See how typo3 compares to other vendors in security performance
The referrer enforcement introduced with TYPO3-CORE-SA-2020-006 (CVE-2020-11069) became ineffective in TYPO3 v13.0, where TYPO3 CMS started serving the backend and Install Tool applications from the site's main entry script instead of the dedicated typo3/ directory.
Whether a request originated from the backend or Install Tool itself was determined by comparing the referrer against the directory of the entry script, which since then is the site root. As a consequence, requests originating from any script running on one of the TYPO3 instance's own domains, such as a frontend page, were accepted by backend routes and Install Tool endpoints.
Attackers able to execute JavaScript on one of those domains, for instance by exploiting a cross-site scripting vulnerability, could invoke these endpoints via Fetch/XHR with the privileges of an authenticated victim's user session. This issue affects TYPO3 CMS versions 13.0.0-13.4.33 and 14.0.0-14.3.5.
The extension passes an editor-configurable email subject string directly into a Fluid template source without restriction. A backend user with edit access to the event plugin or Backend Module can supply Fluid ViewHelper syntax in this field to disclose sensitive data or execute TypoScript content objects. Exploitation of this issue requires an authenticated backend account with edit access to the event registration plugin or backend module.
The extension fails to restrict a backend AJAX endpoint for inline editing to fields the current user is permitted to see or edit. An authenticated, low-privileged backend user can supply arbitrary table, field and record parameters, and trigger an error response that discloses the current database value of the requested field, leading to disclosure of sensitive information such as backend and frontend user password hashes. Exploitation requires a valid, authenticated TYPO3 backend user account with access to the extensions backend module.
Users were able to upload files with arbitrary MIME types to forms using FileUpload or ImageUpload elements with allowedMimeTypes configured. The restriction was not enforced server-side because the MimeTypeValidator was registered during form building before concrete form definition properties were applied, resulting in the validator never being added to the processing pipeline. This issue affects TYPO3 CMS versions 14.2.0-14.3.4.
Problem Backend users with write access to the formdefinition database table were able to directly create, update, or delete form definition records via DataHandler, bypassing the Form Framework's persistence validation and permission checks. This allowed injecting arbitrary form configurations, re-enabling attack vectors originally addressed in TYPO3-CORE-SA-2018-003, including SQL injection and privilege escalation.
Solution Update to TYPO3 version 14.3.3 LTS that fixes the problem described.
Credits TYPO3 CMS thanks Selçuk Güney for reporting this issue, and to TYPO3 core & security team member Oliver Hader for fixing it.
Resources TYPO3-CORE-SA-2026-017
Problem The path allowance check in GeneralUtility::isAllowedAbsPath() performed a plain string prefix comparison without requiring a directory separator boundary, causing a path like /var/www/html-other/secret.yaml to be incorrectly accepted as valid when the project root was /var/www/html. Administrator users with access to the File Abstraction Layer were able to create new file storage definitions pointing to directories outside the project root, bypassing this path check.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Wolfgang Klinger for reporting this issue, and to TYPO3 core & security team member Oliver Hader for fixing it.
Resources TYPO3-CORE-SA-2026-016
Problem TYPO3's cache frontend (VariableFrontend) and persistent key-value store (Registry) deserialized PHP payloads without integrity validation or class restrictions. An attacker with write access to the underlying storage backend (cache store or sysregistry database table) could inject a crafted serialized payload to trigger PHP Object Injection, potentially exploiting a gadget chain to achieve Remote Code Execution or other high-impact effects.
Exploiting this vulnerability requires direct local write access to the storage, such as the SQL database or file system.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks “z3rco”, Chowdhury Faizal Ahammed, Rick Larabee, Vitaly Simonovich, Nozomu Sasaki, Mert Akdag, “tikket”, Shafi Almutairi for reporting this issue, and to TYPO3 core & security team member Oliver Hader for fixing it.
Resources TYPO3-CORE-SA-2026-018
Problem Authenticated backend users were able to retrieve file metadata via several Backend API routes without proper permission checks, allowing access to files outside their permitted file mounts or storages.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Phong Lan for reporting this issue, and to TYPO3 core & security team member Oliver Hader for fixing it.
Resources TYPO3-CORE-SA-2026-015
Problem Backend users were able to move records to a different page without having edit permissions on the source page.
Solution Update to TYPO3 versions 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Hyunseo Shin for reporting this issue, and TYPO3 security team member Torben Hansen for fixing it.
Resources TYPO3-CORE-SA-2026-012
Problem Backend users with access to the Recycler module were able to restore soft-deleted records on pages or for tables they were not authorized to modify.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Hyunseo Shin for reporting this issue, and TYPO3 security team member Elias Häußler for fixing it.
Resources TYPO3-CORE-SA-2026-011
Problem Backend users with access to the Form Framework were able to use files not ending in .form.yaml as form definitions, which were processed without denying the incorrect file extension. Maliciously crafted form definition files can be used to execute arbitrary SQL statements, allowing attackers to escalate privileges by creating administrative backend user accounts.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks “Ethan” for reporting this issue, and TYPO3 core & security team member Oliver Hader for fixing it.
Resources TYPO3-CORE-SA-2026-019
The extension fails to properly sanitize user input before using it in a database query. As a result, an unauthenticated attacker can inject arbitrary SQL through a URL parameter on pages using the "Date Menu of news articles" plugin. Exploitation requires the "Date Menu of news articles" plugin to be in use and the TypoScript/Plugin setting disableOverrideDemand not to be enabled.
The Crawler extension passes the X-T3Crawler-Meta response header from crawled URLs directly to PHP's unserialize(). An attacker controlling a crawled endpoint can inject arbitrary serialized PHP objects, leading to Remote Code Execution on the TYPO3 server. Exploitation requires administrative privileges to configure a crawler-enabled page and trigger the crawl via a Scheduler task.
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 Backend users with file download permissions were able to download files from the fallback storage of the file abstraction layer (FAL) via the Media Module. Since the fallback storage resolves paths relative to the server's document root, this could expose sensitive files such as log files.
Solution Update to TYPO3 versions 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Hyunseo Shin for reporting this issue, and to TYPO3 security team member Torben Hansen for fixing it.
Resources TYPO3-CORE-SA-2026-013
Problem Backend users were able to insert arbitrary records and files into the TYPO3 clipboard without proper read permission checks, which allowed users to gather information about records and files they were not authorized to view.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Vincent Yang for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.
Resources TYPO3-CORE-SA-2026-014
Problem Editors with access to create or modify page content were able to include HTML markup in page titles that were stored in the search index without sanitization. When displayed in frontend search results via the Indexed Search plugin, these titles were rendered without proper output encoding, resulting in a Cross-Site Scripting vulnerability.
Solution Update to TYPO3 versions 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Jan Kahmen and Sanjay Singh Jhala for reporting this issue, and to TYPO3 core & security team member Oliver Hader for fixing it.
Resources TYPO3-CORE-SA-2026-010
Problem Non-privileged backend users with file mount access were able to perform write operations (move, delete, rename) on folders representing the root of an active file mount due to missing authorization restrictions.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Arne Uplegger for reporting this issue, and TYPO3 security team member Elias Häußler for fixing it.
Resources TYPO3-CORE-SA-2026-007
Problem Backend users with file write permissions were able to upload form definition files with mixed-case extensions (e.g., .FORM.YAML) to bypass the Form Framework's upload restriction. Maliciously crafted form definition files can be used to execute arbitrary SQL statements, allowing attackers to escalate privileges by creating administrative backend user accounts.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Alexander Künzl for reporting this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke for fixing it.
Resources TYPO3-CORE-SA-2026-008
Problem Applications that use GeneralUtility::sanitizeLocalUrl to allow only local URLs are vulnerable to open redirect attacks if the URL is used after it has passed the aforementioned sanitization checks. This enables attackers to redirect users to external content and carry out phishing attacks.
Solution Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits TYPO3 CMS thanks Alexandre Romao for reporting this issue, and TYPO3 core & security team member Benjamin Franzke for fixing it.
Resources TYPO3-CORE-SA-2026-009
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
The powermail extension for TYPO3 allows Insecure Direct Object Reference resulting in download of arbitrary files from the webserver. This issue affects powermail version 12.0.0 up to 12.5.2 and version 13.0.0
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 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 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
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
### 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
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
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.
The page module in TYPO3 before 8.7.11 has XSS via $GLOBALS['TYPO3CONFVARS']['SYS']['sitename'], as demonstrated by an admin entering a crafted site name during the installation process.