Package Instance

TYPO3 CMS vulnerable to Arbitrary Code Execution via Form Framework
### Problem
Due to the lack of separating user-submitted data from the internal configuration in the Form Designer backend module, it was possible to inject code instructions to be processed and executed via TypoScript as PHP code.

The existence of individual TypoScript instructions for a particular form item (known as [`formDefinitionOverrides`](https://docs.typo3.org/c/typo3/cms-form/main/en-us/I/Concepts/FrontendRendering/Index.html#form-element-properties)) and a valid backend user account with access to the form module are needed to exploit this vulnerability.

### Solution
Update to TYPO3 versions 8.7.49 ELTS, 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1 that fix the problem described above.

### References
* [TYPO3-CORE-SA-2022-015](https://typo3.org/security/advisory/typo3-core-sa-2022-015)

Information Disclosure via Export Module
> ### Meta
> * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (4.0)

### Problem
The export functionality fails to limit the result set to allowed columns of a particular database table. This allows authenticated users to export internal details of database tables to which they already have access.

### Solution
Update to TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above.

In order to address this issue, access to mentioned export functionality is completely denied for regular backend users.

ℹ️  **Strong security defaults - Manual actions required**
Following User TSconfig setting would allow using the export functionality for particular users:
```
options.impexp.enableExportForNonAdminUser = 1
```

### Credits
Thanks to TYPO3 core merger Lina Wolf who reported this issue and to TYPO3 security member Torben Hansen  who fixed the issue.

### References
* [TYPO3-CORE-SA-2022-001](https://typo3.org/security/advisory/typo3-core-sa-2022-001)

Path Traversal
Due to improper input validation, attackers can by-pass restrictions of predefined options and submit arbitrary data in the Form Designer backend module of the Form Framework. In the default configuration of the Form Framework this allows attackers to explicitly allow arbitrary mime-types for file uploads - however, default `_fileDenyPattern_` successfully blocked files like `_.htaccess_` or `_malicious.php_`. Besides that, attackers can persist those files in any writable directory of the corresponding TYPO3 installation. A valid backend user account with access to the form module is needed to exploit this vulnerability.

Deserialization of Untrusted Data
In TYPO3 CMS, it has been discovered that an internal verification mechanism can be used to generate arbitrary checksums. This allows to inject arbitrary data having a valid cryptographic message authentication code (HMAC-SHA1) and can lead to various attack chains including potential privilege escalation, insecure deserialization & remote code execution. The overall severity of this vulnerability is high based on mentioned attack chains and the requirement of having a valid backend user session (authenticated).

Cross-site Scripting
TYPO3 is vulnerable to cross-site scripting. Corresponding rendering instructions via TypoScript functionality HTMLparser does not consider all potentially malicious HTML tag & attribute combinations per default. In default scenarios, a valid backend user account is needed to exploit this vulnerability. In case custom plugins used in the website frontend accept and reflect rich-text content submitted by users, no authentication is required.

TYPO3 CMS Stored Cross-Site Scripting via FileDumpController
> ### Meta
> * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0)

### Problem
It has been discovered that the `FileDumpController` (backend and frontend context) is vulnerable to cross-site scripting when malicious files are displayed using this component. A valid backend user account is needed to exploit this vulnerability.

### Solution
Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above.

### Credits
Thanks to Vautia who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue.

### References
* [TYPO3-CORE-SA-2022-009](https://typo3.org/security/advisory/typo3-core-sa-2022-009)
* [Vulnerability Report on huntr.dev](https://huntr.dev/bounties/51e9b709-193c-41fd-bd4a-833aaca0bd4e/) (embargoed +30 days)

Improper Restriction of XML External Entity Reference
TYPO3 is an open source PHP based web content management system. In TYPO3 from, and, RSS widgets are susceptible to XML external entity processing. This vulnerability is reasonable, but is theoretical - it was not possible to actually reproduce the vulnerability with current PHP versions of supported and maintained system distributions. At least with libxml2, the processing of XML external entities is disabled per default - and cannot be exploited. Besides that, a valid backend user account is needed.

Cross-Site Scripting in TYPO3's Frontend Login Mailer
> ### Meta
> * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.9)

### Problem
User submitted content was used without being properly encoded in HTML emails sent to users. The actually affected components were mail clients used to view those messages.

### Solution
Update to TYPO3 versions 9.5.35 ELTS, 10.4.29, 11.5.11 that fix the problem described above.

### Credits
Thanks to Christian Seifert who reported this issue and to TYPO3 framework merger Andreas Fernandez who fixed the issue.

### References
* [TYPO3-CORE-SA-2022-004](https://typo3.org/security/advisory/typo3-core-sa-2022-004)

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

Cleartext Storage of Sensitive Information
TYPO3 is an open source PHP based web content management system. In TYPO3 user session identifiers were stored in cleartext - without processing with additional cryptographic hashing algorithms. This vulnerability cannot be exploited directly and occurs in combination with a chained attack - like for instance SQL injection in any other component of the system.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
TYPO3 is a free and open source Content Management Framework released under the GNU General Public License. In affected versions the TYPO3 core component `GeneralUtility::getIndpEnv()` uses the unfiltered server environment variable `PATH_INFO`, which allows attackers to inject malicious content. In combination with the TypoScript setting `config.absRefPrefix=auto`, attackers can inject malicious HTML code to pages that have not been rendered and cached, yet. As a result, injected values would be cached and delivered to other website visitors (persisted cross-site scripting). Individual code which relies on the resolved value of `GeneralUtility::getIndpEnv('SCRIPT_NAME')` and corresponding usages (as shown below) is vulnerable as well. Additional investigations confirmed that at least Apache web server deployments using CGI (FPM, FCGI/FastCGI, and similar) are affected. However, there still might be the risk that other scenarios like nginx, IIS, or Apache/mod_php is vulnerable. The usage of server environment variable `PATH_INFO` has been removed from corresponding processings in `GeneralUtility::getIndpEnv()`. Besides that, the public property `TypoScriptFrontendController::$absRefPrefix` is encoded for both being used as a URI component and for being used as a prefix in an HTML context. This mitigates the cross-site scripting vulnerability. Users are advised to update to TYPO3 versions 8.7.51 ELTS, 9.5.40 ELTS, 10.4.35 LTS, 11.5.23 LTS and 12.2.0 which fix this problem. For users who are unable to patch in a timely manner the TypoScript setting `config.absRefPrefix` should at least be set to a static path value, instead of using auto - e.g. `config.absRefPrefix=/`. This workaround **does not fix all aspects of the vulnerability**, and is just considered to be an intermediate mitigation to the most prominent manifestation.