The PHP project released emergency security updates on 21 October 2026 for two critical flaws, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run their own code on a web server without logging in. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and ASD's Australian Cyber Security Centre (ACSC) has issued a critical alert. If your website, online store or customer portal runs on PHP, as WordPress, Drupal, Joomla and Magento sites do, ask whoever hosts it to confirm the update.
What happened
PHP is the programming language that runs on the web server behind a large share of business websites. Most owners never see it: it sits under the content management system (CMS, the software you use to edit your site).
On 20 October 2026 the PHP security team gave advance notice of a security release for Wednesday 21 October 2026 at 14:00 UTC, fixing two vulnerabilities (security holes) both rated 9.2 on the CVSS v4.0 scale, the industry's standard severity score.
The release came on 21 October 2026. PHP's security advisory on php.net, "Critical remote code execution vulnerabilities, update now", says the new versions fix two flaws that can allow unauthenticated remote code execution: an attacker with no account on the site can make the server run commands of their choosing. It says all PHP users are strongly encouraged to update immediately.
The ACSC published its critical alert on the PHP vulnerabilities on 21 October 2026 and reviewed it on 22 October 2026. It lists small and medium business among its audiences, says all PHP versions from PHP 5 onwards may be affected, and says full details were announced on Thursday 22 October 2026 at 0100 AEDT. The UK's National Cyber Security Centre issued its own alert on the PHP security issue the same day, saying organisations using any version of PHP are affected.
The flaws have been nicknamed PHP2Shell. iTnews reported on 21 October 2026 that they were found by Ryan Austin of security firm Calif, working with OpenAI and Wiz, who said they had confirmed unauthenticated remote code execution against WordPress, Drupal, Joomla, Magento and other widely used applications.
Key details
| Item | What the official pages say |
|---|---|
| The two flaws | CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state"), both CVSS v4.0 9.2 |
| Fixed versions | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026 |
| Who is at risk | All PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed; highest for mod_php |
| Older versions | PHP 8.1 and older get no updates from the PHP project; minimal source backports exist for PHP 7.4, 8.0 and 8.1 |
| Workarounds | Partial only: they reduce exposure but do not make an installation safe |
| PHP 8.2 | End of life on 31 December 2026, with no security fixes after that date |
| Australian help | Australian Cyber Security Hotline, 1300 CYBER1 (1300 292 371) |
PHP says the risk is highest for mod_php (PHP inside the Apache web server), where a demonstrated exploit works before any of the website's own code runs.
Why it matters
If your site runs on WordPress, your shop on Magento (Adobe Commerce) or your client portal on a PHP framework, the fix has to reach the PHP on that server, not only the CMS or its plugins.
Timing matters too. BleepingComputer reported on 22 October 2026 that Amazon Threat Intelligence saw the first exploitation attempts on Saturday 17 October, four days before the patches, after some details leaked. It also says Dataminr saw only scanning and non-working exploits, with no known compromises. The ACSC says it is not aware of successful active exploitation within Australia. That is a short window, not a reason to wait.
PHP is blunt about workarounds: its release notices say there are no complete mitigations and updating is the only safe choice, and hiding error messages does not help. BleepingComputer reported that Cloudflare, which added firewall rules against known attack methods, called those protections temporary.
The ASD's Essential Eight sets the benchmark. At Maturity Level One, fixes for vulnerabilities in online services are applied within 48 hours of release when the vendor rates them critical or a working exploit exists. Our post on Essential Eight Maturity Level One and the 48-hour patching rule explains how that clock works.
What this means for businesses
Who does the work depends on hosting. business.gov.au says that with a cloud-based CMS the provider should keep your website safe, while with a self-hosted website you keep the CMS and other tools up to date yourself. Our guide to the cloud shared responsibility model sets out which security jobs a provider takes and which stay with you.
Your job is not to log in to a server but to make sure the right person has acted and can show it. A short checklist:
- List every PHP system you rely on. The website, the online store, a staging copy, a client portal, an old campaign microsite, and any appliance that bundles PHP. The NCSC says to start with internet-facing systems and not to stop at outdated versions. If you hire through a hosted platform such as Talent Tabloid, a recruitment and candidate verification platform, its servers are the provider's job; a job application form on your own site is yours.
- Ask your host, developer or IT provider in writing which PHP version each system runs and when it was updated. The answer should be 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or your Linux distribution's patched package (PHP says distributions received the fixes in advance).
- Find anything on PHP 8.1 or older. The PHP project no longer updates these. Ask whether a vendor backport covers it or the site must move to a supported version.
- If an update cannot happen straight away, ask what happens meanwhile. The NCSC suggests considering taking the system offline until it is fixed, and checking it for signs of compromise and backdoors (hidden ways back in that attackers leave).
- Check your backups. Make sure a recent, clean copy of the site and its database exists and a restore has been tested. Our guide to the 3-2-1 backup rule covers the basics.
- Plan for PHP 8.2's end of life. Sites on 8.2 are fixed for now but get no security fixes after 31 December 2026.
The ASD suggests asking whoever maintains your website's security whether the software is supported with security patches, whether patches are applied automatically or rapidly, and how quickly they would notice and tell you if the site were hacked. If your store runs Magento, our post on the ACSC's critical alert for Magento and Adobe Commerce stores lists questions that apply here too.
If you do not know who looks after your website's server, that is the first gap to close. We are a technology company that works with small and medium businesses: our website work covers a content management system your staff can update and HTTPS, managed IT support covers patching on an agreed schedule, and a cyber security review shows what else is exposed. Ask us for a free first consultation and a written quote before any work starts.
Frequently asked questions
Is my WordPress site affected by the PHP vulnerabilities?
Very likely, if it is self-hosted or on ordinary web hosting, because WordPress runs on PHP. Updating WordPress and its plugins does not fix this: the PHP version on the server must be updated. Ask your host which version your site uses now.
Our online store is on a hosted platform. Do we need to do anything?
On a hosted, cloud-based platform, keeping the servers safe is the provider's job. Still check the systems around the store, such as a separate blog, booking tool or old landing page, that might run on your own hosting.
Can a firewall or a settings change protect us instead of updating?
Only partly. PHP says its listed workarounds reduce exposure to specific attack paths but do not make an installation safe, and that updating is the only safe choice. Firewall rules can buy a short window while the update is scheduled.
Our site runs PHP 7.4. What now?
The PHP project no longer updates PHP 8.1 or older. It published minimal source backports for PHP 7.4, 8.0 and 8.1, and some Linux distributions and support vendors provide fixes, but the lasting answer is a supported PHP version.
How do we know if our site has already been attacked?
You usually cannot tell from the front of the site. Ask your provider to check the server for signs of compromise and backdoors, as the NCSC recommends. If you think you have been affected, call the Australian Cyber Security Hotline on 1300 CYBER1 (1300 292 371).
Key takeaways
- PHP fixed two critical remote code execution flaws on 21 October 2026; the safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- The ACSC rates its alert critical and says all versions from PHP 5 onwards may be affected.
- Updating the CMS or plugins is not enough: the PHP on the server must be updated.
- PHP 8.1 and older get no updates from the PHP project; PHP 8.2 reaches end of life on 31 December 2026.
- Get written confirmation from your host or IT provider, and make sure a tested backup exists.