Your WordPress website is working. Your plugins are updated. Everything looks normal. Then you hear about a critical PHP vulnerability that could let attackers into websites without a password.
Naturally, your first question is probably, “Does this affect my website too?”
Here’s what made the October 2026 PHP security scare different. The problem wasn’t in WordPress itself. It was in PHP, the programming language that WordPress runs on. So even if you updated WordPress, your website could still have been using a vulnerable PHP version.
And yes, AI helped researchers uncover the bug. But before getting into that story, there’s something more useful to know: you can check which PHP version your WordPress site uses right from the dashboard.
We’ll show you where to look, which versions received fixes, how to update PHP safely on Cloudways, and how to check Google Search Console if you’re worried about your website’s traffic.
Not exactly. Researchers found two critical vulnerabilities in PHP, not WordPress Core. PHP released fixes on October 21, 2026. If your website runs on PHP, check whether your host installed the patch. A vulnerable version doesn’t mean someone hacked your website, but it does mean you need to act.
What Actually Happened to PHP?
On October 21, 2026, PHP released emergency fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. The security research behind the incident became known as PHP2Shell.
Both flaws involved problems with how PHP handled memory. In certain situations, attackers could exploit those problems to run code on the server without signing into WordPress or having an administrator account.
Normally, if someone wants to change your WordPress website, they need access to the admin area or another vulnerable entry point. With PHP2Shell, researchers demonstrated attack paths that worked below WordPress itself.
CVE-2026-109618
PHP could leave parts of its internal memory in an unsafe state after an out-of-memory error. Under certain conditions, attackers could use that state to execute code.
CVE-2026-109619
PHP could reuse internal data after the memory holding it had already been released. Researchers showed how this could also lead to code execution.
The important part isn’t memorizing those CVE numbers. It’s understanding why updating WordPress alone didn’t solve the problem. PHP runs underneath WordPress, and that’s where the fixes needed to go.
In its technical analysis of the PHP vulnerabilities, Wordfence explains why a WordPress Core update, plugin update, or theme update cannot replace the PHP security patch.
Imagine someone making your server run instructions that you never approved, without needing your WordPress password. That’s the risk researchers demonstrated. It doesn’t mean every vulnerable website was successfully taken over, but it explains why the PHP security team treated this as urgent.
So, Did AI Really Find This PHP Vulnerability?
Yes. And this is probably the most interesting part of the story.
Researchers at Wiz were studying PHP with help from AI tools when they uncovered the flaws. According to the team’s PHP2Shell research disclosure, Wiz used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol during its investigation. Gemini 4 Argon played a particularly important role in finding and validating the weaknesses.
The researchers didn’t stop at finding suspicious code. They tested whether the problems could actually be exploited and demonstrated unauthenticated attacks against WordPress, Drupal, and Joomla.
Here’s why that matters. PHP has been around for decades, and these particular weaknesses had remained in its code for years. AI-assisted research helped investigators work through complicated memory behavior and develop working demonstrations much faster.
No. Researchers used AI-assisted tools to discover and demonstrate the flaws in controlled testing. They worked with PHP maintainers and other security organizations on the disclosure and fixes.
There’s also a bigger cybersecurity lesson here. AI can help defenders discover weaknesses earlier, but similar capabilities could help attackers investigate old software too. That makes installing security updates even more important.
When Did the PHP Hack Happen?
The news broke in October, but the discovery happened earlier. Wiz had already confirmed attack paths involving popular content management systems before the public announcement.
| Date | What happened |
|---|---|
| August 19, 2026 | Wiz Research discovered the first vulnerability during AI-assisted security research. |
| August 20–21 | Researchers confirmed unauthenticated remote code execution against Drupal and WordPress in testing. |
| August 24 | Wiz reported the findings privately to the PHP security team. |
| October 20 | PHP announced that emergency security updates would be released the next day. |
| October 21 | PHP released patched versions and researchers publicly disclosed the vulnerabilities. |
| October 23 | Security authorities continued assessing attack reports and advising immediate patching. |
How Many Websites Were Actually Affected?
This is where the headlines need a little context. Wiz described PHP as powering roughly 70% of websites, which explains why the discovery caused so much concern. But that figure describes PHP’s reach, not the number of websites that were hacked.
WordPress wasn’t the only platform involved. Drupal, Joomla, and other PHP applications also faced potential exposure. Researchers demonstrated serious attack paths, while security providers observed attempts to exploit the vulnerabilities.
Some organizations temporarily took websites offline while preparing security updates. But taking a website offline as a precaution doesn’t mean attackers got into it.
What was confirmed?
Critical PHP flaws existed. Researchers demonstrated attacks. Emergency patches became available on October 21.
What wasn’t confirmed?
That every exposed WordPress website was hacked, or that every reported outage resulted from a successful attack.
Both vulnerabilities received a CVSS v4.0 severity score of 9.2 out of 10. That’s a critical rating for the technical risk. It doesn’t mean 92% of websites were compromised.
Which PHP Versions Are Safe From the October Vulnerabilities?
PHP released fixes for four maintained branches on October 21, 2026. The table below shows the first patched version for each branch.
| PHP branch | First patched release | What you should do |
|---|---|---|
| PHP 8.2 | 8.2.35 | Install the patch and plan to move to a newer supported branch before PHP 8.2 reaches end of life. |
| PHP 8.3 | 8.3.36 | Use this version or a later patched release. |
| PHP 8.4 | 8.4.27 | Use this version or a later patched release. |
| PHP 8.5 | 8.5.12 | Use this version or a later patched release. |
PHP confirmed these versions in its official October security release announcements.
You may have seen recommendations to update specifically to PHP 8.2.35. That version does fix the two October flaws, but it isn’t the only patched release. PHP 8.2 also reaches end of life on December 31, 2026, so moving to a newer supported branch may make more sense if your website is compatible.
Some hosting providers backport security fixes without changing the version number displayed in WordPress. Ask your host whether its PHP package includes fixes for CVE-2026-109618 and CVE-2026-109619 before deciding that the server is unpatched.
Where Can You Check Your PHP Version in WordPress?
This is the first thing we’d check on any WordPress website after seeing the news. You don’t need a separate plugin, server access, or coding knowledge.
Open your WordPress dashboard and follow this path:
That’s it. You’ll see the version your WordPress website is actually running.
For example, if the page shows PHP 8.2.34, you’re looking at a version released before the emergency 8.2.35 update. You should confirm whether your host applied a security backport or needs to update the PHP package.
WordPress Site Health
Shows your PHP version. It helps you check the environment, but it doesn’t install PHP updates.
Your Hosting Dashboard
Controls PHP updates. This is where you choose or confirm the version running on your server or application.
How to Update PHP on Cloudways Without Breaking Your Website
So you’ve checked Site Health, and your PHP version needs an update. You might be tempted to head straight to Cloudways and change it.
Before you do that, take a backup. PHP powers important parts of WordPress, and an older plugin or custom feature might not work properly after you move to a newer branch.
For example, your homepage might load perfectly after the update, but a booking form or checkout integration could stop working. That’s why we recommend testing the important parts of the website, not just checking whether it opens.
Open WordPress Site Health and record the version displayed under Server. You’ll use this to confirm the update later.
In Cloudways, create an on-demand backup covering the website files and database. Wait for the backup to finish and make sure a usable recovery point is available.
Review the compatibility of your active plugins, theme, and custom integrations. If you’re switching to a newer major PHP branch, test the change on a staging website where possible.
Log in to Cloudways Flexible, select Applications, and open the WordPress application you want to update.
If your Cloudways environment supports application-level PHP selection, follow this path:
Choose a compatible, patched PHP version from the dropdown and click Proceed.
Once Cloudways finishes, return to WordPress Site Health. Check the PHP version again and confirm that the running environment has received the required security fixes.
Open your homepage, service pages, contact forms, WordPress admin, login area, and checkout if you run an online store. If something fails, check the server error logs instead of assuming the update completed successfully.
Check for admin accounts you didn’t create, unexplained redirects, unfamiliar PHP files, or changes you don’t recognize. Updating PHP fixes the underlying vulnerability, but it won’t automatically remove malicious code from a compromised website.
Cloudways documents this process in its application-level PHP update instructions. The feature is in public preview and depends on your Cloudways server environment. If you don’t see PHP Settings, check the appropriate server-level PHP controls or contact Cloudways Support.
Start with the error logs and identify which plugin, theme, or custom function stopped working. Use your verified backup when recovery is needed, and work toward a compatible patched environment. Don’t leave the website on vulnerable PHP as a permanent fix for a plugin problem.
Can the PHP Vulnerability Affect Your Google Rankings?
It can, but not in the way some people assume.
Google doesn’t automatically penalize a website just because its server previously ran a vulnerable PHP version. The problem begins when an attack or server failure affects what Google can crawl, index, or show in search results.
Imagine your website goes down during an update. Visitors see an error page, and Googlebot may see the same thing. Or suppose an attacker adds hundreds of spam pages to your WordPress database. Those pages could eventually appear in Google Search Console even when you never created them.
Repeated 5xx responses can make Google reduce crawling. Long-lasting outages can also affect indexing.
Attackers may create URLs targeting gambling, adult content, pharmaceuticals, or other unrelated searches.
Legitimate pages may start sending visitors or search engines to unauthorized websites.
Google may warn users about malware, phishing, or harmful content when its systems detect a security problem.
A short interruption during an update doesn’t mean your rankings will collapse. But if you’re concerned about a compromise or unexpected traffic changes, Google Search Console is a good place to start looking.
How to Check the PHP Hack’s Impact in Google Search Console
Search Console won’t tell you whether someone exploited PHP2Shell. For that, you need server logs, security monitoring, and evidence from the website itself.
What GSC can show you is whether Google encountered security warnings, server errors, strange URLs, or changes in search visibility around the incident.
1. Start With Security Issues
Where: Security & Manual Actions → Security Issues
Look for warnings about hacked pages, malware, phishing, or harmful downloads. If the report is empty, that’s encouraging, but it doesn’t prove nobody accessed the server.
2. Compare Search Performance
Where: Performance → Search results
Compare clicks and impressions before and after October 21. Look at the Pages and Queries tabs too. Strange search terms or sudden changes on important URLs deserve a closer look.
3. Look at Page Indexing
Where: Indexing → Pages
Check whether Google started reporting more server errors, redirects, or unfamiliar URLs. Don’t assume every excluded URL is malicious. Focus on changes you can’t explain.
4. Open Crawl Stats
Where: Settings → Crawl stats
Look for increases in 5xx responses, slower server response times, or changes in crawl activity around your patch date. Compare those signals with the actual hosting logs.
5. Inspect Important URLs
Where: URL Inspection
Test your homepage and key landing pages. Check whether Google can access them, when it last crawled them, and whether the indexed and canonical details look correct.
6. Check Manual Actions
Where: Security & Manual Actions → Manual Actions
This report is separate from Security Issues. A hacked website doesn’t automatically receive a manual action, but it’s worth checking during your investigation.
Here’s How We’d Interpret the Results
Suppose your website’s organic impressions drop after October 21. You check Crawl Stats and notice a spike in server errors. Then you look at Cloudways and discover the website was unavailable during a PHP update.
That’s a useful lead. It doesn’t prove PHP2Shell was exploited, but it gives you a reason to investigate server availability and Google’s crawling response.
Now imagine you find URLs about online casinos appearing in Search Console, even though your website has nothing to do with gambling. That points toward a different problem, possibly injected content. You would want to check your WordPress database, files, and user accounts.
Not before checking the website. Make sure the pages are clean, accessible, and returning the right HTTP responses. Repeatedly submitting URLs won’t fix a hacked page or a broken server.
We also covered the difference between Google fetching a page, rendering it, and actually indexing it in our Google crawl troubleshooting article. That distinction helps when a page is accessible again but still isn’t appearing in search.
If Google reports a security problem, use its Security Issues review process after cleaning the website. For an actual compromise, confirm the problem has been removed before requesting a review.
What If Your WordPress Website Was Already Hacked?
This is where we’d be especially careful about assuming that one update solves everything.
We’ve dealt with a WordPress compromise ourselves at MockCertified. An unauthorized administrator appeared, our homepage showed spam content, and the website had unwanted casino-related text.
We moved the blog to a clean AWS Lightsail server. For a moment, things looked better. But when we imported the old WordPress database, the spam came straight back.
It turned out the problem wasn’t limited to the original server. The malicious content had reached the database, including the homepage and several saved revisions. Moving the website hadn’t removed it.
We documented what happened in our WordPress hack recovery steps, including how we investigated the database, checked unauthorized access, and restored verified clean content.
That incident was separate from PHP2Shell, so we’re not suggesting the October PHP vulnerability caused our earlier hack. The connection is in what happens after a compromise: installing updates or changing servers doesn’t necessarily clean up everything an attacker left behind.
Preserve useful evidence, review unfamiliar accounts, remove malicious code and backdoors, rotate exposed credentials, and restore verified clean content. If the website stores sensitive customer information, bring in qualified security help.
What Can Cybersecurity Learners Take Away From PHP2Shell?
If you’re studying for CompTIA Security+ or another cybersecurity certification, this incident is a useful example of several concepts you’ll encounter in your preparation.
You hear terms such as vulnerability management, CVSS, patching, incident response, and risk assessment all the time. PHP2Shell shows how those ideas connect when a real security issue affects production websites.
Vulnerability Management
How do you identify affected systems, decide which flaws need urgent attention, and verify that a security patch is actually installed?
Risk Assessment
Why doesn’t a critical CVSS rating mean every website has already been compromised?
Incident Response
What should a team do if it discovers unauthorized changes, suspicious log entries, or malicious code after an attack?
Security Monitoring
Which server logs, security alerts, and file changes can help investigators understand what happened?
Try This Cybersecurity Practice Question
A company discovers that its WordPress website uses a PHP version affected by a critical remote-code-execution vulnerability.
A patch is available, but the website depends on an older plugin that may not support the newer PHP version.
What should the administrator do?
Assess exposure, verify a restorable backup, test compatibility where possible, apply the security patch promptly, confirm the application works, and check for signs of exploitation.
The goal is to remove the security exposure without unnecessarily disrupting the website. If compatibility problems appear, resolve them in a secure environment rather than leaving an unpatched server exposed.
Illustrative practice scenario, not an official certification exam question.
You don’t need to become a PHP developer to understand the lesson. Cybersecurity often involves knowing which problem matters most, what evidence to check, and how to reduce risk without creating a bigger operational problem.
If you’re considering cybersecurity as a career, our cybersecurity certifications comparison introduces options such as Security+, CISSP, and CEH. You can use it to explore which path matches your experience and goals, then check the current requirements directly with each certification provider.
Your PHP Vulnerability Checklist
Before you close the issue and move on to the next website task, make sure you’ve covered the basics.
- Check the PHP version currently running in WordPress Site Health.
- Confirm your hosting provider patched both October PHP vulnerabilities.
- Make sure you have a complete, restorable website backup.
- Update PHP through the hosting control panel when required.
- Test the homepage, forms, admin dashboard, and other important features.
- Review security logs, unknown user accounts, and suspicious file changes.
- Check Google Search Console for warnings, crawl errors, and unexpected URLs.
- Record the patch date and continue monitoring the website.
So, Is Your WordPress Site Safe?
The recent PHP vulnerability was serious, but seeing the headlines doesn’t mean someone has already hacked your website.
What matters is whether the PHP version running on your server has received the security fix.
We’d start with WordPress Site Health, confirm the patch with the hosting provider, and test the website after updating. If something looks suspicious, we’d check the server and WordPress environment instead of assuming the update cleaned everything.
And if you’re wondering whether the incident affected your search traffic, Google Search Console can help you investigate crawling, indexing, and security symptoms.
One final thing worth remembering: keeping WordPress updated is important, but keeping the software underneath WordPress updated matters just as much.
Frequently Asked Questions
What is the PHP vulnerability discovered in October 2026?
PHP2Shell refers to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. PHP released emergency fixes on October 21, 2026. Under vulnerable conditions, the flaws could allow attackers to execute code remotely without authentication.
Was WordPress hacked because of PHP2Shell?
PHP2Shell affected PHP rather than WordPress Core. Researchers demonstrated attacks against WordPress installations running vulnerable PHP, but that does not mean every WordPress website was successfully hacked.
Which PHP version fixes the vulnerability?
The first fixed releases were PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Use a currently supported patched version compatible with your website, or confirm an applicable backported security fix with your hosting provider.
Is PHP 8.2.35 safe to use?
PHP 8.2.35 includes the October PHP2Shell fixes. However, PHP 8.2 reaches end of life on December 31, 2026, so websites should plan to move to a newer supported branch where compatibility allows.
Can I update PHP directly from WordPress?
No. You can check the version through Tools → Site Health → Info → Server, but PHP updates usually happen through your hosting provider’s dashboard or server management tools.
Will updating PHP remove malware from my WordPress site?
No. Updating PHP fixes the vulnerable software but doesn’t automatically remove malicious files, unauthorized accounts, backdoors, or stolen credentials. A confirmed compromise needs a separate investigation and cleanup.
Can Google Search Console tell me if my website was hacked?
Search Console can report certain security problems and reveal unusual pages or crawling changes. It cannot confirm whether attackers exploited PHP2Shell. You’ll need server logs and other security evidence for that.
Can a PHP vulnerability affect Google rankings?
It can indirectly affect search visibility if the incident causes extended downtime, malware warnings, spam pages, or malicious redirects. Simply having an outdated PHP version does not automatically trigger a Google ranking penalty.
Is PHP2Shell relevant to cybersecurity certification exams?
Yes. It connects to vulnerability management, CVSS severity scoring, patch management, risk assessment, monitoring, and incident response. These concepts appear in several cybersecurity certification programs.
Published October 2026. Security information reflects the disclosures available at publication. Always confirm your hosting provider’s current patch status before changing a production website.
