#vulnerability

Failing to properly encode user input, online media asset rendering (`*.youtube` and `*.vimeo` files) is vulnerable to cross-site scripting. A valid backend user account or write access on the server system (e.g. SFTP) is needed in order to exploit this vulnerability.

### Summary Regardless of the role or privileges, no user should be able to inject malicious JavaScript (JS) scripts into the body HTML. an XSS (Cross-Site Scripting) vulnerability, specifically a Stored XSS, which affects all pages of the website. Once the JS script is embedded in the body HTML, the XSS will trigger on any page a victim visits, such as the about, blog, contact, or any other pages, except for the panel. ### Impact This vulnerability allows attackers to inject malicious JS or HTML through a crafted payload into the vulnerable spot, achieving persistence and attacking numerous visitors or anyone accessing the website. The attack can be widespread and affect many users because the malicious JS will execute on every page, unlike an injection on a specific page (e.g., injecting on the About page would only affect that page). In this case, a single injection point leads to the execution of the malicious JS on all pages. ### Patches - [**Formwork 1.13.1**](https://github.co...

Due to missing file extensions in $GLOBALS['TYPO3_CONF_VARS']['BE'][‘fileDenyPattern’], backend users are allowed to upload *.phar, *.shtml, *.pl or *.cgi files which can be executed in certain web server setups. A valid backend user account is needed in order to exploit this vulnerability. Derivatives of Debian GNU Linux are handling *.phar files as PHP applications since PHP 7.1 (for unofficial packages) and PHP 7.2 (for official packages). The file extension *.shtml is bound to server side includes which are not enabled per default in most common Linux based distributions. File extension *.pl and *.cgi require additional handlers to be configured which is also not the case in most common distributions (except for /cgi-bin/ location).

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 the output of field validation errors in the Form Framework is 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 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.

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)

Ubuntu Security Notice 6815-1 - Xiantong Hou discovered that AOM did not properly handle certain malformed media files. If an application using AOM opened a specially crafted file, a remote attacker could cause a denial of service, or possibly execute arbitrary code.