Since the news broke on October 21, 2026, I have been getting the same worried question from business owners: “Is my website going to be hacked by this PHP2Shell thing, and will it kill my Google rankings?” Some people think only big companies are at risk. Others think that if their site still loads normally, everything must be fine.
Neither belief is safe. PHP2Shell is a set of serious security flaws in PHP, the programming language behind WordPress, Drupal, Joomla and a huge share of the web. And a hacked site does not just lose data. It can lose its place in Google, sometimes for weeks.
Let me explain both parts in plain words: what PHP2Shell is and what is confirmed so far, and then, mainly, exactly how a hack hurts your SEO. At the end, I give you a short list of things to do today. Everything time-sensitive here is accurate as of October 23, 2026. This is a fast-moving story, so I clearly separate what official sources have confirmed from what news outlets have reported.
What PHP2Shell is, in plain words
PHP is the language that runs on your web server and builds your pages before they reach a visitor’s browser. If your site runs on WordPress, your site runs on PHP.
“PHP2Shell” is the name the security firm Wiz gave to a group of bugs inside PHP itself. They are tracked as two official vulnerability IDs: CVE-2026-109618 and CVE-2026-109619. In simple terms, they can let an attacker who has no password run their own code on your server. Security people call this remote code execution, or RCE. Once someone can run code on your server, they can do almost anything with your website.
The official PHP security advisory on php.net (October 21, 2026) is titled “Critical remote code execution vulnerabilities, update now.” It names the affected setups very broadly:
“Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.”
— The PHP Group, Security advisory: Critical remote code execution vulnerabilities, update now
According to Wiz Research’s PHP2Shell write-up, the bugs can also leak pieces of the server’s memory. That memory can contain things like passwords, tokens and API keys. Wiz says it showed working attacks without login on WordPress, Drupal and Joomla. I won’t go into how the attack works. You don’t need that to protect your site, and it would only help the wrong people.
Confirmed facts vs reported claims (as of October 23, 2026)
Breaking news always comes with some noise. Here is how I sort what we know.
| Claim | Status | Where it comes from |
|---|---|---|
| Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026 | Confirmed | php.net |
| Both CVEs are rated CVSS v4.0 9.2 (critical) | Confirmed | php.net advance notice; Wiz |
| PHP 8.1 and older get no official fix; some vendors offer backports | Confirmed | php.net advisory |
| “Every PHP version released in the last decade” is affected by at least one bug | Researcher claim | Wiz |
| Bugs found with help from AI tools (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol) | Researcher claim | Wiz; also ABC7 |
| 22.6 million potentially vulnerable instances | Reported | Palo Alto Networks, via Fortune |
| Exploit attempts reached millions by the evening of October 21 | Reported | Cloudflare CEO, via Fortune |
| The flaw is “now being broadly exploited in the wild” | Reported | AWS, via Fortune |
| Some government, airline, bank and news sites went offline temporarily | Reported | ABC7, October 22, Fortune (citing Reuters) |
One detail is still fuzzy. Wiz’s own timeline says it found the first bug on August 19 and reported it to PHP on August 24, while other outlets credit a separate firm, Calif, with an earlier find in the summer. For you as a site owner, that history doesn’t change anything. What matters is that a fix exists and attackers are already trying.
Why so many WordPress, Drupal and Joomla sites are exposed
The headline number you keep seeing is “70% of the internet.” That roughly matches independent data. W3Techs reports that, as of October 22, 2026, PHP is used by 69.3% of all websites whose server-side language it can detect.
The same W3Techs page shows how PHP versions are spread across those sites. This is where many small businesses get caught out.
| PHP major version | Share of PHP sites (W3Techs, Oct 22, 2026) | What PHP2Shell means for it |
|---|---|---|
| PHP 8 | 65.3% | 8.2 to 8.5 have official fixes. 8.0 and 8.1 are out of support and need a vendor backport or an upgrade. |
| PHP 7 | 26.9% | No official fix. php.net links minimal backports for 7.4, but upgrading is the real answer. |
| PHP 5 | 7.7% | No fix. Treat as high risk and plan a move now. |
| PHP 4 | 0.1% | No fix. |
In brief: roughly a third of PHP sites still run version 7 or older. Many of those are small business sites that were built years ago and “just work.” Nobody touches the server, so nobody updates PHP. Those sites are the easiest targets now.
Also remember that being small does not protect you. Attacks like this are automated. Bots scan the whole web for anything that answers like a PHP server. They don’t care if you are a global brand or a three-page plumber site.
What attackers do with a hacked site that hurts your SEO
Here is the part most news stories skip. When people imagine a hacked website, they picture a defaced homepage or stolen credit cards. Those happen. But a huge share of hacks are about SEO spam: the attacker wants to borrow your domain’s trust in Google to rank their own junk.
Google’s spam policies define hacked content as “any content placed on a site without permission, due to vulnerabilities in a site’s security.” They list four main forms. I have added what each one usually looks like for a business site and how it hurts rankings.
| Hack type (Google’s term) | What it looks like | How it hurts SEO |
|---|---|---|
| Page injection (Search Console calls it URL injection) | Thousands of new pages appear in odd folders, often selling fake brands, pills or casino offers | Google indexes junk under your name; crawl time is wasted; your site starts to look spammy as a whole |
| Content injection | Hidden links or text added to your real pages | Your best pages now link to spam, and can trigger spam warnings or manual actions |
| Code injection | Malicious JavaScript or iframes added to templates | Can lead to malware flags and browser warnings that stop visitors cold |
| Redirects | Some visitors, often mobile users from Google, are sent to a scam site | Bounces, lost leads and possible “sneaky redirect” penalties |
The Japanese keyword, gibberish and cloaked keyword hacks
Google’s web.dev team documents three classic SEO-spam hacks that hit PHP sites again and again. They are worth knowing by name, because they are exactly what attackers tend to install after a mass break-in.
- The Japanese keyword hack. According to web.dev’s guide, it creates pages of auto-generated Japanese text, often in randomly named folders, with affiliate links to stores selling fake branded goods. The attacker often adds themselves as an owner in your Search Console account so they can change settings like sitemaps.
- The gibberish hack. web.dev describes many new pages full of keyword-stuffed nonsense, with URLs like
cheap-hair-styles-cool.html, built to rank and then redirect visitors elsewhere. - The cloaked keywords and links hack. Per web.dev, these pages often use your own theme so they blend in, and they are “created to manipulate Google’s ranking factors.”
Why you often can’t see the hack yourself
The nasty trick behind most of these is cloaking. That means showing one thing to Google and another thing to people. Google’s spam policies define it as “presenting different content to users and search engines.” So you type your URL, see your normal homepage, and relax. Meanwhile Googlebot sees pharma spam.
“Hackers will try to trick you into thinking the page is gone or fixed when it’s still hacked.”
— web.dev, Fix the Japanese keyword hack
This is why I always tell clients not to judge their site by how it looks in their own browser. I cover the exact checks (URL Inspection, site: searches, Search Console reports) in my companion guide on 12 SEO warning signs that your site has been hacked.
“This site may be hacked” and other Google warnings your visitors see
Even before any ranking drop, Google may start warning people about your site. These warnings do the most direct damage, because they stop clicks you would otherwise have won.
According to web.dev’s guide to sites hacked with malware, there are two main labels in search results:
- “This site may be hacked” appears when Google thinks a site has been hacked to show spam, but not to spread malware.
- “This site may harm your computer” appears for malware. Visitors may also hit a full-page browser warning (an interstitial) before they can reach your site.
The Search Console Security Issues report help page adds that Chrome may show a “Dangerous” warning in the address bar for affected pages. If you have ever seen a bright red warning screen in Chrome, you know how few people click past it. For a business, that is close to losing the visit entirely.
The Security Issues report groups problems into hacked content, malware and unwanted software, and social engineering (deceptive pages). Under “hacked,” it lists malware, code injection, content injection and URL injection. That is the first place to look, and you can learn the basics of the tool in our lesson on Google Search Console for beginners.
Manual actions, spam updates and pages dropping out of the index
Warnings are one problem. Rankings are another. A hack can pull your rankings down in three separate ways, and it helps to know which is which.
- A security issue flag. This shows up in the Security Issues report. It mostly works through the warning labels above, and Google says a fix must cover the whole site: “Fixing the issue on just some pages will not earn you a partial return to search results.”
- A manual action. This is a human reviewer at Google applying a penalty. The Manual Actions report help page lists types that commonly follow a hack, such as “Cloaking and/or sneaky redirects,” “Sneaky mobile redirects,” “Hidden text and/or keyword stuffing,” and “Site abused with third-party spam.” Google says most actions result in “pages or sites being ranked lower or omitted from search results.” Our explainer on Google manual actions and how to fix them goes deeper.
- An algorithmic hit. No message, no email. Google’s automated spam systems simply see thousands of spam pages on your domain and trust the site less. If a spam update rolls out while your site is still infected, the damage can be larger. I have covered that exact case in recovering when a hacked site gets caught in a spam update.
On top of that, there is plain index pollution. If 20,000 spam URLs are injected into a 60-page site, Google now spends its crawling on junk. Your real pages may be crawled less often, and the spam URLs can stay in the index for weeks after you delete them. That is why the cleanup has to include getting those URLs out of Google, which I explain step by step in my SEO cleanup plan for recovering rankings after a hack.
How long Google takes to lift hack warnings and penalties
People often ask me, “If I fix it today, will the warning be gone tomorrow?” Sadly, no. Google’s own help pages give these ranges:
| What you fix | What you request | Google’s stated timing |
|---|---|---|
| Security issue (hacked content, malware, deceptive pages) | “Request Review” in the Security Issues report | “A few days to a few weeks” (Security Issues help) |
| Manual action | Reconsideration request in the Manual Actions report | “Several days or weeks” (Manual Actions help) |
| Algorithmic spam signals | Nothing to request | No stated timing; trust returns as Google re-crawls a clean site |
Two rules matter here. First, don’t ask for a review until the site is fully clean. Google warns that submitting too early “can cause longer turnaround time for the next request.” Second, don’t resubmit while a request is still pending. Patience is part of the process.
What a PHP2Shell hack could cost a small business in traffic and leads
Numbers make this real, so let me walk through a simple example. This is a hypothetical example, not a client result.
Say a local dental clinic gets 3,000 organic visits a month from Google. About 2% of those visitors book an appointment, so that is 60 new patient bookings a month from SEO. If an average new patient is worth $400 in the first year, organic search brings in about $24,000 a month in first-year value.
Now imagine the site is hacked with gibberish pages on October 25 and nobody notices for two weeks:
- Weeks 1–2: Spam pages get indexed. Some mobile visitors from Google are redirected to a scam site. Bookings fall, say by a quarter, to about 45 a month pace.
- Weeks 3–5: Google adds “This site may be hacked” to results. Click-through drops sharply. Suppose traffic halves, so bookings fall to about 30 a month pace.
- Weeks 6–8: The site is cleaned and a review is requested. Labels are lifted after about two weeks, but rankings take longer to settle.
Even with these fairly gentle guesses, the clinic loses roughly 40–50 bookings over two months. That is around $16,000–$20,000 of first-year patient value, plus the cost of cleanup and the stress. And this ignores the reputation hit if patients saw a scam page with the clinic’s name on it.
Compare that with the cost of prevention: a PHP update that, on most managed hosts, takes minutes to request. The math is not close.
The trust cost you can’t put in a spreadsheet
There is a softer cost too. Patients, customers and partners who see a red warning or land on a spam page don’t forget it easily. If the hack also leaked memory from your server, which Wiz says these bugs can do, you may have a data breach to handle. That is a legal and trust problem, not just an SEO one. Security is part of how Google and people judge trust, which is why we treat it as a ranking basic in our lesson on HTTPS and website security for SEO and in our post on why security matters for SEO.
What to do today: patch PHP, call your host, add a WAF, check backups
Here is how I would handle it if this were my own site. None of this needs coding skills. Most of it is asking the right person the right question.
- Find out your PHP version. In WordPress, go to Tools → Site Health → Info → Server. In most hosting control panels (cPanel, Plesk and similar), there is a “PHP version” or “Select PHP version” screen.
- Get onto a fixed version. You need PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer, per php.net. If you are on 8.1 or older, ask your host whether they have applied a vendor backport, or plan an upgrade to a supported branch. Note that php.net also says PHP 8.2 reaches end of life on December 31, 2026, so 8.3 or newer is the better target.
- Message your host in writing. Ask: “Have you patched PHP for CVE-2026-109618 and CVE-2026-109619 on my server? Which exact PHP version am I running now?” On shared and managed hosting, the host usually patches PHP, not you. Get a clear yes or no.
- Turn on a web application firewall (WAF) if you can’t patch today. Wiz says Cloudflare, Fastly, Google, Vercel, Akamai, AWS, Microsoft, Imperva and Automattic have provided guidance or mitigations. A WAF is a filter in front of your site that blocks known attack patterns. It buys time; it does not fix the bug.
- Check your backups before you need them. Make sure you have a recent, off-server backup from before October 21, and that you know how to restore it. A clean backup is the fastest way back if something goes wrong.
- Change important passwords after patching. Because the bugs can leak memory, rotate admin passwords, database passwords and API keys once you are on a fixed version.
- Set up Search Console alerts. Make sure your site is verified and that email notices go to someone who reads them. Check that no unknown users have been added as owners.
Be careful with one shortcut. php.net mentions partial mitigations, but it is very clear that they are not enough on their own:
“There are no complete mitigations, updating is the only safe choice.”
— The PHP Group, PHP 8.5.12 release announcement
Wiz says the same thing in different words: “Applying the PHP security update remains the only complete remediation.” And the PHP Foundation, as reported by Fortune, urged sites to patch immediately or take their sites down until they could. If you have a small brochure site on an old server and your host can’t give you a date, a short maintenance page is better than an open door.
A quick plan by type of site
| Your setup | Who patches PHP | Your job today |
|---|---|---|
| Managed WordPress hosting | Usually the host | Confirm in writing; check Site Health shows a fixed version |
| Shared hosting with cPanel or similar | Host patches PHP builds; you may pick the version | Select a fixed 8.3+ version; test the site; ask host to confirm |
| VPS or dedicated server | You or your developer | Update PHP packages, restart all PHP workers, verify version |
| Very old site on PHP 7 or 5 | Nobody, unless a vendor backport exists | Add WAF, plan an urgent upgrade or rebuild; consider maintenance mode |
If an upgrade breaks an old theme or plugin, that is a sign the site needs proper care anyway. Our web development team handles this kind of upgrade work regularly.
Signs PHP2Shell may already have hit your server
Patching closes the door. It does not remove anyone who already got in. Wiz did not publish file hashes or IP addresses, but it did list behavior to watch for in server logs:
- Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 errors
- Unexpectedly large or malformed
PHPSESSIDcookies - Unexplained PHP worker churn (PHP processes crashing and restarting)
On the SEO side, the signs are different: strange foreign-language or pharma queries in your Search Console Performance report, a sudden jump in indexed pages, new unknown owners in Search Console, or Google results for your site that you don’t recognize. I list all twelve checks, with exactly where to click, in the hacked site warning signs guide. If you find anything, follow the step-by-step plan in recovering rankings after a website hack, and read Google’s “Help, I’ve been hacked” guides on web.dev.
Questions site owners are asking about PHP2Shell and SEO
Will patching PHP alone protect my Google rankings?
Patching stops new break-ins through these bugs. It does not undo a hack that already happened. If spam pages or redirects were added before you patched, they stay until you remove them, so check for signs of compromise too.
My site looks normal. Can it still be hacked?
Yes. Many SEO-spam hacks use cloaking, which shows Google one thing and you another. Use Search Console’s URL Inspection tool and the Security Issues report rather than just visiting your homepage.
Does a “This site may be hacked” label mean Google has penalized me?
Not exactly. It is a security warning, not a manual action, but it can cut your clicks sharply. A hack can also trigger a separate manual action, such as for cloaking or sneaky redirects, which you would see in the Manual Actions report.
How long will it take to get my rankings back after a hack?
Google says security reviews take a few days to a few weeks after you request one. Rankings can take longer to settle, depending on how much spam was indexed and how quickly Google re-crawls your clean pages.
I’m on PHP 7.4. Am I safe because I’m not on PHP 8?
No. Wiz says every PHP version released in the last decade is affected by at least one of the bugs, and PHP 7.4 gets no official update. Ask your host about a backport and plan an upgrade to a supported version.
Protecting your Google visibility this week, not next month
Let me sum it up simply. PHP2Shell is a real, confirmed, critical problem with a real fix. The fix is boring: get onto a patched PHP version, confirm it with your host, put a firewall in front if you must wait, and keep a clean backup. The SEO damage from a hack, on the other hand, is not boring at all. Spam pages, redirects, red warnings and manual actions can take weeks to undo.
I suggest you spend thirty minutes today on the checklist above. If you are not sure what PHP version you run, whether your site is already infected, or how to clean up Google’s index, we can help. Our SEO team handles technical audits and hack recovery, and our penalty recovery service covers manual actions. Get a free, no-obligation quote and we will tell you plainly where you stand.
Further reading on PHP2Shell SEO impact
- Has Your Site Been Hacked? 12 SEO Warning Signs to Check Right Now
- Recovering Rankings After a Website Hack: A Step-by-Step SEO Cleanup Plan
Sources for this PHP2Shell SEO impact guide
- PHP Group: Security advisory and PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 releases (php.net, Oct 21, 2026)
- Wiz Research: PHP2Shell – AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Oct 21, 2026)
- Fortune: AI tools discovered the PHP vulnerability… (Oct 21, 2026)
- ABC7 Chicago: PHP vulnerability – websites shut down globally (Oct 22, 2026)
- W3Techs: Usage statistics of PHP for websites (data Oct 22, 2026)
- Google Search Central: Spam policies for Google web search
- Search Console Help: Security Issues report
- Search Console Help: Manual Actions report
- web.dev: Hacked with malware
- web.dev: Fix the Japanese keyword hack
- web.dev: Fix the gibberish hack
- web.dev: Fix the cloaked keywords and links hack
