ghsa

Failing to properly encode user input, frontend forms handled by the form framework (system extension “form”) are vulnerable to cross-site scripting.

When using the TYPO3 backend in order to create new backend user accounts, database records containing insecure or empty credentials might be persisted. When the type of user account is changed - which might be entity type or the admin flag for backend users - the backend form is reloaded in order to reflect changed configuration possibilities. However, this leads to persisting the current state as well, which can result into some of the following: - account contains empty login credentials (username and/or password) - account is incomplete and contains weak credentials (username and/or password) Albeit the functionality provided by the TYPO3 core cannot be used either with empty usernames or empty passwords, it still can be a severe vulnerability to custom authentication service implementations. This weakness cannot be directly exploited and requires interaction on purpose by some backend user having according privileges.

It has been discovered that `t3://` URL handling and typolink functionality are vulnerable to cross-site scripting. Not only regular backend forms are affected but also frontend extensions which use the rendering with typolink.

It has been discovered that backend users having limited access to specific languages are capable of modifying and creating pages in the default language which actually should be disallowed. A valid backend user account is needed in order to exploit this vulnerability.

It has been discovered that the output table listing in the “Files” backend module is vulnerable to cross-site scripting when a file extension contains malicious sequences. Access to the file system of the server - either directly or through synchronization - is required to exploit the vulnerability.

Failing to properly encode user input, templates using built-in Fluid ViewHelpers are vulnerable to cross-site scripting.

It has been discovered that request handling in Extbase can be vulnerable to insecure deserialization. User submitted payload has to be signed with a corresponding HMAC-SHA1 using the sensitive TYPO3 encryptionKey as secret - invalid or unsigned payload is not deserialized. However, since sensitive information could have been leaked by accident (e.g. in repositories or in commonly known and unprotected backup files), there is the possibility that attackers know the private encryptionKey and are able to calculate the required HMAC-SHA1 to allow a malicious payload to be deserialized. Requirements for successfully exploiting this vulnerability (all of the following): - rendering at least one Extbase plugin in the frontend - encryptionKey has been leaked (from LocalConfiguration.php or corresponding .env file)

The encrypt() function of Ninja Core v7.0.0 was discovered to use a weak cryptographic algorithm, leading to a possible leakage of sensitive information.

### Impact All users are impacted. The zsa application transfers the parse error stack from the server to the client in production build mode. This can potentially reveal sensitive information about the server environment, such as the machine username and directory paths. An attacker could exploit this vulnerability to gain unauthorized access to sensitive server information. This information could be used to plan further attacks or gain a deeper understanding of the server infrastructure. ### Patches Yes, this has been pathed on `0.3.3` ### Workarounds No way to fix other than the patch.

### Summary Tornado’s `curl_httpclient.CurlAsyncHTTPClient` class is vulnerable to CRLF (carriage return/line feed) injection in the request headers. ### Details When an HTTP request is sent using `CurlAsyncHTTPClient`, Tornado does not reject carriage return (\r) or line feed (\n) characters in the request headers. As a result, if an application includes an attacker-controlled header value in a request sent using `CurlAsyncHTTPClient`, the attacker can inject arbitrary headers into the request or cause the application to send arbitrary requests to the specified server. This behavior differs from that of the standard `AsyncHTTPClient` class, which does reject CRLF characters. This issue appears to stem from libcurl's (as well as pycurl's) lack of validation for the [`HTTPHEADER`](https://curl.se/libcurl/c/CURLOPT_HTTPHEADER.html) option. libcurl’s documentation states: > The headers included in the linked list must not be CRLF-terminated, because libcurl adds CRLF after each header...