Skip to content
PL Get a quote

What actually happened?

Every WordPress website has two layers. What you see in the dashboard (content, theme and plugins) is WordPress. Underneath it runs PHP: software on the server that puts the page together on every visit and sends it to the browser. Think of it as a hotel reception desk: it takes a guest’s request, prepares a response, then serves the next person.

In summer 2026, researchers at Calif and Wiz, working independently with the help of AI tools, found two faults at this reception desk. The first appeared when PHP ran out of memory and had to stop halfway through a job: it left unfinished “paperwork” behind, then treated it as valid. The second allowed leftovers from one request to survive into the next. A specially crafted request from the internet could exploit this and make the server run an attacker’s command, without a login or password.

The technical term is remote code execution (RCE), and it is the most serious kind of security flaw a website can have. The researchers demonstrated a working attack on WordPress and Drupal. The animation below gives a simplified explanation. Switch to “After the patch” to see the difference.

Timeline: from discovery to patch

The flaw did not appear out of nowhere. More than two years passed between the first clue and the patch, and more than two months between the researchers’ report and the fix. During that time, the details were kept private so that the PHP developers and server providers could prepare patches before criminals learnt about the problem.

  1. PHP audit

    The first clue

    During an external security audit of PHP, a developer noticed a problem with how it handled running out of memory. At the time, they found no way to exploit it.

  2. Calif

    Discovery and report

    With help from an AI model, Ryan Austin at Calif finds a way to take over a server and privately reports it to the PHP team on 11 August. Three days later, he supplies a working demonstration.

  3. Wiz

    A second team, the same problem

    Wiz researchers independently find the same bugs, demonstrate a takeover of WordPress and Drupal, and report further ways to attack on 24 August.

  4. OpenAI

    More ways to attack

    OpenAI reports further variants. The PHP developers work on a patch and share it in advance with operating system distributors and long-term support providers.

  5. Amazon

    The first attack attempts

    Amazon’s decoy servers, set up to look like potential victims, record the first attempts to exploit the flaw before the public announcement. Whether they succeeded is unknown.

  6. leak

    The identifiers appear online

    The CVE numbers start circulating on forums. Technical details stay private, but the PHP team publishes an advance notice and brings the patch release forward by a day.

  7. PHP

    Patches and warnings

    Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released. CERT Polska, the UK’s NCSC and the US’s CISA issue warnings the same day. Cloudflare has been blocking known attack patterns since the morning.

  8. gov.pl

    Government advice and server updates

    Poland’s Government Plenipotentiary for Cybersecurity recommends an immediate update. Hosting companies finish installing the patches on their servers.

One detail says a lot about 2026: both research teams found the flaws with help from artificial intelligence. Criminals have access to the same tools. That is why the time between a public announcement and the first attacks is now measured in hours rather than weeks.

What was the risk for an ordinary business website?

Remote code execution means an attacker can do much the same things on the server as the website itself: read its files and database, change them and add new ones. The researchers also showed that they could read the server’s memory, which can contain passwords and access keys for other services. Here is what that could mean in practice.

  • Data theft

    Customer details from forms and orders, the database password, and access keys for payment and email services stored on the server.

    For you: a personal data breach: notify your data protection authority within 72 hours (GDPR).

  • Stolen payment details

    A hidden script in your checkout form quietly copies the card details customers enter.

    For you: customers lose money, and you lose their trust.

  • Redirects to scam websites

    Some visitors, often only those arriving from Google or using a phone, end up at a fake shop or a page containing malware.

    For you: a red browser warning instead of your website.

  • Spam in Google

    Thousands of hidden pages advertising medicines, casinos or counterfeit goods appear under your domain.

    For you: a drop in search rankings, often only noticed weeks later.

  • Spam sent from your server

    The server starts sending spam and fake messages pretending to come from banks or delivery companies.

    For you: your normal emails start landing in customers’ spam folders.

  • Locked or deleted files

    A ransomware attack: your website’s files are encrypted so you cannot open them, or deleted, and the criminal demands a ransom.

    For you: the website stays offline until you restore a backup.

These are possible scenarios, not a record of what definitely happened. As of 22 October 2026, Amazon, Cloudflare and VulnCheck have confirmed attack attempts, some of them unsuccessful. Nobody has published a reliable count of websites taken over. To be clear: if your hosting company patched the server within a day, your website was most likely unaffected. If you do not know whether it did, it is worth checking.

