Package Instance

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in typo3/cms-form
### Problem
It has been discovered that 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.

### Solution
Update to TYPO3 versions 10.4.14 or 11.1.1 that fix the problem described.

### Credits
Thanks to Richie Lee who reported this issue and to TYPO3 framework merger Andreas Fernandez who fixed the issue.

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

Broken Access Control in Form Framework
### 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](https://typo3.org/security/advisory/typo3-core-sa-2021-003)

TYPO3 Form Framework Module vulnerable to Cross-Site Request Forgery
### Problem
A vulnerability has been identified in the backend user interface functionality involving deep links. Specifically, this functionality is susceptible to Cross-Site Request Forgery (CSRF). Additionally, state-changing actions in downstream components incorrectly accepted submissions via HTTP GET and did not enforce the appropriate HTTP method.

Successful exploitation of this vulnerability requires the victim to have an active session on the backend user interface and to be deceived into interacting with a malicious URL targeting the backend, which can occur under the following conditions:

* the user opens a malicious link, such as one sent via email.
* the user visits a compromised or manipulated website while the following settings are misconfigured:
  + `security.backend.enforceReferrer` feature is disabled,
  + `BE/cookieSameSite` configuration is set to `lax` or `none`

The vulnerability in the affected downstream component “Form Framework Module” allows attackers to manipulate or delete persisted form definitions.

### Solution
Update to TYPO3 versions 11.5.42 ELTS, 12.4.25 LTS, 13.4.3 LTS that fix the problem described.

### Credits
Thanks to TYPO3 core and security members Benjamin Franzke, Oliver Hader, Andreas Kienast, Torben Hansen, Elias Häußler who fixed the issue.

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

Unrestricted File Upload in Form Framework
### 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/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.

### 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/user_upload/form\_\<random-hash\>/_ to _/fileadmin/form_uploads/<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](https://typo3.org/security/advisory/typo3-core-sa-2021-002)