# The PHP vulnerability and your WordPress site (CVE-2026-109618, CVE-2026-109619) > Two critical flaws in PHP itself let anyone run code on a server with no login. What happened on 21 October 2026, which PHP versions carry the fix, how to check yours in two minutes, the message to send your host, and what to look for afterwards. Source: https://www.respira.press/blog/php-vulnerability-cve-2026-109618-wordpress --- On 21 October 2026 the PHP project shipped an emergency release for two flaws in PHP itself. Each lets someone with no account run code on a web server. WordPress runs on PHP, so this reaches every WordPress site until its host updates PHP. The short version: find out which PHP your site runs, compare it with the table below, and if it is older, send your host the message further down. No plugin can do this part for you. The rest of this page is the detail behind each step. ## What happened The PHP project gave advance notice on 20 October and released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. The two flaws are **CVE-2026-109618** and **CVE-2026-109619**, each rated 9.2 out of 10 on CVSS 4.0, and both allow unauthenticated remote code execution. In the advisory's words, all PHP installations serving web requests are at risk, and the risk is highest for Apache with mod\_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." The response was unusual. CERT-EU advised that organisations "should consider isolating internet-facing applications from public networks until a fix is available." Government services in the Netherlands, Finland, France and Australia were taken offline for a while, and Pinboard, parts of Wikipedia, 4chan and Something Awful went offline to wait for the patch, according to NBC News and The National. OpenAI said it helped find the flaws and reported them to PHP. Whether attacks are already happening depends on who you ask. CISA said it had not observed exploitation at the time of its statement. Cloudflare's CTO wrote: "We are seeing early attacks emerging and are updating mitigations as new vectors show up." Patchstack said there were reports of active exploitation. With a public fix, the safe assumption is that the details will be reverse engineered quickly. WordPress.org published its own notice the same day. It says the flaws affect any server running PHP, not only WordPress, that **no WordPress update is required or planned**, and that hosts may already be updating PHP and adding web application firewall rules. Its advice to site owners is the same as this page's: check with your host and update PHP as soon as possible. ## The fixed PHP for your branch Compare your site against the fixed release for *its own branch*. A site on 8.2.35 is fixed. A site on 8.4.26 is not, even though the number is higher. | PHP branch | First fixed release | | --- | --- | | 8.5 | **8.5.12** | | 8.4 | **8.4.27** | | 8.3 | **8.3.36** | | 8.2 | **8.2.35** | | 8.1 and older | No fix from the PHP project | PHP 8.1 and older no longer receive updates from the PHP project. Given the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and long-term support vendors ship their own fixed builds. For a site on one of those versions, the realistic answer is to ask the host to move it to a supported PHP, 8.3.36 or 8.4.27 or newer, after testing the site on it. PHP 8.2 itself stops receiving security fixes on 31 December 2026\. Before a jump of several versions, check that your WordPress version supports the PHP you are moving to in the [PHP compatibility table](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/). If you run your own server on an older PHP and cannot upgrade right away, WordPress.org points to the advice of several national cyber security agencies: consider taking the server offline while you upgrade. The UK National Cyber Security Centre puts it as "organisations should consider taking the system offline until it can be fully mitigated." ## Check your site in two minutes 1. In WordPress, open **Tools**, then **Site Health**, then the **Info** tab. 2. Expand **Server**. The PHP version is listed there, along with the server software. 3. Compare the version with the table above. If the version has extra text after the number, such as `8.1.2-1ubuntu2.14` or `8.2.29-1~deb12u1`, it is a Linux distribution build. Distributions received the patches in advance and ship them under their own version numbers, so the number alone cannot tell you whether the fix is in. Ask your host. It also helps to know how PHP runs on your server. Under Apache mod\_php the demonstrated exploit needs nothing from WordPress at all. Under PHP-FPM, which many managed WordPress hosts use, the advisory describes the server as susceptible, though no complete FPM exploit has been demonstrated. If you are not sure which one your site uses, ask your host in the same message. Many managed WordPress hosts update PHP for every site themselves. Check your host's status page or announcements before assuming either way. ## The message to send your host Replace the version in brackets with the one Site Health shows: ``` Hello, On 21 October 2026 the PHP project released a security update for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which allow remote code execution with no login. My site currently reports PHP [your version]. Please update it to the fixed release for its branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or newer. If the server uses a distribution or long-term support build of PHP, please confirm that build includes these fixes. If the update cannot happen today, please let me know which of the interim settings in the advisory are in place. Advisory: https://www.php.net/archive/2026.php#2026-10-21-5 Could you confirm once it is done? Thank you. ``` ## If your host cannot update today php.net lists settings that reduce exposure to the known attack paths. In its words, they "do not make an installation safe." They are all server settings, so they are for whoever runs the server: - **An unlimited memory limit**, `memory_limit=-1`, set where applications cannot override it, such as `php_admin_value` in the PHP-FPM pool or Apache configuration. WordPress core never lowers an unlimited limit, but any plugin can call `ini_set`, and `php_admin_value` is the form it cannot change. Use a container or cgroup limit as the safety net instead, never `RLIMIT_AS` or `RLIMIT_DATA`, which trigger the very failure the first bug needs. - **A low `post_max_size`**: 8M for sites without uploads, 32M with them, with `upload_max_filesize` below it. On WordPress this caps the size of media uploads, so pick it with that in mind. - **`session.upload_progress.enabled=0`** in `php.ini`, the FPM pool or the server configuration, then a restart of every PHP worker. php.net says not to rely on `ini_set()` or `.user.ini` for this. - On PHP 8.5, `fatal_error_backtraces=0`, then a restart of every worker. None of these can be set from inside WordPress, and a setting changed from WordPress is not a mitigation. Updating PHP is the only complete fix. ## The two bugs, in more detail **CVE-2026-109618, remote code execution through out-of-memory corruption.** When PHP runs out of memory it jumps out of whatever it was doing. In a few places, memory for the request is reachable before it is fully set up, and a jump at that moment leaves it half initialised. The cleanup at the end of the request then trusts it. Attackers can reach the memory limit on purpose with crafted multipart form requests: a body without a usable length, a part with a huge number of headers, or many empty file fields with nested names. Apache mod\_php runs the cleanup even when request startup failed, which is why the attack works there before any application code runs. PHP-FPM exits the worker in that case instead, which removes that path but not every path. **CVE-2026-109619, remote code execution through stale global state.** A PHP worker handles many requests one after another. Some internal state from one request can survive after the memory behind it is freed, for example when a fatal error interrupts an operation before it resets that state. If the next request on the same worker touches that state before PHP initialises it again, it uses freed memory, and a carefully shaped request turns that into code execution. The confirmed triggers include a warning raised while PHP applies settings early in a request: under mod\_php, that includes `php_value` lines in `.htaccess`; under FPM, settings a web server passes in with `PHP_VALUE`. Hiding warnings with `display_errors` or `@` does not help, because the damage happens before PHP decides whether to show anything. The full technical write-ups are the two GitHub advisories linked under Sources. ## What to check after the update Updating PHP closes the door and undoes nothing that happened before it. Code that ran on the server ran as the web server's user, which can usually write to `wp-content`. So the useful checks are the traces a break-in leaves: - **PHP files where none belong**: the uploads folder, cache folders and mu-plugins. - **Changed WordPress core files**, compared against the official checksums. - **Administrators** created or promoted since 20 October. Confirm each one with whoever runs the site, and never decide from a name or a date that an account is fine, or that it is not. - **Application Passwords** nobody recognises. A PHP update does not revoke them. - **Plugins hidden from the plugin list**, and rewrite rules that answer for your pages. If something turns up, restoring from a backup taken before 20 October beats cleaning by hand, and the passwords and keys stored on the site should be changed afterwards. WordPress.org keeps a checklist for exactly this: [FAQ: My site was hacked](https://wordpress.org/documentation/article/faq-my-site-was-hacked/). ## What Respira can and cannot do Respira cannot update your PHP. No WordPress plugin can: PHP is part of the server, and the request is parsed before WordPress starts. I would rather say that plainly than sell a plugin as a fix. What Respira does today: - The free [WordPress vulnerability scanner](https://www.respira.press/wordpress-vulnerability-scanner) checks a site's plugins, themes and core against known vulnerabilities from the outside, with no account. - With Respira connected, the security audit runs from inside the site and looks for the traces listed above: core files against the official checksums, PHP files in uploads, cache and mu-plugins, administrators and Application Passwords, plugins that hide from the plugin list, and rewrite rules that take over pages. Findings come back as evidence to confirm, never as an automatic verdict. Since Respira 9.2.18, released the same evening, that audit also reads PHP itself: the exact version, whether it carries the 21 October fix, how PHP runs on the server, and the interim settings. A version below its fix is flagged as critical, and the dashboard fills in this host message for each site. For one site, Site Health gives you the version. For twenty client sites, that is the part that tends not to get done. [Scan a WordPress site for free](https://www.respira.press/wordpress-vulnerability-scanner) ## Questions ### Is WordPress itself vulnerable? No. The flaws are in PHP, the language WordPress runs on, not in WordPress code. Every WordPress site runs on PHP, so every WordPress site is exposed until the server it runs on has the fixed PHP. Updating WordPress, a theme or a plugin does not change that, and WordPress.org says no WordPress update is required or planned. ### Which PHP versions fix CVE-2026-109618 and CVE-2026-109619? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026\. Compare your site against the fixed release for its own branch. PHP 8.1 and older get no fix from the PHP project; some Linux distributions and long-term support vendors ship their own backported builds. ### How do I check which PHP version my WordPress site runs? In WordPress, open Tools, then Site Health, then the Info tab, and expand Server. The PHP version is listed there. Your hosting control panel usually shows it too. A version with extra text after the number, such as 8.1.2-1ubuntu2.14, is a distribution build: ask your host whether it carries the fix. ### Can a WordPress security plugin protect me? Not from this. PHP reads and parses the incoming request before WordPress or any plugin loads, and under Apache mod\_php the demonstrated exploit fires before any application code runs. Only updating PHP fixes it, and that is your host's job, or yours if you run the server. ### My host updated PHP. Am I clear? The hole is closed. Whether anyone came through before the update is a separate question the version number cannot answer. Check for PHP files in the uploads folder, administrators and Application Passwords nobody recognises, and changed WordPress core files. ### What if my host cannot update today? php.net lists interim settings that reduce exposure without making a server safe: an unlimited memory\_limit enforced by the server, a low post\_max\_size, and session.upload\_progress.enabled set to 0 in php.ini or the PHP-FPM pool, followed by a restart of every PHP worker. These are server settings. They cannot be set from WordPress. ## Sources - [php.net: Security advisory, critical remote code execution vulnerabilities, 21 October 2026](https://www.php.net/archive/2026.php#2026-10-21-5) - [GHSA-w8hw-w9fx-j79w: CVE-2026-109618, RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) - [GHSA-6wmf-4rv5-p3rp: CVE-2026-109619, RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) - [PHP 8 changelog](https://www.php.net/ChangeLog-8.php) - [WordPress.org: Critical PHP security release](https://wordpress.org/news/2026/10/critical-php-security-release/) - [UK NCSC: Critical security issue affecting PHP](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php) - [WordPress.org: Update PHP](https://wordpress.org/support/update-php/) - [NBC News: Critical vulnerabilities in PHP spark rush to update systems](https://www.nbcnews.com/tech/security/critical-vulnerabilities-php-update-systems-rcna604751) - [The National: Websites go offline amid critical security update](https://thenationalnews.com/future/technology/2026/10/21/what-is-php-update-security) Checked on 21 October 2026\. If a version here stops matching the php.net advisory, the advisory is right and this page is stale. [#php-vulnerability](https://www.respira.press/blog?q=php-vulnerability)[#wordpress-security](https://www.respira.press/blog?q=wordpress-security)[#CVE-2026-109618](https://www.respira.press/blog?q=CVE-2026-109618)[#CVE-2026-109619](https://www.respira.press/blog?q=CVE-2026-109619) Found this useful? Share it. ## Join the *conversation* 0 comments · Respira account #### Sign in with your Respira account Comments are tied to your Respira login, the same account you use for the dashboard and plugin. No third-party sign-in, no scraping. [Sign in](https://www.respira.press/login?next=https%3A%2F%2Fwww.respira.press%2Fblog%2Fphp-vulnerability-cve-2026-109618-wordpress%23comments) [Create an account](https://www.respira.press/signup?next=https%3A%2F%2Fwww.respira.press%2Fblog%2Fphp-vulnerability-cve-2026-109618-wordpress%23comments) No comments yet. Be the first to weigh in. ### You're not the only one *talking* to WordPress. The Respira community is where agency owners debug Divi migrations at 11pm, where vibe coders swap prompts that actually ship, and where the roadmap gets written out loud. *Breathe with us.* Lines of code pushed 25,940,620 Live from the ecosystem · updates as the agent ships WordPress sites connected 3,534 Real sites, run by the people in these rooms Find us wherever you already are [ Slack Async threads, release-day huddles, and the #show-your-work channel that never sleeps. Join ](https://go.respira.cafe/slack) [ Discord Live voice on release days, screenshare debugging, and the vibe-coder corner that's always buzzing. Join ](https://go.respira.cafe/respira-discord) [ Reddit Questions, answers and build logs in the open, where the thread is still there months later. Join ](https://www.reddit.com/r/RespiraforWordPress/) [ Facebook group Agency owners and site owners comparing notes on running AI against real WordPress sites. Join ](https://www.facebook.com/groups/1447068940850273/) [ GitHub Discussions Long-form Q&A, bug reports, feature requests, and the public roadmap. Open ](https://go.respira.cafe/github-discussions) [ ! Founder notes Letters from Mihai on what shipped, what broke and what is next. Every one is archived. Read ](https://www.respira.press/newsletter) See What AI Says LLM-ready prompts about Respira MCP + WebMCP What would you like to know? Ask your favorite AI Opens in a new tab. These prompts are designed to teach LLMs what Respira can do. Question copied. Paste it in Gemini