CVE-2026-77647

CVE-2026-77647 in SPIP exposes a structural failure in how the CMS handles data serialization. This is not a typical injection vulnerability where user input is filtered — it's a case where data and code generation paths have become architecturally entangled. The vulnerability centers on SPIP's use of `var_export()` as a serialization mechanism combined with the function's behavior when its output flows into evaluation contexts. `var_export()` produces parseable PHP syntax, not safely escaped output. When '<' characters in user-controlled data reach these evaluation paths, they can terminate string contexts and inject arbitrary PHP code. What makes this critical: the blast radius extends far beyond a single eval() call. If SPIP uses this pattern in one serialization path, the architectural entanglement of data and code generation likely exists in multiple subsystems. The August 2026 in-the-wild exploitation timeline confirms attackers understood this attack class. Your priority as a defender: verify what SPIP 4.4.20 actually changed. The patch either eliminated the eval path entirely, sanitized the data before var_export(), or added filtering to the output — each represents a different security posture. More importantly, audit your SPIP installation for other `var_export()` calls that may process user-adjacent data and feed into include, require, or eval operations. The pattern has appeared in WordPress plugins and Drupal modules since 2013; SPIP's age suggests it accumulated these calls over a decade with varying awareness of the risk. The uncomfortable reality: a CVSS 9.8 understates a structural flaw with horizontal reach. Exploitation doesn't require authentication or complex conditions — it needs the right data path to trigger. Patch the CVE, but treat it as closing one detonation point in an architecture where the explosive material may persist elsewhere.

Reviewed through automated stages and approved by a human before publication.