Possible Arbitrary Code Execution in Image Processing

TYPO3 is an open source PHP based web content management system. Versions prior to 8.7.49, 9.5.38, 10.4.33, 11.5.20, and 12.1.1 are vulnerable to Code Injection. Due to the lack of separating user-submitted data from the internal configuration in the Form Designer backend module, it is 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 and a valid backend user account with access to the form module are needed to exploit this vulnerability. This issue is patched in versions 8.7.49 ELTS, 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1.

Unrestricted File Upload vulnerability in the fileDenyPattern in sysext/core/Classes/Core/SystemEnvironmentBuilder.php in TYPO3 7.6.0 to 7.6.21 and 8.0.0 to 8.7.4 allows remote authenticated users to upload files with a .pht extension and consequently execute arbitrary PHP code.

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

TYPO3 Extbase extensions, which implement a file upload and do not implement a custom TypeConverter to transform uploaded files into FileReference domain model objects are affected by the vulnerability as well, since the UploadedFileReferenceConverter of ext:form handles the file upload and will accept files of any mime-type which are persisted to the default location.

In any way, uploaded files are placed in the default location /fileadmin/userupload/, 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.

Solution Update to TYPO3 versions 8.7.40, 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

Type converter UploadedFileReferenceConverter is not registered globally anymore and just handles uploaded files within the scope of the Form Framework. Guessable storage location has changed from /fileadmin/userupload/form\\<random-hash\>/ to /fileadmin/formuploads/<random-40-bit>. Allowed mime-types must match expected file extensions (e.g. application/pdf must be .pdf, and cannot be .html).

Extbase extensions, who rely on the global availability of the UploadedFileReferenceConverter must now implement a custom TypeConverter to handle file uploads or explicitly implement the ext:form UploadedFileReferenceConverter with appropriate setting for accepted mime-types.

Credits Thanks to Sebastian Michaelsen, Marc Lindemann, Oliver Eglseder, Markus Volkmer, Jakob Kunzmann, Johannes Regner, Richie Lee who reported this issue, and to TYPO3 core & security team members Oliver Hader & Benni Mack, as well as TYPO3 contributor Ralf Zimmermann who fixed the issue.

References TYPO3-CORE-SA-2021-002

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

Solution Update to TYPO3 versions 8.7.40, 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

Credits Thanks to Richie Lee who reported this issue and to TYPO3 contributor Ralf Zimmermann who fixed the issue.

References TYPO3-CORE-SA-2021-003

Problem User session identifiers were stored in cleartext - without processing of 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.

Solution Update to TYPO3 versions 6.2.57, 7.6.51, 8.7.40, 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

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

References TYPO3-CORE-SA-2021-006

An issue was discovered in TYPO3 before 8.7.30, 9.x before 9.5.12, and 10.x before 10.2.2. Because escaping of user-submitted content is mishandled, the class QueryGenerator is vulnerable to SQL injection. Exploitation requires having the system extension ext:lowlevel installed, and a valid backend user who has administrator privileges.

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

Problem It has been discovered that user credentials have been logged as plaintext when explicitly using log level debug, which is not the default configuration.

Solution Update to TYPO3 versions 7.6.52 ELTS, 8.7.41 ELTS, 9.5.28, 10.4.18, 11.3.1 that fix the problem described.

Credits Thanks to Ingo Schmitt who reported this issue, and to TYPO3 core & security team member Benni Mack who fixed the issue.

References TYPO3-CORE-SA-2021-012

TYPO3 is an open source PHP based web content management system released under the GNU GPL. 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. 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. There are no known workarounds for this issue.

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

Problem It has been discovered that system internal credentials or keys (e.g. database credentials) have been logged as plaintext in exception handlers, when logging the complete exception stack trace.

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.

Credits Thanks to Marco Huber who reported this issue and to TYPO3 security member Torben Hansen who fixed the issue.

References TYPO3-CORE-SA-2022-002

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

Problem Failing to properly encode error messages, the components QueryGenerator and QueryView are vulnerable to both reflected and persistent cross-site scripting. A valid backend user account having administrator privileges is needed to exploit this vulnerability.

Solution Update to TYPO3 versions 8.7.41 ELTS, 9.5.28, 10.4.18, 11.3.1 that fix the problem described.

Credits Thanks to Richie Lee who reported this issue and to TYPO3 security team member Oliver Hader who fixed the issue.

References TYPO3-CORE-SA-2021-010

Problem Failing to properly encode settings for backend layouts, the corresponding grid view is vulnerable to persistent cross-site scripting. A valid backend user account is needed to exploit this vulnerability.

Solution Update to TYPO3 versions 8.7.41 ELTS, 9.5.28, 10.4.18, 11.3.1 that fix the problem described.

Credits Thanks to TYPO3 core merger Oliver Bartsch who reported and fixed the issue.

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

