On October 21, 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. BBC News reported that security agencies urged organizations unable to patch in time to consider taking their sites offline, and that several public bodies did so, among them the Finnish government and the Dutch cyber-security agency.

Patching a whole PHP estate takes time: finding every instance, testing, scheduling maintenance. To cover that gap, SKUDONET’s engineering team has prepared a WAF ruleset, PHP2Shell.conf. SKUDONET WAF can help reduce exposure to the known PHP2Shell exploitation vector while you patch, but it does not replace the official PHP patches.

What happened

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both flaws. PHP’s advisory describes them as follows:

  • CVE-2026-109618: out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat that invalid data as valid.
  • CVE-2026-109619: request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use it.

PHP says all installations serving web requests are at risk (PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed), with mod_php the highest. According to the BBC, details of the flaws leaked on social media before the planned release, and Cloudflare reported seeing early attacks.

SKUDONET itself does not use PHP to process user requests, so Enterprise Edition and Community Edition are not directly exposed to this vector. The PHP applications running behind SKUDONET can still be vulnerable, and those are what the ruleset is for.

What PHP2Shell.conf does

The ruleset focuses on CVE-2026-109619, whose publicly documented exploitation path uses the PHP_SESSION_UPLOAD_PROGRESS field of PHP’s session.upload_progress feature. According to SKUDONET’s engineers, it cuts that known vector and reduces the risk from both vulnerabilities, but it is not a solution for either one. PHP’s advisory also warns that other exploitation variants exist, which a WAF cannot see.

The rules detect:

  • requests that include the PHP_SESSION_UPLOAD_PROGRESS field, the main vector;
  • known public exploitation tools, by their User-Agent and their characteristic multipart boundaries;
  • session file poisoning, where PHP code is embedded in the name of an uploaded file;
  • evasion attempts using malformed multipart requests;
  • session identifiers sent in the POST body, which bypass session.use_only_cookies;
  • HTTP 5xx responses after a multipart POST, as an alert signal that a PHP worker has crashed.

The WAF inspects each request in several phases: first the headers (User-Agent, Content-Type, session cookie), then the POST body, both parsed and raw so that manipulation does not get past it, and finally the response code. When it matches the field, the tool or the attack pattern, it cuts the request with an HTTP 403 before it reaches the application. The rules most prone to false positives are first left in log-only mode.

What has been tested

The team validated the rules’ syntax and logic and confirmed that they fire on known attack indicators. We have not run exploitation tests against a vulnerable PHP server, because that means running the exploit, so we make no claim of demonstrated protection against real attacks.

This is the ModSecurity log from a test request with the User-Agent php2shell-test:

Oct 22 10:59:14 ID13905 pound: test, [WAF,service be, backend 172.16.100.254:80,] (7efe5c4b36c0) [client 172.16.100.60] ModSecurity: Access denied with code 403 (phase 1). Matched "Operator `Rx' with parameter `(?i)php2shell' against variable `REQUEST_HEADERS:User-Agent' (Value: `php2shell-test' ) [file "/usr/local/skudonet/config/ipds/waf/sets/PHP2Shell.conf"] [line "17"] [id "99200100"] [rev ""] [msg "PHP2Shell Exploit: Malicious User-Agent detected"] [data "client:172.16.100.60"] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "172.16.100.60"] [uri "/"] [unique_id "179265955471.271463"] [ref "o0,9v47,14"]

It shows the request denied with a 403 in phase 1 (header inspection). The Rx operator matched the pattern php2shell against the User-Agent header, whose value was php2shell-test. The rule that fired is ID 99200100 at line 17 of PHP2Shell.conf, with the message “PHP2Shell Exploit: Malicious User-Agent detected”. The request was for / and came from the client 172.16.100.60. This test covers the User-Agent rule only.

You can run the same safe check on your own farm by sending an inert request, such as a test User-Agent or an invalid session cookie, and confirming that the WAF answers 403.

Applying it

SKUDONET customers can request PHP2Shell.conf by opening a ticket with our support team. The ruleset is designed for SKUDONET’s WAF module: it is imported and associated with the farm that serves the PHP application. Before enabling blocking, SKUDONET recommends:

  1. Start in detection mode and review the logs for a day or two. Applications that upload files (WordPress, admin panels, file managers) are the likeliest to produce false positives. The deserialization and obfuscated-function rules can also trigger on CMS platforms or forums where users paste code.
  2. Confirm each application’s field and cookie names. The upload progress field name is configurable (session.upload_progress.name), and so is the session cookie if it is not PHPSESSID. If either was changed, the rules need adjusting.
  3. Make sure the WAF can see plain HTTP. It can only inspect encrypted traffic where it terminates TLS.

Perimeter filtering does not correct the memory flaw inside PHP.

What to do now

The WAF helps reduce exposure to the known vector while you patch. No mitigation can guarantee that it covers a given attack, which is why PHP’s advisory states that updating is the only safe choice. In order of priority:

  1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later). PHP 8.1 and older no longer receive updates from the PHP project, so check your distribution or LTS vendor for backports, or upgrade. The BBC also notes that PHP can be bundled inside appliances and third-party products, so include those in your inventory.
  2. Until then, set session.upload_progress.enabled = 0 in the server-level PHP configuration and restart the workers (PHP-FPM or Apache). Using ini_set() or .user.ini does not work, because the setting has to apply before the request is processed. PHP notes that this closes the confirmed session paths but not other variants.
  3. Keep the default IPDS protection rules active on every service exposed to the Internet. Many attack types, this one included, share well-known patterns that those rules already cover.

Need assistance securing your applications?

If you have questions about these PHP vulnerabilities or how SKUDONET WAF can help, contact our team.

Contact the SKUDONET Team