Problem The backend user settings module (SetupModuleController) incorrectly conflates entity data (like passwords or email address) with user-interface settings (like theme, display options) when persisting changes. As a result, passwords were stored in cleartext in the uc and usersettings fields of the beusers database table.

The cleartext data was only persisted if users changed their credentials in the backend user settings module when the TYPO3 14.2.0 release was used (not in any other version).

Solution Update to TYPO3 version 14.3.0 LTS which fixes the problem described.

[!IMPORTANT] Manual actions required Updating to the patched release does not retroactively clean existing data. It is recommended to execute all User Settings upgrade wizards in the TYPO3 Install Tool, including the dedicated User Settings Scrubbing wizard, which sanitizes the incorrectly persisted cleartext values from the uc and usersettings fields of the beusers table. Additionally, affected backend user accounts should be assigned new passwords. Admin Tools → Upgrade → Upgrade Wizard → User Settings Scrubbing

Credits TYPO3 thanks Martin Clewing for reporting this issue, and TYPO3 core team members Oliver Hader, Stefan Bürk and Garvin Hicking for fixing it.

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['TYPO3CONFVARS']['MAIL']['transportspooltype'] = '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

Problem Backend users who had access to the recycler module could delete arbitrary data from any database table defined in the TCA - regardless of whether they had permission to that particular table. This allowed attackers to purge and destroy critical site data, effectively rendering the website unavailable.

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 Sven Jürgens and Daniel Windloff for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

References TYPO3-CORE-SA-2026-003

Problem Backend users with access to the redirects module and write permission on the sysredirect table were able to read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

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 Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

References TYPO3-CORE-SA-2026-002

Problem By exploiting the defVals parameter, attackers could bypass field‑level access checks during record creation in the TYPO3 backend. This gave them the ability to insert arbitrary data into prohibited exclude fields of a database table for which the user already has write permission for a reduced set of fields.

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 Daniel Windloff for reporting this issue, and to TYPO3 core & security team member Benjamin Franzke for fixing it.

References TYPO3-CORE-SA-2026-001

The femanager extension for TYPO3 allows Insecure Direct Object Reference resulting in unauthorized modification of userdata. This issue affects femanager version 6.4.1 and below, 7.0.0 to 7.5.2 and 8.0.0 to 8.3.0

Problem Entities of the File Abstraction Layer (FAL) could be persisted directly via DataHandler. This allowed attackers to reference files in the fallback storage directly and retrieve their file names and contents. The fallback storage ("zero-storage") is used as a backward compatibility layer for files located outside properly configured file storages and within the public web root directory. Exploiting this vulnerability requires a valid backend user account.

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.

ℹ️ Strong security defaults - Manual actions required

When persisting entities of the File Abstraction Layer directly via DataHandler, sysfile entities are now denied by default, and sysfilereference & sysfilemetadata entities are not permitted to reference files in the fallback storage anymore.

When importing data from secure origins, this must be explicitly enabled in the corresponding DataHandler instance by using $dataHandler->isImporting = true;.

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

References TYPO3-CORE-SA-2024-006

Problem The TYPO3-specific t3:// URI scheme could be used to access resources outside of the users' permission scope. This encompassed files, folders, pages, and records (although only if a valid link-handling configuration was provided). Exploiting this vulnerability requires a valid backend user account.

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 Richie Lee who reported this issue and to TYPO3 core & security team member Benjamin Franzke who fixed the issue.

References TYPO3-CORE-SA-2024-005

Problem The plaintext value of $GLOBALS['SYS']['encryptionKey'] was displayed in the editing forms of the TYPO3 Install Tool user interface. This allowed attackers to utilize the value to generate cryptographic hashes used for verifying the authenticity of HTTP request parameters. Exploiting this vulnerability requires an administrator-level backend user account with system maintainer permissions.

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 TYPO3 core & security team member Benjamin Franzke who fixed the issue.

References TYPO3-CORE-SA-2024-004

Problem 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.

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 the TYPO3 framework merger Christian Kuhn and external security researchers Maximilian Beckmann, Klaus-Günther Schmidt who reported this issue, and TYPO3 security team member Oliver Hader who fixed the issue.

References TYPO3-CORE-SA-2024-003

Meta CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N/E:F/RL:O/RC:C (3.5)

