Critical PHP Vulnerability (October 2026): Is Your Website Exposed, and Who Fixes It?

Imagine you run a 40-person physiotherapy practice. Your website takes online bookings, and a patient portal sits behind it. One morning a supplier forwards you a news story about a "critical PHP flaw" and asks whether you're affected. You don't know what PHP is, who built the portal, or who would fix it.

Here's the short answer. On 21 October 2026, the PHP project released fixes for two critical flaws, known as PHP2Shell, that can let an attacker run their own code on a web server without logging in. The fix sits in PHP itself, not in your website's content or plugins, so whoever runs the server your site lives on has to apply it. Your job is to find out who that is for each site, get them to confirm the fix in writing, and decide whether you also need a check for signs of a break-in.

This guide reflects what was known as at 26 October 2026.

What is PHP2Shell?

PHP is the programming language that runs on the web server behind many websites and web applications. WordPress and WooCommerce, Magento and Laravel all run on PHP, as do many custom booking systems, client portals and CRMs.

The two flaws behind the name are CVE-2026-109618 and CVE-2026-109619. PHP rated both 9.2 out of 10 (CVSS v4.0), and its security advisory says "all PHP installations serving web requests" are at risk. An attacker who succeeds could steal customer data, plant malware or deface your site.

What's happened so far (as at 26 October 2026)

• 20 October: Details of the flaws leaked on social media before the planned disclosure, according to security firm watchTowr. The same day, PHP gave advance notice of an emergency security release.
• 21 October: The Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) published a critical alert advising organisations to identify where they use PHP and prepare to patch.
• 21 October (1:00 am AEDT on 22 October): PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which fix both flaws.
• Since then, reports on attacks differ. watchTowr says it has seen exploitation "in the wild" through its network of decoy (honeypot) systems since 21 October. The Canadian Centre for Cyber Security, in an alert last updated 23 October, said open-source reporting indicated that proof-of-concept code was available, with no active exploitation identified at that time, adding that this "can change quickly". The ACSC alert, last reviewed 22 October, says ASD's ACSC "is not aware of successful active exploitation within Australia".
• 23 October: PHP flagged a separate, lower-risk issue, CVE-2026-115560. PHP calls it "an unlikely RCE vector" that needs an unusual combination of settings and code, and says it will be fixed in the next regular release. Until then, PHP suggests switching off one feature (session upload progress). See PHP's informational advisory.

Why updating WordPress or your plugins won't fix it

The flaws are in PHP itself, the engine that runs your site's code, not in WordPress, your theme or your plugins. Vercel's security bulletin puts it plainly: "Updating your application code or plugins does not fix these vulnerabilities." It adds that a web application firewall "does not replace patching".

PHP is just as direct: "There are no complete mitigations, updating is the only safe choice." It lists interim settings a provider can use if it can't update straight away, but says they "reduce exposure to specific attack paths but do not make an installation safe". If your provider says they've applied a workaround, treat it as a stopgap and ask when the update itself will happen.

What to do this week: five steps

Work through these in order.

1. List every website and web app that might run on PHP

Think beyond your main website. Include your online store, booking system, client or patient portal, staff intranet and any web-based tools a developer built for you. Canada's Cyber Centre also recommends identifying "third-party products, appliances and containers" that include PHP, so add business software or devices with a web admin page and ask their vendors.

This step is just a list. Don't test anything yourself, and don't run exploit code or unfamiliar online "checker" tools against your sites. Canada's Cyber Centre cites reports that proof-of-concept code is available, and running untested attack code against a live site can cause the very damage you're trying to avoid.

2. Find out who updates PHP for each one

Who has to act depends on how each site is hosted.

Since the fixes were released on 21 October, CSPRO has been checking and updating PHP on client websites it hosts or maintains.

If you're not sure which kind of hosting you have, this guide to shared, VPS and cloud hosting explains the differences. If you run your own server and would rather hand over the patching, CSPRO's server management includes scheduled patching wherever the server is hosted.

3. Check which PHP version you're on

You can often see the version yourself:

• WordPress: go to Tools > Site Health, open the Info tab and expand Server. The PHP version is listed there.
• cPanel hosting: the MultiPHP Manager screen lists the PHP version each domain uses. With another control panel, look for its PHP settings or ask your host.

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Treat what you see as a starting point, not proof. PHP says Linux distributions and long-term support vendors received the patches in advance and supply their own updated packages, so a fixed build may not show one of those exact numbers. Only your provider can confirm that the build running your site includes the fix.

Two version ranges need extra attention:

