CVE-2025-59022: 
PHP vulnerability analysis and mitigation

CVE-2025-59022 is a missing authorization vulnerability in the TYPO3 CMS recycler module that allows authenticated backend users to delete arbitrary data from any database table defined in the Table Configuration Array (TCA), regardless of their actual table-level permissions. It affects TYPO3 CMS versions 10.0.0–10.4.54, 11.0.0–11.5.48, 12.0.0–12.4.40, 13.0.0–13.4.22, and 14.0.0–14.0.1. The vulnerability was disclosed on January 13, 2026, by the TYPO3 security team (advisory TYPO3-CORE-SA-2026-003), with patches released the same day. It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, TYPO3 Advisory).

The root cause is CWE-862 (Missing Authorization): the deleteRecords action in the ext:recycler AJAX route (RecyclerAjaxController) lacked proper authentication checks, and the DeletedRecords::deleteData() method called DataHandler->deleteAction() with $noRecordCheck = true, bypassing all tables_modify permission checks. This meant any backend user with recycler module access could hard-delete records from any TCA-defined table without needing explicit permission to that table. The fix involved setting $noRecordCheck = false in the recycler's delete path, adding a checkModifyAccessList() call in DataHandler->deleteAction(), and adding an isDeleteAllowed() authorization gate in the AJAX controller that enforces the mod.recycler.allowDelete UserTSconfig option (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker with recycler module access to permanently hard-delete arbitrary records from any database table in the TYPO3 installation, including pages, content elements, user accounts, and other critical site data. This can render the website completely unavailable and result in irreversible data loss, as hard-deleted records bypass TYPO3's soft-delete mechanism and are removed directly from the database. There is no confidentiality impact, but the integrity and availability impacts are both rated High (GitHub Advisory, TYPO3 Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires low-privilege authenticated access (a backend user account with recycler module access), making it an insider threat or post-compromise escalation scenario rather than an unauthenticated attack. The EPSS score is approximately 0.039% (very low probability of exploitation in the near term), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a TYPO3 CMS installation running an affected version (10.0.0–10.4.54, 11.0.0–11.5.48, 12.0.0–12.4.40, 13.0.0–13.4.22, or 14.0.0–14.0.1) with the recycler extension (typo3/cms-recycler) installed and enabled.
2. Obtain backend access: Authenticate to the TYPO3 backend (/typo3/) using a low-privilege backend user account that has been granted access to the Recycler module.
3. Identify target tables: Browse the recycler module to enumerate soft-deleted records across various TCA-defined database tables, including tables the user would not normally have tables_modify permission for.
4. Trigger unauthorized deletion: Send a crafted AJAX POST request to the recycler's deleteRecords action endpoint, specifying records from arbitrary tables (e.g., pages:1, be_users:2) in the request payload. In unpatched versions, the $noRecordCheck = true flag bypasses all permission validation.
5. Achieve data destruction: The DataHandler->deleteAction() call hard-deletes the targeted records directly from the database, permanently destroying critical site data and potentially rendering the website unavailable (GitHub Advisory, Patch Commit).

• Logs: TYPO3 system log (sys_log table) entries showing hard-delete operations (action = DELETE) on tables the acting backend user does not have tables_modify permissions for; look for log entries with Cannot delete "{table}:{uid}" without permission (added by the patch, absent in vulnerable versions).
• Logs: Web server access logs showing repeated POST requests to the TYPO3 recycler AJAX endpoint (typically /typo3/ajax/recycler) with deleteRecords action from a single backend user session.
• Database: Sudden disappearance of records from critical tables (e.g., pages, tt_content, be_users, fe_users) without corresponding soft-delete flags set, indicating hard deletion.
• Application: Website returning errors or blank pages due to missing page tree records or essential configuration records being permanently deleted.
• TYPO3 Backend: Recycler module access logs showing activity from users who should not have delete permissions based on their group configuration (Patch Commit, TYPO3 Advisory).

Update to the patched TYPO3 versions immediately: 10.4.55 (ELTS), 11.5.49 (ELTS), 12.4.41 (LTS), 13.4.23 (LTS), or 14.0.2, depending on your current branch. As a temporary workaround prior to patching, restrict recycler module access to only fully trusted administrator-level backend users, and ensure the UserTSconfig option mod.recycler.allowDelete is not set to 1 for non-admin users. Additionally, review and audit all backend user group permissions to minimize the number of accounts with recycler module access (TYPO3 Advisory, GitHub Advisory).

The vulnerability was reported by Sven Jürgens and Daniel Windloff, and fixed by TYPO3 security team member Elias Häußler. The TYPO3 project published the advisory (TYPO3-CORE-SA-2026-003) simultaneously with the patch release on January 13, 2026, following responsible disclosure practices. Community coverage was limited to standard vulnerability aggregators and security feeds, with no notable independent researcher commentary or significant social media discussion observed (TYPO3 Advisory, GitHub Advisory).