CVE-2026-57859

CVE-2026-57859 in e107's user preferences system is being filed as a deserialization vulnerability with a CVSS 7.5, and that rating is misleading. The issue isn't the 'array' prefix check that was bypassed — it's that user preferences are stored as serialized PHP expressions that get passed to eval() when materialized. That architectural decision is the real failure, and it's far more serious than the CVSS suggests. The key detail most coverage is missing: this is a persistent RCE that survives remediation. An attacker with database write access — via SQL injection, a compromised admin account, or any third-party plugin with unsafe data handling — writes a serialized e_array payload to the user_prefs column. The eval() fires silently on every page load for that user, indefinitely. Unlike typical injection where the attack window is a single request, this is a one-time write that creates a persistent execution trigger. More critically: if you patch the handler but don't scrub the database column, the payload sits there waiting for any future code path that reads those preferences. I've seen exactly this pattern where a CVE gets marked 'mitigated' and the stored payload outlives the fix. The 'out-of-band database write' prerequisite that some analyses focus on is actually a moving target in e107's plugin ecosystem. The user_prefs column isn't a locked vault — it's written through normal plugin settings, theme preferences, and profile extensions. An attacker who obtains authenticated access often gets both the write path and the trigger path in the same session. The 'out-of-band' framing implies two separate compromises, but the actual attack chain is frequently tighter than that. What should you do? First, audit your e107 database for any rows in user_prefs containing 'e_array' serialized objects — treat any finding as active exploitation, not just theoretical risk. Second, treat the patch as incomplete: verify whether the fix removes eval() entirely or just adds class-name prefixes. If it's the latter, expect future bypasses. Third, and most importantly, assume the architectural pattern is broken across any similar handlers in your codebase. The security boundary isn't the deserialization check — it's whether any code path can write to user_prefs at all. Review plugin and theme code for unsafe data handling, not just the core handler.

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