• PHP 8.1 or older: PHP no longer releases updates for these. It published minimal source fixes for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some vendors backport fixes. Even so, a typical business site on these versions needs an upgrade plan now. That's a common position: Bitsight's internet-wide scans found only about a third of the PHP installations whose version it could identify run a branch covered by this security release (8.2 to 8.5). PHP 7.4 was the most common branch it saw.
• PHP 8.2: fixed in 8.2.35, but support ends on 31 December 2026, after which it gets no further security fixes.

Moving an older site to a supported version can mean code or plugin changes. If your site needs that work, CSPRO's web development team can help.

4. Get the fix confirmed in writing

Send each provider these questions and ask for a dated written reply covering every site:

1. Which PHP version and build is running on each of our websites and web apps?
2. Has the fix for CVE-2026-109618 and CVE-2026-109619 been applied, and on what date?
3. Were PHP and the web server restarted afterwards, so the updated version is the one actually running?
4. Have you checked for signs of compromise since the details leaked on 20 October? What did you check?
5. What are you doing about CVE-2026-115560 until PHP's next regular release?
6. Are any of our sites on PHP 8.2 or older, and what's the upgrade plan?

Question 3 matters because updating the files on disk isn't enough. Google Cloud's response guidance notes that running PHP processes keep the vulnerable code until they're restarted. A useful reply names the version or build, gives a date and says what was checked.

The fix comes from your provider, so be wary of unexpected emails that offer a "PHP patch" or a link to fix your site.

5. Decide whether you need a compromise check

Updating PHP closes the hole, but it doesn't remove an attacker who got in before the fix. Every PHP site ran unfixed for a time after the details leaked on 20 October, because no fix existed until 21 October. Ask your IT provider or a cyber security specialist for a compromise check, especially if:

• the fix was applied days later rather than straight away;
• your provider can't tell you when the fix was applied; or
• you notice warning signs, such as unfamiliar new files on the server (especially ones ending in .php), admin accounts nobody created, pages that changed without explanation, odd redirects, new scheduled tasks, or alerts from your host or security tools.

If a site already shows warning signs, tell whoever investigates before the server is restarted or rebuilt. Google Cloud's guidance points out that restarting PHP's worker processes wipes evidence held in memory.

If the check confirms a compromise, the job becomes a breach response. Follow what to do in the first 24 hours after a breach, which covers containment and who you may need to notify.

What Australian guidance expects

The ACSC alert now advises organisations to apply available security updates and monitor PHP applications for suspicious activity.

For patch speed, ASD's Essential Eight maturity model sets a baseline. At Maturity Level One, patches, updates or other vendor mitigations for vulnerabilities in online services are applied "within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist". PHP rated both flaws critical. Its interim settings could count as vendor mitigations under that wording, but PHP says they don't make an installation safe, so judge your provider by when the update itself was applied. The Essential Eight is a baseline, not a law, but its 48-hour mark is a fair yardstick for your provider's response, and for these fixes it has already passed. For the wider framework, see this overview of the Essential Eight.

If you suspect a site has been compromised, ASD's reporting page covers cybercrimes (reported to police through ReportCyber), incidents and vulnerabilities. The ACSC alert also says organisations that have been affected, suspect they have, or need advice can call 1300 CYBER1 (1300 292 371).

After the emergency: make the next alert easier

• Keep a register. List every website and web app, where it's hosted, which PHP version it runs and who updates it. Next time, you'll know who to email.
• Put responsibility in writing. Whether you use an in-house team or managed IT support, make sure your agreement says who updates PHP on each server. This guide covers what your managed service agreement should spell out.
• Plan your upgrades. Move off PHP 8.2 before 31 December 2026, and off 8.1 or older now.
• Know your exposure. Regular vulnerability scanning can flag outdated software on your internet-facing sites before the next alert.

Conclusion

The fix exists. What matters now is a dated, written confirmation from whoever runs PHP for each of your sites that it's applied and running. Every PHP site ran unfixed for a time after the details leaked on 20 October, so ask for a compromise check, especially if the fix came late, its date is unknown or anything looks wrong, rather than assuming all is well.

If CSPRO hosts your website, updating PHP is CSPRO's job. If CSPRO maintains your site but another company hosts it, contact the team to confirm who is updating PHP on that server. Either way, you can contact the team with any questions about your site. If you're not a client and want help working out where you stand, get in touch or start with a free initial cybersecurity risk assessment.

Advice may change as PHP and ASD's ACSC publish updates, so check php.net and cyber.gov.au for the latest.