Webmail Patched for PHP Zero-Day (CVE-2026-109618 & CVE-2026-109619)

Posted on October 21, 2026 by Purelymail Team

You may have seen the news today regarding two PHP zero-day vulnerabilities (CVE-2026-109618 and CVE-2026-109619). Our webmail (Roundcube) is the only service at Purelymail that runs PHP, so we wanted to share a quick update on what happened and our patching timeline.

Both vulnerabilities are fully resolved, and webmail remained online with zero downtime.

What the Vulnerabilities Were

The issue, nicknamed “PHP2Shell”, involves two separate bugs in PHP:

  • CVE-2026-109618: A memory corruption bug during request cleanup. If PHP hits an out-of-memory error while parsing multipart form data (like file uploads), request state is left partially initialized, leading to memory corruption when the request terminates.
  • CVE-2026-109619: A use-after-free flaw. Under certain error conditions, PHP worker processes can hold onto pointers to freed request memory, which can then be reused on subsequent requests.

Further technical details can be found in PHP’s official security advisories for CVE-2026-109618 and CVE-2026-109619.

How We Handled It

When the exploit leaked overnight, our first step was disabling session.upload_progress in our PHP configuration (session.upload_progress.enabled = Off). Roundcube doesn’t use this feature anyway (it handles file uploads through standard AJAX/HTML5), so turning it off blocked the exploit path immediately without affecting webmail functionality.

Later that morning, we also added request-size caps to prevent oversized multipart payloads from triggering PHP’s memory allocation bug.

Once PHP 8.4.27 was released upstream with source fixes for both CVEs, we tracked the update as it moved through the official PHP Docker image and into Roundcube’s container. We then pulled Roundcube 1.6.20, applied our configuration patches, and deployed the update to production with zero downtime.

Timeline

  • ~03:00 UTC: Exploit details for the PHP zero-days leak online.
  • ~05:30 UTC: Initial fix prepared to disable PHP session upload progress.
  • ~11:15 UTC: First mitigation deployed to production, disabling session upload progress to block the exploit path.
  • ~14:00 UTC: PHP officially releases source patches (PHP 8.4.27).
  • ~16:15 UTC: Second interim mitigation deployed to production, adding request body limits.
  • ~17:30 UTC: Official Docker PHP base image is published.
  • ~19:10 UTC: Roundcube publishes an updated container image built on PHP 8.4.27.
  • ~21:30 UTC: Deployed Roundcube 1.6.20 and PHP 8.4.27 to production with zero downtime.

Current Status

Webmail is up to date on Roundcube 1.6.20 and PHP 8.4.27, and everything is working normally. We also reviewed our container logs across the past week and found no indicators of compromise or exploit attempts. Our IMAP, POP3, and SMTP services do not use PHP and were never affected.

No action is needed on your end. If you notice any issues, please reach out to us on Discord or through our helpdesk.