How we blocked PHP2Shell for every app on Apply.Build

On 20 October, details of two critical PHP vulnerabilities leaked before a fix was available. Known together as PHP2Shell, CVE-2026-109618 and CVE-2026-109619 are both rated 9.2, and either one can let an unauthenticated attacker run code on the server.

Both bugs are in how PHP reads form fields and file uploads, which happens before any application code runs. Updating your framework or adding checks to your app doesn't help.

The PHP team released fixed versions the following day. Until apps could be updated, we wanted them protected without their owners having to do anything, so we added new rules to the Apply.Build firewall.

What the vulnerabilities are

CVE-2026-109618 is in how PHP handles running out of memory. If memory runs out while PHP is reading request data, cleanup can treat half-built internal data as valid, and an attacker can turn that into code execution. A request can be built to make PHP use far more memory while parsing it than the request itself takes up.

CVE-2026-109619 lets internal request state outlive the memory behind it. A later request handled by the same PHP worker can then use that stale state. It is reached through PHP's session upload progress feature.

Both affect PHP 5.4 and later, under both PHP-FPM and Apache mod_php.

How the firewall handles it

Every request to an app on Apply.Build passes through our firewall before it reaches the app. Alongside the OWASP Core Rule Set it runs our own rules, and when it bans a client, that client is shut out of every app on the platform.

We wrote the new rules from the PHP advisories and from research by security teams who had reproduced the attacks. The rules block requests that:

• send a PHP_SESSION_UPLOAD_PROGRESS field in an upload, the entry point for CVE-2026-109619
• use field names nested unusually deep, like a[][][]…, which multiply the arrays PHP builds
• contain an unusual number of file parts, including empty ones that PHP does not count towards max_file_uploads
• send extremely long field names in regular forms, the method used in public reproductions

Normal traffic doesn't look like this, so the rules can afford to be strict.

The rules cover both regular forms and file uploads. A client that sends one of these requests is blocked and banned.

Inspecting request bodies

Catching these requests means reading request bodies. This is how the firewall handles them:

• Large request bodies are inspected.
• File uploads are inspected. The rules look at how the upload form is put together, so normal uploads keep working.
• For large requests, the firewall first checks whether the client is already banned, so a banned client is turned away before it uploads anything.

A common stopgap elsewhere was to block all file uploads until PHP was patched. That stops the attacks, but it also breaks every app that accepts uploads. Our rules block only the attack requests.

Update PHP

The firewall rules cover the attacks known today, but only updating PHP fixes the vulnerabilities themselves.

Every app gets this firewall and these rules on every plan, including the free tier.

Platform numbers