CVE-2026-15305: Server-Side Validation Bypass in TYPO3 CMS Form Framework File Upload Component

CVE-2026-15305 is an unrestricted file upload vulnerability residing in the Form Framework extension (ext:form) of TYPO3 CMS. The affected subsystem is responsible for rendering, processing, and validating user-submitted forms, including those designed to receive file or image uploads. When configured with explicit MIME type limitations, the server-side validation mechanics failed to engage under certain conditions.

The vulnerability stems from a lifecycle mismatch where the configuration properties of a form element are loaded after the element's validation middleware has already initialized. This architectural timing defect results in the server-side validator receiving an empty array of allowed MIME types. Consequently, the component registers no active validators for the upload fields, bypassing server-side validation checks entirely.

The scope of exposure includes any deployment of TYPO3 CMS versions 14.2.0 through 14.3.4 that utilizes either the FileUpload or ImageUpload elements within its forms. Although client-side restrictions limit the interactive file picker in a user's web browser, these restrictions are trivially bypassed at the HTTP layer. Security teams must address this vulnerability because it allows unauthenticated users to upload arbitrary files, with the exception of PHP execution scripts.

The root cause of this vulnerability lies in the sequence of execution inside TYPO3's Form Framework during the form tree assembly. During a typical form submission, TYPO3 builds a structured representation of the form using AbstractSection::createElement(). This method calls initializeFormElement() on individual element classes to set up default rules, handlers, and validation boundaries.

When handling FileUpload and ImageUpload elements, the initializeFormElement() method attempts to retrieve the element's user-defined properties, specifically the allowedMimeTypes configuration list. However, at this exact moment in the lifecycle, the concrete configuration options parsed from the form's YAML configuration have not been merged into the element instance. This merge operation is deferred until a later stage in ArrayFormFactory::addNestedRenderable(), where setOptions() is executed.

Because the properties are unpopulated during initialization, FileUpload::initializeFormElement() evaluates the configured MIME types to an empty array. The code then skips the instantiation and registration of the MimeTypeValidator due to a strict truthy check on the array's contents. The framework proceeds to process the form submission without any active server-side file type restrictions attached to the file upload processing rules.

This architectural sequence flaw means that while the rendering engine correctly receives the properties to generate the HTML accept attribute for client-side enforcement, the server-side execution pipeline operates completely blind. The processing rule for the uploaded file executes with zero registered validators. This lack of validation allows any payload to bypass checks and successfully propagate to the destination storage directory.

A comparative analysis of the vulnerable and patched code reveals how the developer team decoupled validation registration from the early form tree setup. In the vulnerable implementation of FileUpload.php, the validator setup occurred directly inside the early initialization lifecycle hook. This premature extraction is illustrated below, where the empty array results in a failed check:

// Vulnerable implementation in FileUpload::initializeFormElement()
$allowedMimeTypes = [];
if (is_array($this->getProperties()['allowedMimeTypes'] ?? null)) {
    $allowedMimeTypes = array_filter($this->getProperties()['allowedMimeTypes']);
}
if (!empty($allowedMimeTypes)) {
    $validatorResolver = GeneralUtility::makeInstance(ValidatorResolver::class);
    $mimeTypeValidator = $validatorResolver->createValidator(MimeTypeValidator::class, ['allowedMimeTypes' => $allowedMimeTypes]);
    $this->getRootForm()
        ->getProcessingRule($this->getIdentifier())
        ->addValidator($mimeTypeValidator);
}

The patch remediates this defect by removing the validation logic from initializeFormElement() and deferring it to PropertyMappingConfiguration::adjustPropertyMappingForFileUploadsAtRuntime(). This adjustment ensures that the validation rules are populated only when the form runtime state is fully initialized and all properties are merged. By checking for the presence of the MimeTypeValidator before adding it, the engine also prevents duplicate registration issues:

// Deferring validation to runtime execution hook
protected function registerMimeTypeValidator(
    ProcessingRule $processingRule,
    FileUpload $renderable
): void {
    $allowedMimeTypes = [];
    if (is_array($renderable->getProperties()['allowedMimeTypes'] ?? null)) {
        $allowedMimeTypes = array_filter($renderable->getProperties()['allowedMimeTypes']);
    }
    if ($allowedMimeTypes === []) {
        return;
    }
 
    foreach ($processingRule->getValidators() as $validator) {
        if ($validator instanceof MimeTypeValidator) {
            return; // Guard against duplicates
        }
    }
 
    $mimeTypeValidator = GeneralUtility::makeInstance(ValidatorResolver::class)
        ->createValidator(MimeTypeValidator::class, ['allowedMimeTypes' => $allowedMimeTypes]);
    $processingRule->addValidator($mimeTypeValidator);
}

