Two public-sector security bodies on either side of the Atlantic today warned organisations about two critical vulnerabilities in PHP, the server-side language behind a large share of the web's publishing and commerce sites. CERT-EU, the cybersecurity service of the European Union's institutions, published Security Advisory 2026-018 at 15:20:18 on October 21, 2026, saying both flaws can allow unauthenticated remote code execution and carry a CVSS score of 9.2. The US National Security Agency issued a shorter statement from Fort Meade, advising organisations that cannot update immediately to take affected systems offline.

In Short

PHP, the programming language that runs a huge number of websites, has two serious holes that let an attacker take control of a web server with a single request. Anyone running a website on PHP, including many WordPress publishers and online shops, is affected, and early attack code is already circulating, according to CERT-EU. Fixed versions came out today, and both the NSA and CERT-EU say servers that cannot be updated right away should be cut off from the public internet until they are.

Two advisories, one day

The two documents differ sharply in length and in what they say. The NSA statement, dated Oct. 21, 2026 and titled "NSA Advisory: PHP Updates", runs to five sentences. It names no vulnerability identifiers, no version numbers and no severity scores. CERT-EU's advisory, by contrast, lists two CVE numbers, two GitHub security advisory identifiers, the patched releases on four branches, the server configurations at risk and more than a dozen temporary mitigations.

"Effective Immediately, all organizations using PHP for their systems are advised to be prepared for an update addressing two critical vulnerabilities," according to the NSA. The agency added that "PHP is widely used for web applications" and that "these vulnerabilities often provide a direct path to the server's file system or database." It closed with a line that promises more: "NSA will follow up shortly with more specific guidance."

CERT-EU's advisory carries a version history showing two releases on the same day: v1.0, the initial publication, and v1.1, described as "Updates with additional information." The release time printed on the page is 21-10-2026 15:20:18. The page does not state a time zone. CERT-EU's offices are at Rue de la Loi 107 in Brussels, but that is not a basis for assuming which clock the timestamp uses.

A difference in tense

The two texts do not describe the same moment. The NSA statement asks organisations "to be prepared for an update," phrasing that reads as if fixes were still to come. CERT-EU states that "the PHP team released the fixes today, 21 October 2026 at 13:30 UTC." The NSA page shows a date but no time, so it is not possible to tell from the documents whether the NSA text was written before the 13:30 UTC release or simply worded loosely. The practical difference is significant: according to CERT-EU, patched versions are already available.

Offline or isolated

The agencies also differ on the fallback for systems that cannot be updated at once. "If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated," according to the NSA. CERT-EU's wording is narrower and softer. "Where that is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified," according to the advisory's summary. The NSA's version covers "the system"; CERT-EU's covers internet-facing applications and uses "consider."

How the disclosure unfolded

According to CERT-EU, the PHP project announced on October 20, 2026 an upcoming security release addressing two critical vulnerabilities. The advisory cites the PHP project's news archive entry for that date. "Public reports indicated that these vulnerabilities could lead to remote code execution," according to CERT-EU, which footnotes two sources for that statement: a post on the Mastodon server cyberplace.social by the account @GossiTheDog and a post on X by the account @watchtowrcyber. PPC Land has not independently reviewed either post.

The fixes followed a day later. CERT-EU lists them as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. "Technical details are now being discussed publicly, and initial proofs of concept (PoCs) have begun to circulate," the advisory states. "This raises the likelihood that attackers are already exploiting the vulnerabilities."

That last sentence is an assessment of likelihood, not a report of confirmed attacks. Neither CERT-EU nor the NSA says in these documents that exploitation has been observed.

The two vulnerabilities

CVE-2026-109618: memory corruption during out-of-memory handling

The first flaw, CVE-2026-109618, is tracked on GitHub as GHSA-w8hw-w9fx-j79w. CERT-EU gives it a CVSS score of 9.2 and says it "allows remote code execution through memory corruption during out-of-memory (OOM) handling." The advisory does not specify which CVSS version produced the score.

The mechanism, as CERT-EU describes it, sits in how PHP enforces its own memory ceiling. PHP applies the user-configurable memory_limit setting "by using longjmp() to abort any request that exceeds the limit, which raises an OOM error." That abort can land at an awkward moment. According to the advisory, it "can interrupt PHP while internal request data is only partially initialised, for example while parsing a form-based file upload." The cleanup routine that follows "may then treat the invalid data as valid and try to free memory that was never initialised." The memory in question, CERT-EU notes, "may still contain data from earlier allocations controlled by the attacker."

Put differently: a request pushed past the memory limit at the wrong moment can leave PHP freeing memory an attacker has shaped, which is the route CERT-EU describes to remote code execution.

CVE-2026-109619: stale global state

