If your website runs on WordPress, PrestaShop, Moodle or almost any content management system, it runs on PHP. And in October 2026 PHP had one of the most serious flaws in its history: two vulnerabilities, nicknamed php2shell, that let a stranger run code on your server with no username or password.
This isn't a technical manual for system administrators. It's what I would do if I owned a website, an online shop or a professional practice and wanted to know two things: am I exposed, and what happens to my reputation if someone has already got in.
What happened, and when
- 17 October. Amazon spots the first exploitation attempts, four days before the flaw is made public.
- 20 October. The PHP team announces a critical security release for the following day.
- 21 October. Fixed versions come out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The same day the US cybersecurity agency (CISA) urges everyone to patch immediately.
- 23 October. PHP reports a third, session-related flaw, CVE-2026-115560, which it considers unlikely to be exploited and will fix in its next regular release.
- 26 October. CISA adds the two main flaws to its catalogue of actively exploited vulnerabilities.
The two main flaws are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. What makes them so dangerous is when they happen: PHP processes them as the request arrives, before a single line of your website runs. It doesn't matter if WordPress is up to date, if you have a security plugin or long passwords. If the server's PHP version isn't fixed, the door is open.
How to tell if your website is exposed
The only thing that matters is the PHP version the server uses to serve your site. Not the one on your computer, and not what a plugin says.
| PHP branch | Fixed version | What to do |
|---|---|---|
| 8.5 | 8.5.12 or later | Check the server already has it |
| 8.4 | 8.4.27 or later | Same |
| 8.3 | 8.3.36 or later | Same |
| 8.2 | 8.2.35 or later | Update now and plan the move: 8.2 loses support on 31 December 2026 |
| 8.1, 8.0, 7.4 or older | No official fix | Ask your provider whether they've applied their own patch and, if not, migrate |
Three ways to check, from easiest to most technical:
- Ask your hosting company. A one-line email: "Which PHP version serves my domain, and does it include the php2shell patches from 21 October?". Decent providers have been updating for days and usually answer quickly.
- Look in your hosting control panel. Almost all of them show the PHP version for each domain.
- In WordPress, go to Tools, Site Health, the Info tab, Server section: the PHP version is listed there.
You can also use our PHP checker (in Spanish): type your domain and it tells you whether the server shows an affected version. If the server hides it, which is the right thing to do, it will tell you that too, and then the answer lies with your hosting company.
Watch out for a common trap: some Linux distributions apply the fix without changing the version number. If your server shows an old version but your provider says it's patched, ask them to confirm it in writing.
We use PHP too. The first thing we did on the 21st was check that our server already had the fixed version. I'd do the same today, not next week.
If you can't update yet
The official PHP advisory is clear: no temporary measure replaces updating. In the meantime, your provider can disable `session.upload_progress.enabled` in the server configuration (not from your website), limit request sizes and restart the PHP processes. That reduces the risk; it doesn't remove it.
Signs that someone may have got in
Exploitation started on 17 October, so updating isn't enough if your site was exposed during those days. You have to look back. These are the signs we see most often when a website has been compromised, whether through this flaw or another:
- Pages from your domain you never created show up on Google, often in Japanese or selling pharmacy products, replicas or gambling. Search `site:yourdomain.com` and go through the results.
- Google shows a warning under your site saying it may have been hacked, or Chrome displays a red screen when people visit.
- Search Console emails you about "Security issues".
- Your customers receive emails or texts in your name that you didn't send.
- There are new administrator accounts, recent PHP files in image folders or scheduled tasks nobody remembers creating.
- The server logs show "out of memory" errors on "Unknown on line 0" or processes crashing with "Segmentation fault" since mid-October. Your technician or hosting company has to check this, but it's worth asking about it specifically.
No single sign proves anything. Several together should make you act.
If they got in: the order I'd follow
1. Keep the evidence before cleaning up
The natural reaction is to delete everything strange as soon as possible. That's a mistake. If you later need to report it to the police, claim against a provider or show the data protection authority that you acted diligently, you'll need to know what happened and when. Ask your hosting company for a full copy of the files, database and logs as they are now, and keep dated screenshots of the Google results and warnings. If the case might end up in court, it should be certified properly, as we explain in chain of custody for digital evidence (in Spanish).
2. Close the door and clean up
Update PHP, change every password (hosting panel, FTP, database, website administrators, email), review user accounts and restore from a backup made before 17 October if you have one. Restoring a backup without updating PHP first only lets them back in.
3. Decide whether there has been a personal data breach
This is where many people get it wrong. If your website held customer data (contact forms, orders, user accounts, records, CVs) and the attacker could reach it, that's a personal data breach under the GDPR, even if you have no proof they took it.
- The regulator: Article 33 of the GDPR requires you to notify your data protection authority (in Spain, the AEPD) within 72 hours of becoming aware of the breach, unless it's unlikely to put people at risk. The AEPD has an online tool, Comunica-Brecha RGPD, that helps you decide whether you must also tell the people affected.
- The people affected: Article 34 requires you to tell them when the risk is high, for example if passwords, health data, ID documents or bank details were involved.
Not having all the information isn't a reason to wait. The GDPR allows notification in stages: first what you know, then what you find out. What does count against you is staying silent.
In Spain, INCIBE's 017 helpline gives free technical advice to businesses and individuals.
4. Ask Google to remove the warnings
Once the site is clean, in Search Console, under Security and Manual Actions, Security issues, there's a button to request a review. Explain specifically what you did (PHP updated, files removed, passwords changed). If the review goes well, the warning disappears from the results, usually within a few days.
The junk pages planted on your domain may keep appearing for a while. If they already return a 404 or 410 error, Google will drop them gradually; for the most visible ones you can use the URL removal tool in Search Console.
What does the most damage to your reputation
From the cases that reach us, the damage rarely comes from the attack itself. It comes from what customers see afterwards: a red Google warning when they search for your brand, fraudulent emails carrying your logo, or a news story or social media post saying your data leaked and you said nothing.
Three things reduce that damage a lot:
- Tell people first. A clear email to your customers, without jargon or excuses, saying what happened, which data may be affected and what they should do (change their password, distrust emails asking for payments). People who hear it from someone else tend to assume the worst.
- Have a short answer ready for anyone who asks by phone, on social media or in reviews, and make sure the whole team says the same thing.
- Watch what's published about your brand in the following weeks. Stolen data sometimes ends up on forums or Telegram channels, and it needs to be spotted early to request its removal.
If the story is already out, our guide to a business reputation crisis in the first 72 hours (in Spanish) applies almost as it stands, and data leak after a hack (in Spanish) explains what to do if your data or your customers' data appears online.
What we can't do, and what we can
We're an online reputation agency, not a cybersecurity firm. We won't clean your server; that's a job for your hosting company or a systems technician. What we do is what comes next: getting Google to remove warnings and junk results, finding leaked data and requesting its removal, preparing communication with customers and the press and, with the law firm we work with, assessing what legal action makes sense.
If your website has been attacked and you don't know where to start, tell us in the free analysis. If we see that your problem is purely technical, we'll say so and won't waste your time.
