CVE-2026-49740: 
PHP Analyse et atténuation des vulnérabilités

CVE-2026-49740 is an insecure deserialization vulnerability in TYPO3 CMS, titled "TYPO3 CMS has Insecure Deserialization via Core API" (security bulletin TYPO3-CORE-SA-2026-018). TYPO3's cache frontend (VariableFrontend) and persistent key-value store (Registry) deserialized PHP payloads without integrity validation or class restrictions, enabling PHP Object Injection and potentially Remote Code Execution via gadget chains. Affected versions include TYPO3 CMS before 10.4.57, 11.0.0–11.5.51, 12.0.0–12.4.46, 13.0.0–13.4.31, and 14.0.0–14.3.3. The vulnerability was published on June 9, 2026, with patches released on June 12, 2026. It carries a CVSS v4 base score of 6.3 (Medium) (Github Advisory, RedHat CVE).

The root cause is CWE-502 (Deserialization of Untrusted Data): both VariableFrontend (cache frontend) and Registry (the sys_registry database table) called PHP's unserialize() on stored data without any HMAC integrity check or allowed_classes restriction, meaning any class present in the PHP runtime could be instantiated during deserialization (Github Advisory). An attacker who can write to the cache storage backend (e.g., file system cache, Redis, database) or directly to the sys_registry table can inject a crafted serialized PHP payload referencing a gadget class with a user-defined __destruct() or __wakeup() method, which is then triggered when TYPO3 reads and deserializes the stored value (TYPO3 Commit). Exploitation requires direct local write access to the underlying storage (SQL database or file system), making this a local attack vector with low privileges required and no user interaction needed. The fix introduces two complementary mitigations: AuthenticatedMessageDeserializer (HMAC-signed payloads for VariableFrontend) and DenyListDeserializer (runtime gadget-class blocking for Registry) (TYPO3 Commit).

Successful exploitation allows an attacker with write access to TYPO3's cache or registry storage to achieve PHP Object Injection, which — when a suitable gadget chain exists in the application's class hierarchy — can escalate to Remote Code Execution on the server (Github Advisory). The CVSS v4 scoring reflects high subsequent-system impacts across confidentiality, integrity, and availability (SC:H/SI:H/SA:H), meaning a successful exploit could compromise not just the TYPO3 instance but also adjacent systems reachable from the server. Data exfiltration, web shell installation, lateral movement within the hosting environment, and full server takeover are all plausible outcomes depending on available gadget chains (RedHat CVE).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Github Advisory). The EPSS score is approximately 0.588% (43rd percentile), indicating a relatively low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by the requirement for local write access to the storage backend, which limits the attacker pool to those who have already compromised the database or file system, or who hold privileged database credentials.

1. Gain write access to storage: Obtain write access to the TYPO3 cache storage backend (e.g., file system cache directory, database cache table) or directly to the sys_registry database table — for example, via a compromised database account, SQL injection in another component, or file system access.
2. Identify a gadget chain: Enumerate PHP classes loaded by the TYPO3 application (including third-party Composer packages) to identify a class with a user-defined __destruct() or __wakeup() method that can be chained to execute arbitrary code or commands.
3. Craft a malicious serialized payload: Using a tool such as PHPGGC (PHP Generic Gadget Chains), generate a serialized PHP object payload targeting the identified gadget class, e.g., phpggc <gadget-chain> exec 'id' -s.
4. Inject the payload: Write the crafted serialized string directly into the cache storage backend (e.g., insert/update a row in the cache database table or overwrite a cache file) or into the sys_registry table's entry_value column.
5. Trigger deserialization: Wait for or trigger TYPO3 to read the poisoned cache entry or registry value — this occurs during normal page requests or backend operations that cause TYPO3 to call VariableFrontend::get() or Registry::loadEntriesByNamespace(), which previously called unserialize() without restrictions.
6. Achieve code execution: The gadget chain's magic methods execute during deserialization, running attacker-controlled commands on the server under the web server process account (Github Advisory, TYPO3 Commit).

• Database: Unexpected or anomalous entries in the sys_registry table with entry_value fields containing PHP serialized strings beginning with O: (object notation) referencing unusual class names; similar anomalies in cache database tables.
• File System: Cache files in the TYPO3 cache directory (e.g., typo3temp/var/cache/) containing serialized PHP object payloads (strings starting with O:<number>:) rather than expected scalar or array data; new or modified files in the web root or TYPO3 installation directory not associated with a deployment.
• Logs: PHP error log entries referencing unserialize() warnings or __PHP_Incomplete_Class objects; TYPO3 application logs showing unexpected DeserializerException errors after patching (indicating attempted exploitation of a patched system); web server access logs showing unusual POST requests to TYPO3 backend endpoints shortly before anomalous behavior.
• Process: Unexpected child processes spawned by the PHP-FPM or web server process (e.g., bash, curl, wget, python, nc) that are not part of normal TYPO3 operation; outbound network connections from the web server to unknown external IPs.

Upgrade TYPO3 CMS to one of the patched versions: 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, or 14.3.3 LTS (Github Advisory, TYPO3 Advisory). As a configuration-level workaround prior to patching, restrict write access to the TYPO3 cache storage backends and the sys_registry database table to only authorized application processes, and enforce strict database user privilege separation. Additionally, monitor for unauthorized write attempts to cache and registry storage. The patched versions introduce AuthenticatedMessageDeserializer (HMAC-signed cache payloads) and DenyListDeserializer (gadget-class blocking for the registry), and also expose a $TYPO3_CONF_VARS['SYS']['deserialization']['allowedClassNames'] configuration option for explicitly permitting reviewed classes (TYPO3 Commit).

The vulnerability was reported by multiple independent researchers including "z3rco", Chowdhury Faizal Ahammed, Rick Larabee, Vitaly Simonovich, Nozomu Sasaki, Mert Akdag, "tikket", and Shafi Almutairi, and was fixed by TYPO3 core & security team member Oliver Hader (Github Advisory). No significant broader media coverage or notable social media reactions have been identified beyond the official advisory and standard vulnerability database entries.