Roundcube fixes pre-auth file write via session deserialization

TL;DR — Unsafe deserialization in Roundcube’s redis/memcache session handler can enable unauthenticated arbitrary file writes, and an oss-security post points teams to patched Roundcube security releases.

What happened

Roundcube is a widely deployed open-source webmail frontend used to provide browser access to IMAP/SMTP mail systems.

An oss-security mailing list post summarizes Roundcube’s March 18, 2026 security releases and calls out a pre-auth arbitrary file write caused by unsafe deserialization in the redis/memcache session handler (tracked as CVE-2026-35537). The CVE description states that unauthenticated attackers can trigger arbitrary file write operations via crafted session data.

Even when scored conservatively, pre-auth file write in an internet-facing webmail app is operationally high-risk: it’s the kind of primitive that can enable follow-on compromise depending on deployment specifics (writable paths, webroot adjacency, and runtime hardening). The same release announcement also lists multiple additional web-exposure-relevant fixes (XSS, SSRF, and CSRF-bypass categories), reinforcing that this is a “review your exposure and patch” moment for Roundcube operators.

Who is impacted

• Organizations running Roundcube Webmail where deployed versions fall into the CVE record’s affected ranges (versions before 1.5.14 and before 1.6.14).
• Internet-reachable Roundcube deployments using redis or memcache-backed session handling, where attacker-controlled session data could reach the unsafe deserialization path.
• Teams that rely on Roundcube’s web UI as an externally accessible entry point (common in hosted mail, enterprise webmail, and shared services).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "We strongly recommend to update your productive installations of Roundcube with this new versions."

• Inventory Roundcube instances and determine the exact deployed version(s), including container images and baked VM artifacts.
• If you can’t patch immediately, treat this as a potential integrity exposure and reduce blast radius where feasible (e.g., validate that the web user cannot write to sensitive host paths; ensure uploads/cache/temp directories are appropriately isolated).
• After patching, review perimeter logs and application telemetry for anomalous unauthenticated activity that could indicate probing of session-handling paths.