CVE-2024-55637

What it actually does

The vulnerability adds a potential PHP Object Injection vector in Drupal core classes by allowing unsafe input to reach unserialize() when a separate flaw is present, which could enable object instantiation and property manipulation leading to Remote Code Execution if further chained.

Why it matters to the business

Organizations running older Drupal versions face elevated risk of full site compromise only if another unrelated vulnerability exists to supply malicious serialized data; the low EPSS score and absence from KEV indicate limited standalone threat but require prompt patching to eliminate the deserialization exposure across affected 8.x through 11.x releases.

How an attack unfolds

An attacker must first identify and exploit a separate input-handling flaw in a Drupal site or extension to pass attacker-controlled serialized PHP objects into unserialize() calls on core classes; once that vector exists, the injected objects can trigger gadget chains for code execution, though no such chaining exploits are known in core itself.

How to fix it

Upgrade Drupal core to 10.2.11 or later, 10.3.9 or later, or 11.0.8 or later; apply the type-hinting changes from commit 3712d59414f556474f990a503c3f7c295f8c719f to any custom subclasses of affected core classes; ensure all extensions also enforce strict types on properties.

How to confirm the fix worked

Verify installed Drupal version is at or above the fixed releases; inspect custom class extensions for addition of type declarations matching the core changes; run static analysis or unit tests that attempt unserialize() with unsafe input to confirm TypeError enforcement.

Typical attack path

1. Locate or introduce a secondary vulnerability allowing arbitrary input to a Drupal unserialize() call
2. Craft a serialized payload targeting typed properties in core classes that lack strict type enforcement in subclasses
3. Deliver the payload to trigger object injection and property manipulation
4. Leverage resulting gadget chain for remote code execution if mitigation types are absent

How to detect it

Search web server and application logs for unexpected serialized PHP object strings reaching unserialize() functions; review access logs around the publication date for anomalous POST or query parameters containing serialized data; check for any post-exploitation artifacts such as unexpected file writes or process spawns following deserialization events.

What your security team should do

• Immediately upgrade all Drupal instances to the fixed versions listed in remediation guidance
• Audit custom code extending core classes for missing type hints and add them to prevent TypeError bypasses
• Review application logs and input paths for any prior unserialize() usage that could have accepted external data
• Monitor EPSS trend and re-assess after 30 days given the modest upward movement