Who was affected?

Almost everyone with a website running on PHP. It did not matter whether it used WordPress, Joomla, PrestaShop or a custom shop, or which server software was underneath. Every PHP installation handling requests from the internet was vulnerable. According to the PHP developers, the flaw goes back at least to version 5.4, released over a decade ago. CERT Polska warned about all versions from 5.0 onwards.

69.3%of websites with identifiable server technology use PHP (W3Techs, 22 October 2026)
39.6%of all websites use WordPress, which cannot run without PHP

What you need to do depends on your hosting setup. With ordinary shared hosting and a control panel, the hosting company updates PHP, and most had done so by 22 October. If you have your own virtual private server (VPS) or dedicated server, the update is your responsibility or that of whoever manages it for you. Websites built with services such as Wix or Shopify do not run on your own PHP installation, so there is nothing for you to do here.

How to check whether your website is safe

You only need one number: the full PHP version your website uses, for example 8.3.36. Each PHP release branch (8.2, 8.3, 8.4 and 8.5) received its own patch, so the last part of the number matters. Enter your version and I will explain what it means. Just below, I show you where to find it.

Where to find your PHP version (no technical knowledge needed)

You have three options. The first takes 30 seconds and only needs your WordPress login. If you do not have one, or your website does not use WordPress, try the second or third.

Asking about a restart is sensible. PHP runs in processes, which are programmes on the server that can keep running for weeks. Until they are restarted, some may still be using the old, vulnerable version.

How to spot a possible hack

Updating closes the door, but it does not tell you whether someone got in earlier. Work through this short checklist. None of it needs technical skills, and the whole thing takes about 15 minutes. Tick each item once you have checked it and everything looks right.

Something looks wrong? Do not delete anything yourself, as that could erase evidence. Contact your hosting company or whoever looks after your website. The next steps are to change all passwords (WordPress, hosting, database and email), restore a clean backup, update the software and ask Google to review the website again. If customer data may have leaked, notify your data protection authority within 72 hours (GDPR). You can also report attempted attacks to your national CERT (in Poland: CERT Polska).

Free tools that can help

None of these can tell you whether PHP is patched, because that is not visible from outside the server. They can help spot signs that your website has already been infected. All are free.

Google Safe Browsing site status

Checks whether Google has flagged your website as unsafe. This is the same database used by Chrome and Firefox.

Cost
Free
Checks
Google’s unsafe website list
Check with Google

Sucuri SiteCheck

Scans public pages for malicious code, spam and redirects. It cannot see files stored on your server.

Cost
Free
Checks
publicly visible code
Run a scan

Wordfence

A WordPress plugin that compares your website’s files with the originals and spots suspicious changes.

Cost
Free version available
Checks
WordPress files
How the scan works

Google Search Console

Google’s dashboard for website owners. It emails you if it detects a hack or spam on your domain.

Cost
Free
Checks
security issues
Open Search Console

Want to check your website’s speed, errors and visibility in Google too? I cover these in my SEO audit checklist.

What I did on my clients’ server

My clients’ websites run on a server I look after. On 21 October, the day of the announcement, I put security rules in place to block known attack attempts. On 22 October, I installed the official PHP patch. I sent clients a short message to say everything was fine and there was nothing they needed to do.

That is simply how I believe website maintenance should work: you run your business, and someone else takes care of things like this. For obvious reasons, I am not sharing the server’s configuration details here. If your hosting company has not said anything yet, this is a good time to ask.

Sources

  1. PHP security announcement (21 October 2026) official patches and recommendations, in English
  2. PHP Foundation: reporting and disclosure timeline and 9.2 severity rating
  3. CERT Polska: critical vulnerabilities in PHP in Polish
  4. Recommendation from Poland’s Government Plenipotentiary for Cybersecurity in Polish
  5. Calif: discovering PHP2Shell the researchers who reported the flaw
  6. Wiz: PHP2Shell the second research team
  7. Amazon: attack attempts before public disclosure
  8. Cloudflare: protection against PHP attacks
  9. WordPress.org: critical PHP security release advice for website owners
  10. W3Techs: PHP market share data from 22 October 2026

Questions about PHP2Shell