The second flaw, CVE-2026-109619, is tracked as GHSA-6wmf-4rv5-p3rp, also with a CVSS score of 9.2. According to CERT-EU, it "allows remote code execution through stale global state." Internal state belonging to one request "can survive after its backing memory has been freed, for example after a fatal error." The consequence is that "a later request handled by the same worker may use that stale state before normal initialisation resets it."

This matters because most production PHP deployments reuse worker processes across many requests. A fault left behind by one request becomes a hazard for the next one served by that worker.

Every web-facing installation

CERT-EU's statement of scope is broad. "Every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed," according to the advisory. The PHP team, it adds, "considers mod_php the highest-risk setup." And the attack does not depend on a weakness in the application sitting on top of PHP: "A demonstrated exploit shows that one unauthenticated request can trigger the attack before any application code runs," according to CERT-EU.

That last point removes a defence many site operators rely on. Hardening a content management system, a plugin or a checkout script does nothing if the interpreter is compromised before any of that code executes.

Affected versions

CERT-EU lists the following as affected:

  • PHP 8.5 versions prior to 8.5.12
  • PHP 8.4 versions prior to 8.4.27
  • PHP 8.3 versions prior to 8.3.36
  • PHP 8.2 versions prior to 8.2.35
  • End-of-life branches (PHP 8.1 and older), "which no longer receive updates from the PHP project"

The exposure extends beyond servers that run PHP visibly. "Many commercial and open-source products use PHP as a backend technology - these could be also affected, even if they do not directly expose a PHP installation," according to CERT-EU. The advisory points to a GitHub repository maintained by NCSC-NL, the Dutch National Cyber Security Centre, named php2shell, which it says helps "identify third-party software that embeds PHP and may be impacted by these vulnerabilities." For organisations running packaged software they did not build, that list is the difference between knowing and guessing whether PHP is inside.

What CERT-EU recommends

"CERT-EU strongly recommends updating all affected PHP installations as soon as possible to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35," according to the advisory. It then breaks the update path down by how PHP was installed.

Distribution packages. According to CERT-EU, "Linux distributions and LTS vendors received the patches in advance." That suggests packaged updates from major distributions may already be available or close to it, though the advisory names no specific vendors.

End-of-life versions. For PHP 8.1 and older, CERT-EU says "some distributions and LTS vendors provide backported fixes." Because of the severity, "the PHP security team has also published minimal source backports for PHP 7.4, 8.0 and 8.1 for organisations that build from source or have no LTS vendor." The advisory does not mention backports for branches older than 7.4.

rpms.remirepo.net. The advisory singles out one repository. It describes rpms.remirepo.net as "volunteer-maintained" and says it "will not have updates on release day." According to CERT-EU, "the PHP team urges users to switch to distribution packages or build from source."

Temporary mitigations, with caveats

CERT-EU devotes a long section to stopgaps, and it is explicit about their limits. "Only an update fully fixes these vulnerabilities. The measures below reduce exposure to specific attack paths but do not make an installation safe," according to the advisory.

For CVE-2026-109618

The mitigations for the out-of-memory flaw focus on removing or bounding the memory-limit failure that triggers it:

  • Setting memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and checking that no pool, directory or application setting restores a finite limit. CERT-EU says this "removes the controllable memory limit failure, but an underlying allocation failure can still reach the vulnerable code path."
  • A low post_max_size: 8M for applications that do not need file uploads, 32M where uploads are required, with upload_max_filesize kept below post_max_size.
  • Limits at the web server or proxy level on decoded request size, input field count, multipart part count, header count and nesting depth. These, according to CERT-EU, "must also cover requests without a usable Content-Length."
  • A container or cgroup memory limit as an availability boundary, preferably with a policy that kills only the affected worker. The advisory warns against RLIMIT_AS or RLIMIT_DATA as a substitute, "because they can trigger the vulnerable allocation failure."

There is a visible tension in the first item. Lifting PHP's memory ceiling removes one trigger for the flaw but also removes a guard against runaway memory use, which is presumably why CERT-EU pairs it with the container-level limit.

For CVE-2026-109619

The stale-state mitigations each close a known path rather than the flaw itself:

  • Setting session.upload_progress.enabled=0 and restarting every worker, applied in php.ini, an FPM pool or server configuration that takes effect before request parsing. CERT-EU says not to rely on ini_set() or FPM .user.ini, and that the setting "blocks the confirmed session paths but not other variants."
  • On PHP 8.5, setting fatal_error_backtraces=0 and restarting every worker. According to CERT-EU, this "blocks the confirmed fatal backtrace path only."
  • Removing invalid or deprecated per-request settings that emit diagnostics before initialisation. Hiding diagnostics with error_reporting, display_errors or the @ operator "does not help," according to the advisory.
  • Fixing fatal errors and execution timeouts that attackers can reach, "including failures in callbacks, upload or import processing, and cleanup."

Who issued the European advisory

