Skip to content

[upstream] [SECURITY] Register MimeTypeValidator for file uploads at runtime#10

Open
github-actions[bot] wants to merge 1 commit into
release/v14from
upstream-sync/03866a4904
Open

[upstream] [SECURITY] Register MimeTypeValidator for file uploads at runtime#10
github-actions[bot] wants to merge 1 commit into
release/v14from
upstream-sync/03866a4904

Conversation

@github-actions

Copy link
Copy Markdown

Automatisch vorgeschlagener Cherry-pick aus TYPO3-CMS/form @ 14.3.

Upstream-Commit

Commit-Message

Upstream-Commit-Message anzeigen
[SECURITY] Register MimeTypeValidator for file uploads at runtime

The "allowedMimeTypes" restriction of the FileUpload and ImageUpload
form elements was never enforced on the server side. Uploading a file
whose MIME type is not part of the configured list (e.g. a PNG while
only "application/pdf" is allowed) passed validation and the form was
processed as valid, including running finishers.

Root cause is a timing issue during form building:
FileUpload::initializeFormElement() registered the MimeTypeValidator
based on the "allowedMimeTypes" property. However, the method
initializeFormElement() is called from AbstractSection::createElement()
*before* the concrete form definition properties are applied via the
second setOptions() call in ArrayFormFactory::addNestedRenderable().
As the prototype type definition does not contain "allowedMimeTypes",
the property was always empty at that point and the validator was never
added to the ProcessingRule. The client-side "accept" attribute was
therefore the only remaining barrier, which can be trivially bypassed
in the browser file picker.

The MimeTypeValidator registration is now performed at runtime in
PropertyMappingConfiguration::adjustPropertyMappingForFileUploadsAtRuntime(),
where the form definition properties are fully available and which runs
before the submitted values are validated. The same class already sets
the upload seed and removal configuration there for the exact same
reason. Registration is guarded against duplicates.

Resolves: #110158
Releases: main, 14.3
Security-Bulletin: TYPO3-CORE-SA-2026-020
Security-References: CVE-2026-15305
Change-Id: Ibe36e7709966d13966aa960b6a64fc5d6acfbbb4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/94773
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>


Erzeugt von .github/workflows/upstream-sync.yml.
Um diesen Commit künftig nicht erneut vorzuschlagen, schließe die PR ohne Merge — der Marker unten bleibt erhalten.

The "allowedMimeTypes" restriction of the FileUpload and ImageUpload
form elements was never enforced on the server side. Uploading a file
whose MIME type is not part of the configured list (e.g. a PNG while
only "application/pdf" is allowed) passed validation and the form was
processed as valid, including running finishers.

Root cause is a timing issue during form building:
FileUpload::initializeFormElement() registered the MimeTypeValidator
based on the "allowedMimeTypes" property. However, the method
initializeFormElement() is called from AbstractSection::createElement()
*before* the concrete form definition properties are applied via the
second setOptions() call in ArrayFormFactory::addNestedRenderable().
As the prototype type definition does not contain "allowedMimeTypes",
the property was always empty at that point and the validator was never
added to the ProcessingRule. The client-side "accept" attribute was
therefore the only remaining barrier, which can be trivially bypassed
in the browser file picker.

The MimeTypeValidator registration is now performed at runtime in
PropertyMappingConfiguration::adjustPropertyMappingForFileUploadsAtRuntime(),
where the form definition properties are fully available and which runs
before the submitted values are validated. The same class already sets
the upload seed and removal configuration there for the exact same
reason. Registration is guarded against duplicates.

Resolves: #110158
Releases: main, 14.3
Security-Bulletin: TYPO3-CORE-SA-2026-020
Security-References: CVE-2026-15305
Change-Id: Ibe36e7709966d13966aa960b6a64fc5d6acfbbb4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/94773
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
(cherry picked from commit 03866a4904defadd3e057663783a2c3399bc4d57)
@github-actions github-actions Bot added upstream-sync Automatically proposed cherry-pick from upstream security Security-related upstream change labels Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

security Security-related upstream change upstream-sync Automatically proposed cherry-pick from upstream

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant