Package Instance

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.

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.

TYPO3 Install Tool vulnerable to Code Execution
### Problem
Several settings in the Install Tool for configuring the path to system binaries were vulnerable to code execution. Exploiting this vulnerability requires an administrator-level backend user account with system maintainer permissions.

The corresponding change for this advisory involves enforcing the known disadvantages described in [TYPO3-PSA-2020-002: Protecting Install Tool with Sudo Mode](https://typo3.org/security/advisory/typo3-psa-2020-002).

### Solution
Update to TYPO3 versions 8.7.57 ELTS, 9.5.46 ELTS, 10.4.43 ELTS, 11.5.35 LTS, 12.4.11 LTS, 13.0.1 that fix the problem described.

### Credits
Thanks to Rickmer Frier & Daniel Jonka who reported this issue and to TYPO3 core & security team member Benjamin Franzke who fixed the issue.

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

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.

TYPO3 Cross-Site Scripting in Link Handling
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.

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.

Asymmetric Resource Consumption (Amplification)
Requesting invalid or non-existing resources via HTTP, triggers the page error handler which again could retrieve content to be shown as error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded.

Cross-site Scripting
Database fields used as `_descriptionColumn_` are vulnerable to cross-site scripting when their content gets previewed. A valid backend user account is needed to exploit this vulnerability.

TYPO3 Cross-Site Scripting in Filelist Module
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.

Exposure of Sensitive Information to an Unauthorized Actor
TYPO3 is an open source PHP based web content management system released under the GNU GPL. Password hashes were being reflected in the editing forms of the TYPO3 backend user interface. This allowed attackers to crack the plaintext password using brute force techniques. Exploiting this vulnerability requires a valid backend user account. Users are advised to update to TYPO3 versions 8.7.57 ELTS, 9.5.46 ELTS, 10.4.43 ELTS, 11.5.35 LTS, 12.4.11 LTS, 13.0.1 that fix the problem described. There are no known workarounds for this issue.

TYPO3 Allows Unrestricted File Upload in File Abstraction Layer
### Problem
By design, the file management module in TYPO3’s backend user interface has historically allowed the upload of any file type, with the exception of those that are directly executable in a web server context. This lack of restriction means it is possible to upload files that may be considered potentially harmful, such as executable binaries (e.g., `.exe` files), or files with inconsistent file extensions and MIME types (for example, a file incorrectly named with a `.png` extension but actually carrying the MIME type `application/zip`).

Although such files are not directly executable through the web server, their presence can introduce indirect risks. For example, third-party services such as antivirus scanners or malware detection systems might flag or block access to the website for end users if suspicious files are found. This could negatively affect the availability or reputation of the site.

### Solution
Update to TYPO3 versions 9.5.51 ELTS, 10.4.50 ELTS, 11.5.44 ELTS, 12.4.31 LTS, 13.4.12 LTS that fix the problem described.

Unrestricted Upload of File with Dangerous Type
Due to the lack of ensuring file extensions belong to configured allowed mime-types, attackers can upload arbitrary data with arbitrary file extensions - however, default `_fileDenyPattern_` successfully blocked files like `_.htaccess_` or `_malicious.php_`. Additionally, `_UploadedFileReferenceConverter_` transforming uploaded files into proper FileReference domain model objects handles possible file uploads for other extensions as well - given those extensions use the Extbase MVC framework, make use of FileReference items in their direct or inherited domain model definitions and did not implement their own type converter. In case this scenario applies, `_UploadedFileReferenceConverter_` accepts any file mime-type and persists files in the default location. In any way, uploaded files are placed in the default location `_/fileadmin/user_upload/_`, in most scenarios keeping the submitted filename - which allows attackers to directly reference files, or even correctly guess filenames used by other individuals, disclosing this information. No authentication is required to exploit this vulnerability.

Cross-Site Request Forgery (CSRF)
In TYPO3 CMS, it has been discovered that the backend user interface and install tool are vulnerable to a same-site request forgery. A backend user can be tricked into interacting with a malicious resource an attacker previously managed to upload to the web server. Scripts are then executed with the privileges of the victims' user session. In a worst-case scenario, new admin users can be created which can directly be used by an attacker. The vulnerability is basically a cross-site request forgery (CSRF) triggered by a cross-site scripting vulnerability (XSS). Malicious payload such as HTML containing JavaScript might be provided by either an authenticated backend user or by a non-authenticated user using a third party extension, e.g., file upload in a contact form with knowing the target location. To be successful, the attacked victim requires an active and valid backend or install tool user session at the time of the attack.

TYPO3 CMS Allows Insecure Deserialization via Mailer File Spool
### Problem
Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server.

The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue.

### Solution
Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

### Credits
Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it.

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