Problem Failing to properly parse, sanitize and encode malicious rich-text content, the content rendering process in the website frontend is vulnerable to cross-site scripting. Corresponding rendering instructions via TypoScript functionality HTMLparser do not consider all potentially malicious HTML tag & attribute combinations per default.

In addition, the lack of comprehensive default node configuration for rich-text fields in the backend user interface fosters this malfunction.

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.

Solution Update to TYPO3 versions 7.6.53 ELTS, 8.7.42 ELTS, 9.5.29, 10.4.19, 11.3.2 that fix the problem described above.

Custom package typo3/html-sanitizer - based on allow-lists only - takes care of sanitizing potentially malicious markup. The default behavior is based on safe and commonly used markup - however, this can be extended or restricted further in case it is necessary for individual scenarios.

During the frontend rendering process, sanitization is applied to the default TypoScript path lib.parseFunc, which is implicitly used by the Fluid view-helper instruction f:format.html. Rich-text data persisted using the backend user interface is sanitized as well. Implementation details are explained in corresponding ChangeLog documentation.

Credits Thanks to Benjamin Stiber, Gert-Jan Jansma, Gábor Ács-Kurucz, Alexander Kellner, Richie Lee, Nina Rösch who reported this issue, and to TYPO3 security team member Oliver Hader, as well as TYPO3 contributor Susanne Moog who fixed the issue.

References TYPO3-CORE-SA-2021-013

Problem It has been discovered that Login Handling is susceptible to open redirection which allows attackers redirecting to arbitrary content, and conducting phishing attacks. No authentication is required in order to exploit this vulnerability.

Solution Update to TYPO3 versions 6.2.57, 7.6.51, 8.7.40, 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

Credits Thanks to Alexander Kellner who reported this issue and to TYPO3 security team member Torben Hansen who fixed the issue.

References TYPO3-CORE-SA-2021-001

Problem It has been discovered that content elements of type menu are vulnerable to cross-site scripting when their referenced items get previewed in the page module. A valid backend user account is needed to exploit this vulnerability.

Solution Update to TYPO3 versions 7.6.51, 8.7.40, 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

Credits Thanks to TYPO3 contributor Oliver Bartsch who reported and fixed the issue.

References TYPO3-CORE-SA-2021-008

TYPO3 is an open source web content management system. Prior to versions 8.7.47 ELTS, 9.5.34 ELTS, 10.4.29, and 11.5.11, the Form Designer backend module of the Form Framework is vulnerable to cross-site scripting. A valid backend user account with access to the form module is needed to exploit this vulnerability. TYPO3 versions 8.7.47 ELTS, 9.5.34 ELTS, 10.4.29, and 11.5.11 contain a fix for the problem.

Bootstrap Package is a theme for TYPO3. It has been discovered that rendering content in the website frontend is vulnerable to cross-site scripting. A valid backend user account is needed to exploit this vulnerability. Users of the extension, who have overwritten the affected templates with custom code must manually apply the security fix. Update to version 7.1.2, 8.0.8, 9.1.4, 10.0.10 or 11.0.3 of the Bootstrap Package that fix the problem described. Updated version are available from the TYPO3 extension manager, Packagist and at https://extensions.typo3.org/extension/download/bootstrappackage/.

### CVSS: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:X/RL:O/RC:C (4.0)

Problem Given that there are at least two different sites in the same TYPO3 installation - for instance first.example.org and second.example.com - then a session cookie generated for the first site can be reused on the second site without requiring additional authentication.

This vulnerability primarily affects the frontend of the website. It's important to note that exploiting this vulnerability requires a valid user account.

Solution Update to TYPO3 versions 8.7.55 ELTS, 9.5.44 ELTS, 10.4.41 ELTS, 11.5.33, 12.4.8 that fix the problem described above.

Credits Thanks to Rémy Daniel who reported this issue, and to TYPO3 core & security team member Benjamin Franzke who fixed the issue.

References TYPO3-CORE-SA-2023-006

TYPO3 is an open source PHP based web content management system released under the GNU GPL. It has been discovered that observing response time during user authentication (backend and frontend) can be used to distinguish between existing and non-existing user accounts. Extension authors of 3rd party TYPO3 extensions providing a custom authentication service should check if the extension is affected by the described problem. Affected extensions must implement new MimicServiceInterface::mimicAuthUser, which simulates corresponding times regular processing would usually take. 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 this problem. There are no known workarounds for this issue.

TYPO3 is an open source web content management system. Prior to versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.34 ELTS, 10.4.29, and 11.5.11, the export functionality fails to limit the result set to allowed columns of a particular database table. This way, authenticated users can export internal details of database tables they already have access to. TYPO3 versions 7.6.57 ELTS, 8.7.47 ELTS, 9.5.34 ELTS, 10.4.29, 11.5.11 fix the problem described above. In order to address this issue, access to mentioned export functionality is completely denied for regular backend users.