CVE-2026-47349: Missing Authorization in TYPO3 CMS DataHandler Record Restoration

TYPO3 CMS is an enterprise-grade open-source content management system utilizing a granular access control list (ACL) model to restrict backend editors to specific page subtrees, languages, and database tables. The core component responsible for executing write, delete, and modification operations is the DataHandler class. This class serves as the gatekeeper for database operations, ensuring that user and group permissions are strictly enforced during transactions.

The Recycler module (ext:recycler) provides a backend interface for managing soft-deleted records, which are records marked with a deletion flag rather than being permanently removed from the database. This module allows authorized editors to locate and restore deleted content, mapping actions to the DataHandler class. Under normal conditions, a user should only be able to restore items that they have permission to recreate or modify in the current workspace context.

CVE-2026-47349 represents a critical broken access control vulnerability (CWE-862) within the DataHandler::undeleteRecord() method. An authenticated user possessing basic access to the Recycler module can trigger this vulnerability to bypass write restrictions. This flaw enables them to restore and implicitly modify database records on pages and tables for which they lack authorized access.

The root cause of CVE-2026-47349 resides within the authorization flow of DataHandler::undeleteRecord(), which processes the command map (cmdmap) for record restoration. During normal operations, DataHandler must validate that the acting user has modify permissions for the table in question. It must also verify insert permissions for the target parent page where the record is being restored.

In vulnerable versions of TYPO3 CMS, the undeleteRecord() method did not evaluate table-level modification permissions. Any backend user who could interact with the Recycler interface could trigger an undelete action on any table schema supported by the Recycler. This check was omitted regardless of whether their user group configuration (tables_modify) permitted actions on that table.

Furthermore, when evaluating parent page permissions for non-root records (where recordPid > 0), the code retrieved the parent page record using BackendUtility::getRecord('pages', $recordPid, 'deleted', '', false). By specifying only the 'deleted' column, the system omitted crucial ACL fields such as user ownership (perms_user), group ownership (perms_group), and permission bitmasks. Without this metadata, the core was unable to execute any meaningful authorization evaluations, leaving the parent page write permissions unverified.

To fully understand the flow, we examine the vulnerable implementation in DataHandler.php. In this version, the method proceeds to flip the deleted flag without calling any permission check helpers.

// Vulnerable implementation
protected function undeleteRecord(string $table, int $uid): void {
    // ...
    $recordPid = (int)($record['pid'] ?? 0);
    if ($recordPid > 0) {
        // The select field is restricted to 'deleted', omitting crucial perms metadata
        $page = BackendUtility::getRecord('pages', $recordPid, 'deleted', '', false);
        if ($page === null || !isset($page['deleted']) || (bool)$page['deleted'] === true) {
            return;
        }
        // No table check (checkModifyAccessList) and no page-level insert check is performed here
    }
    // ...
}

The patch introduced by the TYPO3 security team mitigates this flaw by enforcing authorization checks at both the table and page level. First, it introduces a verification using checkModifyAccessList($table) to ensure that the user's active configuration allows modifying the target table. Second, the patch modifies the database query to retrieve all columns (*) of the parent page, ensuring that the returned $page record contains all permissions and ownership metadata required for access control evaluation. It then calls hasPermissionToInsert($table, $recordPid, $page) to confirm that the user holds the authorization to write content under that specific parent page node.

// Patched implementation in typo3/sysext/core/Classes/DataHandling/DataHandler.php
protected function undeleteRecord(string $table, int $uid): void {
    // ...
    // Fix 1: Verify table-level modification permissions
    if (!$this->checkModifyAccessList($table)) {
        $this->log($table, 0, SystemLogDatabaseAction::DELETE, null, SystemLogErrorClassification::USER_ERROR, 'Cannot restore "{table}:{uid}" without permission', null, ['table' => $table, 'uid' => $uid]);
        return;
    }
    // ...
    if ($recordPid > 0) {
        // Fix 2: Retrieve all columns (*) to fetch permission metadata
        $page = BackendUtility::getRecord('pages', $recordPid, '*', '', false);
        if ($page === null || !isset($page['deleted']) || (bool)$page['deleted'] === true) {
            return;
        }
        // Fix 3: Assert permission to write to the parent page node
        if (!$this->hasPermissionToInsert($table, $recordPid, $page)) {
            $this->log('pages', $recordPid, SystemLogDatabaseAction::DELETE, null, SystemLogErrorClassification::USER_ERROR, 'Record "{table}:{uid}" can\'t be restored: Insufficient user permissions to target page {pid}', null, ['table' => $table, 'uid' => $uid, 'pid' => $recordPid], $recordPid);
            return;
        }
    }
}

Exploitation of CVE-2026-47349 requires an attacker to possess valid backend credentials with access to the Recycler module. This vulnerability is particularly relevant in installations that utilize multi-tenant structures or delegate content management to regional editors. The attacker does not need high-level privileges, as any role with access to ext:recycler can trigger the flaw.

The attacker starts by browsing soft-deleted records via the Recycler module interface or by directly querying the backend API. They identify a target record belonging to a restricted table (such as tt_content elements containing administrative configurations or credentials) or located under a restricted page path. They then draft a payload targeting the backend's command-mapping interface.

To exploit the flaw, the attacker sends an HTTP request containing a command-mapping payload representing the undelete command. Because the backend fails to validate table permissions or parent page ownership, the transaction is processed, and the record is restored to an active state. This allows the attacker to bypass organizational ACLs and modify backend content.

The security impact of CVE-2026-47349 is classified as privilege escalation. Users configured with minimal write privileges can bypass organizational boundaries, manipulating elements that are managed by administrators or higher-privileged groups. This bypass breaks the integrity assurances of multi-user configurations.

This vulnerability compromises both data integrity and confidentiality. By restoring deleted templates, configuration elements, or standard content blocks on pages where they have no access, users can disrupt localized styling, display outdated data, or modify system behavior. In complex installations, restoring specific records could result in cross-site scripting (XSS) or additional privilege escalation if the restored elements are interpreted as trusted code blocks.

The CVSS v4.0 score of 5.3 reflects a localized impact, as subsequent system parameters remain unaffected. The vulnerability is currently not known to be used in active exploitation, nor has it been linked to ransomware or advanced persistent threat (APT) groups. However, its low attack complexity and the immediate availability of patch details make it a key target for internal threat actors.

The primary remediation path is upgrading to a patched version of TYPO3 CMS. The TYPO3 security team has released security updates for all affected branches, including Extended Long-Term Support (ELTS) and active Long-Term Support (LTS) releases. Organizations should apply these security updates during their immediate maintenance window.

For environments where immediate patching is not viable, the recommended mitigation is to disable access to the Recycler module (ext:recycler) for all non-administrative backend users. Removing the Recycler module from user group configurations effectively closes the primary vector of exploitation by preventing the trigger of the vulnerable undelete command path.

The fix implemented in the official patches is structurally sound for standard configurations because it re-establishes the core permission validation helper functions. However, security teams should verify if custom extensions bypass standard DataHandler routines or implement independent undelete commands. Additionally, special attention must be paid to records stored on root-level pages (PID 0) to ensure that table-level write permissions are configured appropriately, as page-level insertion validation does not apply to the root node.