Problem It has been discovered that TYPO3 CMS is susceptible to host spoofing due to improper validation of the HTTP Host header. TYPO3 uses the HTTP Host header, for example, to generate absolute URLs during the frontend rendering process. Since the host header itself is provided by the client, it can be forged to any value, even in a name-based virtual hosts environment.

This vulnerability is the same as described in TYPO3-CORE-SA-2014-001 (CVE-2014-3941). A regression, introduced during TYPO3 v11 development, led to this situation. The already existing setting $GLOBALS['TYPO3CONFVARS']['SYS']['trustedHostsPattern'] (used as an effective mitigation strategy in previous TYPO3 versions) was not evaluated anymore, and reintroduced the vulnerability.

Solution Update your instance to TYPO3 version 11.5.0 which addresses the problem described.

Credits Thanks to TYPO3 framework merger Benjamin Franzke who reported and fixed the issue.

References TYPO3-CORE-SA-2021-015 CVE-2014-3941 reintroduced in TYPO3 v11.0.0

### Meta CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C (8.2)

Problem It has been discovered that the new TYPO3 v11 feature that allows users to create and share deep links in the backend user interface is vulnerable to cross-site-request-forgery.

The impact is the same as described in TYPO3-CORE-SA-2020-006 (CVE-2020-11069). However, it is not limited to the same site context and does not require the attacker to be authenticated. In a worst case scenario, the attacker could create a new admin user account to compromise the system.

To successfully carry out an attack, an attacker must trick his victim to access a compromised system. The victim must have an active session in the TYPO3 backend at that time.

The following Same-Site cookie settings in $GLOBALS[TYPO3CONFVARS][BE][cookieSameSite] are required for an attack to be successful:

SameSite=strict: malicious evil.example.org invoking TYPO3 application at good.example.org SameSite=lax or none: malicious evil.com invoking TYPO3 application at example.org

Solution Update your instance to TYPO3 version 11.5.0 which addresses the problem described.

Credits Thanks to Richie Lee who reported this issue and to TYPO3 core & security team members Benni Mack and Oliver Hader who fixed the issue.

References TYPO3-CORE-SA-2021-014 CVE-2020-11069 reintroduced in TYPO3 v11.2.0

svg.swf in TYPO3 6.2.0 to 6.2.38 ELTS and 7.0.0 to 7.1.0 could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack on a targeted system. This may be at a contrib/websvg/svg.swf pathname.

It was found that Typo3 Core versions 4.5.0 - 4.5.5 uses prepared statements that, if the parameter values are not properly replaced, could lead to a SQL Injection vulnerability. This issue can only be exploited if two or more parameters are bound to the query and at least two come from user input.

TYPO3 before 4.4.9 and 4.5.x before 4.5.4 does not apply proper access control on ExtDirect calls which allows remote attackers to retrieve ExtDirect endpoint services.

Cross-site Scripting (XSS) in TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to inject arbitrary web script or HTML via the RemoveXSS function.

TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to delete arbitrary files on the webserver.

TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to extract arbitrary information from the TYPO3 database.

Cross-site Scripting (XSS) in TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to inject arbitrary web script or HTML via the tcemain flash message.

Cross-site Scripting (XSS) in TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to inject arbitrary web script or HTML via the system extension recycler.

Cross-site Scripting (XSS) in TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to inject arbitrary web script or HTML via the browselinks wizard.

Cross-site Scripting (XSS) in TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to inject arbitrary web script or HTML via the admin panel.

TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to bypass authentication mechanisms in the backend through a crafted request.

TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows Information Disclosure on the backend.

Cross-site Scripting (XSS) in TYPO3 before 4.3.12, 4.4.x before 4.4.9, and 4.5.x before 4.5.4 allows remote attackers to inject arbitrary web script or HTML via the "JSwindow" property of the typolink function.

TYPO3 before 4.4.1 allows XSS in the frontend search box.

TYPO3 before 4.2.13, 4.3.x before 4.3.4 and 4.4.x before 4.4.1 allows information disclosure in the mail header of the HTML mailing API.

TYPO3 before 4.3.4 and 4.4.x before 4.4.1 allows XSS in the textarea view helper in an extbase extension.

TYPO3 before 4.1.14, 4.2.x before 4.2.13, 4.3.x before 4.3.4 and 4.4.x before 4.4.1 is open to a session fixation attack which allows remote attackers to hijack a victim's session.

TYPO3 before 4.3.4 and 4.4.x before 4.4.1 contains insecure randomness during generation of a hash with the "forgot password" function.