A plain-language action plan for business owners, managing directors and marketing leaders. If your website runs on WordPress, WooCommerce, Drupal, Joomla, Magento or Laravel, this applies to you.
Last updated: 22 October 2026. This is a developing situation, and we will update this guide as official guidance changes.
On Tuesday morning, a business owner’s website looked exactly as it did the day before. Same homepage, same contact form, same checkout. Nothing on the screen suggested that anything was wrong.
But behind that homepage, the server was running a version of PHP that, as of 21 October 2026, can be taken over by a stranger with a single web request. No password. No phishing email. No warning.
That is the situation facing millions of businesses this week. Two critical PHP security vulnerabilities, known as PHP2Shell, have prompted the FBI and NSA to advise organisations that cannot patch to take their systems offline, and have led governments in Europe to pull their own websites as a precaution.
This guide explains, without jargon, what has happened, how to find out whether your website is exposed, and exactly what to do about it, today and over the next 30 days.
At a glance
| What | Two critical flaws in PHP itself: CVE-2026-109618 and CVE-2026-109619, known as “PHP2Shell” |
| Severity | 9.2 out of 10 (CVSS v4.0), the highest tier (PHP.net) |
| Risk | An attacker can run their own code on your web server without logging in |
| Who is affected | Any website or web application running an unpatched version of PHP, across nearly all releases back to PHP 5.4 (SecurityWeek) |
| Scale | PHP is used by 69.3% of websites whose server-side language is known (W3Techs, via Newsweek) |
| Being exploited? | Yes. Attack attempts began before disclosure and have since been reported in the hundreds of thousands (The Register) |
| The fix | Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP |
| If you cannot fix it today | Take the site offline or isolate it, as advised by the FBI, NSA and CERT-EU |
If you read nothing else, do these five things today
- Find out the exact PHP version every one of your websites is running.
- Update to a fixed version and make sure PHP services are restarted.
- If you cannot update today, take the site offline until you can.
- Check for signs of compromise going back to at least 17 October 2026.
- Name one person who is accountable for closing this out.
Part 1: What happened, in plain language
PHP is the engine under most of the web
When someone visits your website, the pages they see are usually assembled on a server by software written in PHP. WordPress, the world’s most widely used website platform, is built on PHP. So are WooCommerce, Drupal, Joomla, Magento and Laravel applications, along with many client portals, booking systems and hosting control panels.
You may never have heard of PHP. Your website almost certainly depends on it.
What the vulnerabilities allow
The two PHP security vulnerabilities sit inside the PHP engine itself, not in a plugin, theme or piece of your own code:
- CVE-2026-109618 can be triggered when PHP runs out of memory part-way through handling a request, leaving internal data in a broken state that an attacker can exploit.
- CVE-2026-109619 allows data from one visitor’s request to linger in memory after it should have been cleared, so an attacker’s later request can misuse it.
Both can lead to remote code execution, which means an attacker can make your server do whatever they want: steal customer data, plant malware, redirect your visitors to scam sites, send spam from your domain or use your server to attack others. Reporting also indicates the flaws can expose sensitive data held in server memory, which may include passwords and API keys (SecurityWeek).
The PHP project states that all installations serving web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php (PHP.net).
How events unfolded
| Date (2026) | What happened |
|---|---|
| 17 October | An exploitation attempt is recorded by security researchers, four days before public disclosure (The Register) |
| 20 October | Details leak ahead of the planned disclosure date. The PHP project announces an emergency security release (SecurityWeek; PHP.net) |
| 21 October | Fixed versions are released. CISA, the FBI, the NSA and CERT-EU issue urgent guidance. Government websites in Finland and the Netherlands are taken offline as a precaution (The Register) |
| 22 October | Attack attempts are reported to have passed one million, with attackers modifying their methods to get around firewall protections (The Register) |
Why this is different from a routine update
Most security updates can wait for the next maintenance window. This one cannot, for four reasons:
- No login is required. A single unauthenticated request can be enough, and it runs before your website’s own code has a chance to respond (Help Net Security).
- Attackers had a head start. Attempts began before most businesses even knew the flaws existed.
- The reach is enormous. Because the flaw is in PHP itself, every website on an unpatched PHP server is exposed, whatever platform it is built on.
- AI has compressed the timeline. Researchers have said frontier AI models substantially lowered the barrier to turning these long-standing flaws into a working exploit (Help Net Security). The gap between “announced” and “attacked” is now measured in hours.
The official response reflects this. The FBI and NSA have advised organisations that cannot update immediately to “take the system offline until it can be fully mitigated” (Newsweek). CISA has issued an alert titled “Critical Vulnerabilities in PHP Require Immediate Patching”.
Part 2: What it could mean for your business
The impact of a compromised website goes far beyond the website itself.
| If your business is… | The risk to you |
|---|---|
| E-commerce | Stolen payment and customer data, fraudulent orders, lost sales during downtime, and loss of customer trust at the point of purchase |
| A professional services firm | Exposure of confidential client information shared through forms or portals, and reputational damage with clients who trusted you with sensitive matters |
| Healthcare, finance, legal or another regulated sector | Regulatory reporting obligations, potential penalties and mandatory customer notification if personal data is accessed |
| Lead-generation or B2B | Hijacked forms, lost enquiries, a blacklisted domain and emails from your company landing in spam |
| Any business | Your website redirecting visitors to scams or malware, search engines flagging your site as unsafe, and recovery costs far higher than prevention |
The question for leadership is not “will we be targeted?” Attackers are scanning the whole internet automatically. The question is “will we be patched before we are found?”
Part 3: Is your website affected? How to check in 10 minutes
If your website runs on PHP and has not been updated since 21 October 2026, assume it is exposed until you have confirmed otherwise.
Step 1: Find your PHP version
You do not need to be technical. Use whichever of these applies to you:
- WordPress sites: Log in to your dashboard and go to Tools → Site Health → Info → Server. The PHP version is listed there.
- Hosting control panel: Most hosting dashboards show the PHP version under a section named “PHP version”, “PHP settings” or similar.
- Ask in writing: Email your hosting provider, developer or agency and ask: “What exact PHP version is our website running, and has it been updated for CVE-2026-109618 and CVE-2026-109619?” Ask for the full version number, not a general reassurance.
Step 2: Compare it against the fixed versions
| If your site runs | It must be updated to at least |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 (PHP 8.2 reaches end of life on 31 December 2026, so plan to move beyond it) |
| PHP 8.1, 8.0, 7.4 or older | No longer updated by the PHP project. Upgrade to a supported version, or use a backported fix from your vendor. Treat this as urgent. |
Source: PHP.net security advisory
Step 3: Confirm who is responsible for updating it
| Your hosting setup | Who updates PHP | What you should do |
|---|---|---|
| Shared hosting | Usually your hosting provider | Ask for written confirmation of the patched version today |
| Managed WordPress or managed hosting | Usually your provider | Confirm the patched version is live on your site, not only on the platform |
| VPS, cloud or dedicated server | You, your developer or your agency | Patch immediately and restart PHP services. This is the highest-risk category |
| Custom web application (for example Laravel) | Your development team | Patch the runtime, rebuild containers or images, redeploy and verify |
| Software or devices that bundle PHP | The product vendor | Check vendor advisories; some affected products do not yet have fixes (Help Net Security) |
One of the most common and most costly assumptions is “our host handles security”. Hosts often patch their platform while individual sites remain pinned to older PHP versions. And old microsites, staging copies and campaign pages are routinely forgotten entirely.
Step 4: Decide
- Confirmed on a fixed version? Move to the compromise checks in Part 4, step 6.
- Not sure? Treat it as unpatched until someone confirms the version number in writing.
- Unpatched and can be fixed today? Fix it now.
- Unpatched and cannot be fixed today? Take it offline or isolate it until it can.
Part 4: The 24-hour action plan
1. Name an owner.
Assign one person to be accountable, with authority to make decisions, including taking a website offline.
2. List every website and web application you run.
Include your main site, landing pages, client portals, booking systems, intranets, old domains, staging sites and campaign microsites. As one researcher put it, “the number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast” (The Register).
3. Patch, then restart.
Updating PHP is the only complete fix (PHP.net). PHP services must be restarted afterwards for the fix to take effect. A patch that has been installed but not activated protects nothing.
4. If you cannot patch today, go offline.
A temporary maintenance page costs far less than a breach. The PHP project lists partial configuration changes for teams who need time, but states plainly that they do not make an installation safe.
5. Add a protective layer while you work.
Many hosting and content delivery providers have deployed web application firewall rules that block known attack patterns. Turn them on. But treat them as a seatbelt, not a fix: attackers are already adapting their methods to get around them, and firewall providers themselves describe this protection as “no substitute for patching” (The Register).
6. Check for signs of compromise, going back to 17 October.
Because attacks began before disclosure, investigators have advised looking for suspicious activity dating back to at least 17 October 2026 (The Register). Warning signs include unfamiliar files, new administrator accounts, unexpected redirects, unusual outbound traffic, and PHP processes starting command shells or downloading files (Newsweek).
7. Rotate credentials if there is any doubt.
Because the flaws may expose data held in memory, change database passwords, API keys and admin credentials on any site that was unpatched and internet-facing.
8. If you suspect a breach, preserve evidence and report it.
Isolate the affected system, keep server and PHP logs, and report the incident to the relevant authority in your country. Review your obligations under data protection law if customer data may have been accessed.
What not to do
- Do not rely on a plugin update. Updating WordPress or its plugins does not fix this. The PHP version on the server must change.
- Do not accept “we’re looking into it” as an answer. Ask for a version number and a time.
- Do not forget the sites nobody uses. Old sites are often the least maintained and the easiest way in.
- Do not assume a firewall is enough. Patch regardless.
- Do not stay silent if customer data is at risk. Delayed disclosure usually causes more damage than the incident itself.
If you take your site offline: a message you can adapt
We’ll be back shortly.
We are carrying out urgent security maintenance to keep your information safe, following an industry-wide software update. Our website will be back online as soon as this work is complete. In the meantime, you can reach us at [email address] or [phone number]. Thank you for your patience.
Part 5: The 30-day hardening plan
Patching closes this door. The next 30 days are about making sure the next one does not catch you unprepared.
Week 1: Verify and document
- Confirm every site in your inventory is patched and restarted, with the version recorded.
- Create one register showing each site’s hosting setup, PHP version, platform version and responsible party.
- Retire sites you no longer need. An unused website is pure risk.
Week 2: Close the gaps
- Upgrade anything on PHP 8.1 or older, and plan the move off PHP 8.2 before 31 December 2026.
- Update your platform, themes and plugins, and remove anything unused or abandoned.
- Review admin accounts, enforce strong passwords and enable multi-factor authentication.
Week 3: Build resilience
- Confirm you have automated, off-site backups, and test a full restore. A backup you have never restored is a hope, not a plan.
- Put uptime and security monitoring in place so you hear about problems before your customers do.
- Assess your site against the OWASP Top 10, the industry-standard list of critical web application security risks.
Week 4: Make it routine
- Agree a maintenance schedule and a guaranteed response time for critical security updates.
- Write a one-page incident plan: who decides, who acts, who speaks to customers.
- Subscribe the responsible person to official sources, such as the PHP.net news feed and CISA’s Known Exploited Vulnerabilities catalog.
Part 6: Seven questions every leader should ask their web team this week
You do not need to be technical to lead well here. You need to ask precise questions and expect precise answers.
- What exact PHP version is each of our websites running right now?
- When was it updated, and who confirmed it?
- Have we checked for suspicious activity back to 17 October?
- Are there websites or systems we have forgotten about?
- If a critical vulnerability is announced tomorrow, how many hours until we are patched?
- When did we last test restoring from a backup?
- Who is accountable for website security, by name?
If any answer is “I’m not sure”, that is your priority, regardless of this particular vulnerability.
Part 7: The bigger lesson, a website is never “finished”
Many businesses still treat their website as a project: designed, built, launched and left alone until the next redesign. PHP2Shell shows why that model no longer holds.
A website is live software. It is connected to the internet around the clock and built on layers of technology, from the server and PHP to the platform and its plugins, each of which needs ongoing care. Security commentators expect “a long tail” of forgotten and unpatched installations long after the headlines fade (Help Net Security). Those are exactly where attackers will look next.
With AI accelerating how quickly vulnerabilities are found and weaponised, the window between disclosure and attack will keep shrinking. The businesses that come through events like this unharmed are not the lucky ones. They are the prepared ones, and they share five traits:
| Trait | What it looks like in practice |
|---|---|
| Clear ownership | One named person accountable for website security |
| Full visibility | A current inventory of every site, system and version |
| Fast response | A maintenance partner with a defined response time for critical updates |
| Proven recovery | Automated backups that have been tested, and an incident plan |
| Continuous assurance | Regular security assessments, not only when the news forces one |
Frequently asked questions
What are the PHP2Shell vulnerabilities?
PHP2Shell is the widely used name for CVE-2026-109618 and CVE-2026-109619, two critical PHP security vulnerabilities disclosed on 21 October 2026. They can allow an attacker to run code on a web server without logging in, and are rated 9.2 out of 10 for severity.
Is my WordPress website affected?
WordPress runs on PHP. If the server hosting your WordPress site runs an unpatched version of PHP, your site is exposed. You can check your PHP version under Tools → Site Health → Info → Server. Updating WordPress or its plugins does not fix this; the PHP version on the server must be updated.
Which PHP versions fix the vulnerabilities?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older no longer receive official updates from the PHP project and should be upgraded or covered by a vendor-supplied backport (PHP.net).
Should I really take my website offline?
If you cannot confirm it is patched, yes, temporarily. The FBI, NSA and CERT-EU have all advised taking or isolating unpatched systems offline until they can be fixed. A short, well-communicated outage is far less damaging than a compromised website.
My hosting provider says they handle security. Am I safe?
Possibly, but get written confirmation of the exact PHP version your site runs. Providers often patch their platform while individual sites remain on older PHP versions, and older or forgotten sites are frequently missed.
Is a web application firewall enough to protect me?
No. A firewall can block known attack patterns and buys valuable time, but attackers are already modifying their methods to get around these rules. Updating PHP is the only complete fix.
How do I know if my website has already been hacked?
Warning signs include unfamiliar files or administrator accounts, unexpected redirects, spam pages appearing in search results, unusual server activity and alerts from your host. Investigators recommend reviewing activity back to at least 17 October 2026. If you suspect a compromise, isolate the site, preserve logs, rotate credentials and get a professional assessment.
Conclusion: fix today’s risk, then build for the next one
PHP2Shell is one of the most significant website security events in years. For businesses that know what they run, who owns it and how to act, it is a busy but manageable week. For businesses that do not, it is a serious exposure.
Use this week to do both: close today’s risk, and put in place the people, processes and partners that turn the next critical vulnerability into a routine update instead of a crisis.
Digifluencer helps businesses secure, maintain and modernise their websites and web applications.
- Our cybersecurity assessments identify where your websites, apps and accounts are exposed, and what to fix first.
- Our Safe Web service provides ongoing maintenance, backups and reporting, so critical updates are handled before they become headlines.
- When older platforms need upgrading or migrating, our engineering team handles integrations, migration and hosting end to end.
Not sure whether your website is patched? Do not wait to find out the hard way.
Talk to Digifluencer today →
Sources
- PHP.net, “Security advisory: Critical remote code execution vulnerabilities,” 21 October 2026. https://www.php.net/archive/2026.php#2026-10-21-5
- PHP.net, advance notice of security release, 20 October 2026. https://www.php.net/archive/2026.php#2026-10-20-1
- CISA, “Critical Vulnerabilities in PHP Require Immediate Patching,” 21 October 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
- CISA, “Known Exploited Vulnerabilities Catalog.” https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Newsweek, “FBI Issues Advice As Security Issue Hits Global Websites,” October 2026. https://www.newsweek.com/fbi-issues-advice-as-security-issue-hits-global-websites-12603155
- The Register, “PHP devs publish critical bug fix as site owners warned: Pull ’em offline if you’re unpatched,” 21 October 2026. https://www.theregister.com/security/2026/10/21/php-devs-publish-critical-bug-fix-as-site-owners-warned-pull-em-offline-if-youre-unpatched/5304519
- The Register, “Hackers pile on PHP2Shell as attacks began before disclosure,” 22 October 2026. https://www.theregister.com/cyber-crime/2026/10/22/hackers-pile-on-php2shell-as-aws-reveals-attacks-began-before-disclosure/5304749
- SecurityWeek, “PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors,” October 2026. https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/
- Help Net Security, “PHP2Shell: Critical PHP vulnerabilities patched, update now!,” 21 October 2026. https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
- W3Techs, “Usage statistics of PHP for websites.” https://w3techs.com/technologies/details/pl-php
- OWASP Foundation, “OWASP Top Ten.” https://owasp.org/www-project-top-ten/
