#git

TYPO3’s built-in record registration functionality (aka `basic shopping cart`) using recs URL parameters is vulnerable to denial of service. Failing to properly ensure that anonymous user sessions are valid, attackers can use this vulnerability in order to create an arbitrary amount of individual session-data records in the database.

It has been discovered that mechanisms used for configuration of RequireJS package loading are susceptible to information disclosure. This way a potential attack can retrieve additional information about installed system and third party extensions.

It has been discovered that the output of field validation errors in the Form Framework is vulnerable to cross-site scripting.

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)