CERT-EU describes itself on its website as having been "born in 2011." It is administratively hosted within the Directorate-General for Digital Services of the European Commission, but "our nature is that of an inter-institutional provider," according to the organisation, governed by the Interinstitutional Cybersecurity Board, currently chaired by the European Parliament. It serves all EU institutions, bodies, offices and agencies, which it counts as "90+ constituents," with a staff of "more than 60" cybersecurity experts.

The organisation lists memberships of the CSIRTs Network, the European Government CSIRTs Group, FIRST and Trusted Introducer, structured cooperation with ENISA, the EU Agency for Cybersecurity, and a 2016 technical agreement with the NATO Cyber Security Centre to exchange cybersecurity information. Its legal basis is the EU regulation laying down measures for a high common level of cybersecurity at the Union's institutions, published in the Official Journal.

That constituency matters for reading the advisory. CERT-EU writes for EU institutions; its guidance is published openly and covers software used everywhere, but its formal audience is not private businesses. The NSA statement, likewise, is a press release from an intelligence agency and not a binding directive.

Why this matters for marketers and publishers

PHP is not an abstract dependency for the advertising and publishing industry. Much of the open web's content layer runs on it. A Cloudflare analysis covered by PPC Land in April described a WordPress plugin as a PHP script with unrestricted access to the database and filesystem, and quoted Cloudflare's claim that "96% of security issues on WordPress sites originate in plugins." The PHP flaws described today sit one layer below that: in the interpreter, before plugin or theme code runs.

The patching record of that ecosystem is not encouraging. In September, 20i found that 88% of WordPress sites were running outdated software, with 87.62% of more than 44 million sites worldwide on versions below WordPress 7.1, and micro-businesses showing the highest rate at 88.42%. Those figures concern the WordPress application, not the PHP runtime, and PPC Land has no comparable count for PHP versions. But they describe the same population of site owners, many of whom depend on hosts or agencies to apply server updates.

For advertisers and publishers the risks are specific. A compromised server can serve altered pages, inject redirects or scripts into ad slots, or leak first-party customer data stored in the database the NSA statement mentions. Criminal use of injected scripts and redirects is a recurring theme in the malvertising problem PPC Land has tracked. Landing pages, lead forms and e-commerce checkouts built on PHP stacks are directly in the affected category if they serve web requests, according to CERT-EU's scope statement.

The timing also follows a period in which vulnerability exploitation has become a leading entry point. The 20i coverage cited Verizon's 2026 Data Breach Investigations Report, which put vulnerability exploitation as the initial access vector in 31% of breaches. Earlier this year, Cloudflare's 2026 threat report described CVE-2026-22813, a critical unauthenticated remote code execution flaw in markdown rendering pipelines scored 9.4. Security research is also moving faster: in June PPC Land reported on a Firefox security harness that fixed 271 bugs, some 15 to 20 years old, found with an AI agent. Shorter gaps between disclosure and working exploit code are consistent with CERT-EU's note that proofs of concept were already circulating within a day of the PHP project's pre-announcement.

The exposure question is complicated by hosting. Shared and managed hosting customers frequently do not control the PHP version or the FPM pool configuration that CERT-EU's mitigations depend on. CERT-EU's own point about open-source and commercial products that embed PHP extends the issue to tools in the marketing stack that may never be described to their users as PHP software.

What remains unclear

Several questions are not answered in the documents. The NSA promised "more specific guidance" but had not published it in the material reviewed for this article. Neither agency reports confirmed exploitation. CERT-EU does not specify the CVSS version behind its 9.2 scores, nor the time zone of its release timestamp. The advisory names five server setups as at risk and calls mod_php the highest-risk one, but gives no estimate of how many installations run each version. And the NSA's "prepared for an update" wording sits awkwardly beside CERT-EU's statement that fixes shipped at 13:30 UTC on the same day.

Timeline

Summary

Who: The US National Security Agency and CERT-EU, the cybersecurity service of the EU institutions, warning all organisations that run PHP. The fixes come from the PHP project; the Dutch NCSC maintains a list of products that embed PHP.

What: Two critical PHP vulnerabilities, CVE-2026-109618 (memory corruption during out-of-memory handling) and CVE-2026-109619 (stale global state), each scored CVSS 9.2 by CERT-EU and each allowing unauthenticated remote code execution. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source backports for 7.4, 8.0 and 8.1.

When: The PHP project pre-announced the release on October 20, 2026. Fixes shipped today, October 21, 2026, at 13:30 UTC, and both agencies published their advisories today.

Where: Every PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, according to CERT-EU. The NSA statement was issued from Fort Meade, Maryland; CERT-EU is based in Brussels.

Why: According to CERT-EU, a single unauthenticated request can trigger the attack before application code runs, and proofs of concept are circulating. For publishers and advertisers, much of the web's content and commerce layer, including WordPress sites, landing pages and checkouts, runs on PHP.