Additionally, the remediation introduces an extra security layer within UploadedFileReferenceConverter.php by performing pre-storage validation. The converter now transforms the incoming file into a temporary PseudoFile object and evaluates it against the registered validators before writing any bytes to the persistent File Abstraction Layer (FAL). If an invalid MIME type is detected, the converter throws a TypeConverterException, preventing the file from being committed to the file system:

// Executing validators on PseudoFile objects prior to persistence
$preStorageValidators = $configuration->getConfigurationValue(self::class, self::CONFIGURATION_PRE_STORAGE_VALIDATORS) ?? [];
foreach ($preStorageValidators as $validator) {
    $validationResult = $validator->validate($pseudoFile);
    if ($validationResult->hasErrors()) {
        $firstError = current($validationResult->getErrors());
        throw TypeConverterException::fromError($firstError);
    }
}

Exploitation of CVE-2026-15305 requires no authenticated sessions or specialized configuration beyond the presence of an active file upload field. An attacker first navigates to the target TYPO3 application containing a form with an FileUpload or ImageUpload component. Although the browser restricts the file picker options based on the client-side accept attribute, this control is easily bypassed.

The attacker captures a legitimate form submission request using an intercepting HTTP proxy or generates a manual raw POST request mimicking the multipart/form-data structure. Within the payload boundary, the attacker swaps the authorized file payload with their chosen payload, such as a malicious SVG or HTML file. The attacker modifies the filename and the Content-Type headers to reflect the new file format and submits the transaction to the server.

Upon receipt, the TYPO3 server processes the request but fails to trigger any MIME type checks during the property mapping phase. The server-side code handles the file, executes any subsequent form finishers (such as database persistence or email distribution), and writes the file into the public-facing storage directory, typically located within fileadmin/user_upload/. The attacker can then access the uploaded asset directly or leverage it to execute client-side attacks like Stored Cross-Site Scripting (XSS).

To visualize this workflow and technical structure, the sequence of the attack can be modeled using the following architecture diagram. The diagram outlines the client-server interaction and highlights where the lack of validation occurs in the processing chain:

The security impact of CVE-2026-15305 is assessed with a CVSS v4.0 base score of 6.3 (Medium). While this rating reflects a non-critical score, the real-world operational impact on affected organizations can be substantial depending on the site configuration. Because the vulnerability allows unauthenticated, remote users to write files to the web server's storage, it directly threatens system integrity and client-side security.

The primary vector of concern is Stored Cross-Site Scripting (XSS) via uploaded files. Attackers can upload HTML documents or SVG images containing embedded JavaScript payloads. If the fileadmin directory is configured to execute scripts or if the files are served directly to other users under the same domain context, the embedded scripts execute within the context of the victim's browser session, potentially leading to session hijacking or credential theft.

It is critical to differentiate this vulnerability from direct Remote Code Execution (RCE) via PHP file uploads. TYPO3 Core implements low-level, global security configurations that reject files with extensions configured in the system's blocklist, which includes .php and other executable formats. These low-level controls are processed within the File Abstraction Layer (FAL) and remain active, preventing attackers from executing arbitrary PHP code on the underlying host.

In addition to client-side threat vectors, the vulnerability introduces risks associated with storage consumption and resource exhaustion. An attacker can repeatedly upload exceptionally large files of any non-blocked format, depleting system storage and leading to a denial-of-service condition. Furthermore, if form finishers are configured to email attachments to administrators, the mail subsystem may distribute malicious payloads to internal staff, increasing phishing risks.

The primary and most effective remediation path for CVE-2026-15305 is to update the TYPO3 CMS installation to a secure version. The TYPO3 security team addressed the vulnerability in version 14.3.5 LTS. Organizations utilizing version ranges between 14.2.0 and 14.3.4 must schedule an immediate upgrade to the patched release to ensure the proper enforcement of MIME type restrictions.

When direct upgrading is delayed due to change-control policies, security administrators can implement temporary detection and filtering rules at the network perimeter. Web Application Firewalls (WAF) can be configured to inspect incoming multipart/form-data POST requests targeting known form-submission endpoints. By writing rules that match file extensions inside form boundaries against expected types, security tools can drop unauthorized files before they reach the application.

System administrators should also perform regular post-facto file audits within the TYPO3 upload directories. Automated scripts can scan the fileadmin/ directory structure for files whose actual MIME signatures do not align with the intended business requirements of the forms. Detecting anomalies such as .svg, .html, or executable archive formats in folders intended solely for .pdf or .png documents indicates potential exploitation attempts.