It has been discovered that the output of field validation errors in the Form Framework is vulnerable
to cross-site scripting.
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.
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 the extraction of manually uploaded ZIP archives in Extension Manager is vulnerable
to directory traversal. Admin privileges are required in order to exploit this vulnerability. Since TYPO3 v9 LTS,
System Maintainer privileges are required as well.
Failing to properly escape user submitted content, class QueryGenerator is vulnerable to SQL injection.
Having system extension ext:lowlevel installed and a valid backend user having administrator privileges are
required to exploit this vulnerability.
It has been discovered that classes QueryGenerator and QueryView are vulnerable to insecure deserialization.
Requirements for successfully exploiting this vulnerability (one of the following):
- having system extension ext:lowlevel (Backend Module: DB Check) installed and valid backend user having
administrator privileges
- having system extension ext:sys_action installed and valid backend user having limited privileges
TYPO3 allows to upload files either in the backend user interface as well as in custom developed extensions.
To reduce the possibility to upload potential malicious code TYPO3 uses the fileDenyPattern to deny e.g. user
submitted PHP scripts from being persisted. Besides that it is possible for any editor to upload file assets
using the file module (fileadmin) or changing their avatar image shown in the TYPO3 backend.
Per default TYPO3 allows to upload and store HTML and SVG files as well using the mentioned functionalities.
Custom extension implementations probably would also accept those files when only the fileDenyPattern is evaluated.
Since HTML and SVG files - which might contain executable JavaScript code per W3C standard - could be directly
displayed in web clients, the whole web application is exposed to be vulnerable concerning Cross-Site Scripting.
Currently the following scenarios are known - given an authenticated regular editor is able to upload files using
the TYPO3 backend:
- directly target a potential victim to a known public resource in a URL, e.g. /fileadmin/malicious.svg or
/fileadmin/malicious.html
- using the TypoScript content object “SVG” (implemented in class ScalableVectorGraphicsContentObject)
having renderMode set to inline for SVG files (available since TYPO3 v9.0)
- custom implementations that directly output and render markup of HTML and SVG files
SVG files that are embedded using an img src=”malicious.svg” tag are not vulnerable since potential
scripts are not executed in these scenarios (see https://www.w3.org/wiki/SVG_Security). The icon API of TYPO3
is not scope of this announcement since SVG icons need to be registered using an individual implementation,
which is not considered as user submitted content.
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).