EUVD-2026-35402
GHSA-jh32-v29g-68pq
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (f4fb688c-4412-4426-b4b8-421ecf27b14a) · only source for this CVE.
CVSS VectorVendor: f4fb688c-4412-4426-b4b8-421ecf27b14a
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
Backend users with write access to the form_definition database table were able to directly create, update, or delete form definition records via DataHandler, bypassing the Form Framework's persistence validation and permission checks. This allowed injecting arbitrary form configurations, re-enabling attack vectors originally addressed in TYPO3-CORE-SA-2018-003, including SQL injection and privilege escalation. This issue affects TYPO3 CMS versions 14.0.0-14.3.3.
AnalysisAI
SQL injection and privilege escalation in TYPO3 CMS 14.0.0 through 14.3.3 allow authenticated backend users holding write permissions on the form_definition table to bypass the Form Framework's persistence validation by submitting form configurations directly through DataHandler. Successful exploitation re-opens the attack class originally fixed in TYPO3-CORE-SA-2018-003, enabling injection of arbitrary form configurations that yield SQLi and elevation of privileges. No public exploit identified at time of analysis; not listed in CISA KEV.
Technical ContextAI
TYPO3 CMS is a widely deployed PHP-based enterprise content management system; its Form Framework (sysext/form) persists rendered form definitions into the form_definition database table. Normal writes are supposed to flow through the FormDefinitionRepository and DatabaseStorageAdapter, which apply the Form persistence manager's validation and permission filters. However, the underlying TYPO3 DataHandler - the generic record persistence layer - accepted writes against form_definition for any backend user with table-level write access, side-stepping the validation pipeline. The root cause maps to CWE-89 (SQL Injection) because injected form configuration payloads are later interpreted by the Form Framework runtime, where unsanitised values reach database operations. The patch (commit c90493c) introduces a new FormDefinitionPersistenceGuard plus a FormDefinitionDataHandlerHook (processDatamapClass/processCmdmapClass) that denies any direct DataHandler create/update/delete against form_definition unless an HMAC-bound invocation grant from the legitimate repository path is in flight.
RemediationAI
Upgrade TYPO3 CMS to the fixed release line per advisory TYPO3-CORE-SA-2026-017 (https://typo3.org/security/advisory/typo3-core-sa-2026-017); the upstream fix is published as commit c90493c13b633f328cf2c066182c90a1655ff0fc, and the released patched version should be confirmed against that advisory before deployment. As compensating controls until patching, audit backend user and group permissions and revoke write access to the form_definition table for any role that does not strictly require it (Web>List / table permissions in backend user TSconfig), and restrict backend access to trusted networks or VPN to shrink the attacker pool given PR:L. Disabling the Form Framework system extension entirely is a heavy-handed but effective workaround on sites that do not use it, at the cost of breaking any existing frontend forms. Avoid relying on web application firewall rules alone, as the bypass is exercised through legitimate backend DataHandler endpoints rather than a distinctive request signature.
Same weakness CWE-89 – SQL Injection
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today