On 21 October the PHP project released a security update, and on the same day researchers at Wiz published PHP2Shell, their write-up of critical remote code execution flaws in core PHP. If your business has a website, there is a strong chance it runs on PHP. WordPress and WooCommerce do. Magento does. Drupal, Joomla and Laravel do. Wiz puts the figure at roughly 70% of all websites.
The short version: until the server your site sits on is running a patched version of PHP, an attacker who has never logged in, never bought anything, and never had an account can potentially run their own code on it. That is the worst category of flaw there is.
The problem is underneath your website, not inside it
This is the part that catches owners out. Most security advice you have heard is about your site: update your plugins, use a strong password, do not install dodgy themes. None of that helps here.
According to the Wiz research, the bugs are in the PHP engine itself, in the way it cleans up after a request runs out of memory. Wiz states that exploitation does not depend on any flaw in your application code, and that even a simple "Hello World" page on a vulnerable PHP version can be attacked. They demonstrated unauthenticated remote code execution against the latest official container images for WordPress, Drupal and Joomla, but they are explicit that those were representative targets, not the cause.
There is a second impact that gets less attention and deserves more. Separately from running code, Wiz says attackers can read raw memory out of the PHP process, and that this memory can contain passwords, authentication tokens, API keys and certificates belonging to other requests. Think payment gateway keys, mail service credentials, admin session tokens. No code execution required.
Wiz reports that every PHP release in the last decade is affected by at least one of these issues, going back to version 5.4, with severity reaching CVSS 9.2 across two CVEs.
Why this one does not wait for the next maintenance window
Normally I would tell a business owner that a security update can sit in the queue until the next scheduled release. Not this one, for three reasons.
First, the technical details are now public. Wiz published the exploitation chain in detail on the same day the patch landed. Second, there is no authentication barrier, so there is nothing an attacker has to get past first. Third, and this is the uncomfortable part, Wiz's own timeline shows the first vulnerability was discovered on 19 August and unauthenticated code execution was confirmed against Drupal the next day. The gap between "this bug exists" and "here is a working exploit" was measured in days.
The discovery was AI-assisted. Wiz credits frontier models with making the exploit development practical, and argues that complexity is no longer a meaningful barrier to exploitation. In the Hacker News discussion of the disclosure, several commenters pushed back on the framing, noting that the underlying code was decades old and that no compute costs were disclosed, and one accused the security industry of branding vulnerabilities to sell product. Others, including Simon Willison, raised a more pointed concern: the timeline suggests details may have leaked during the month-long coordination window, and a parallel write-up from the researchers at Calif appears to have begun disclosure even earlier.
You do not need to resolve that argument. Whether or not the marketing is overcooked, the patch is real and the exploit works.
What to ask your host or developer today
If you take one action from this article, make it a single email or phone call. You are not asking anyone to explain memory safety to you. You are asking four questions, and you want them answered in writing.
- What version of PHP is our site running right now? You want a specific number, like 8.3.x, not "the latest".
- Has the 21 October 2026 security release been applied, and on what date and time? "We're on it" is not an answer. "Applied at 9am Wednesday" is.
- If it has not been applied yet, when will it be, and what mitigation is in place in the meantime? Wiz notes that major providers including Cloudflare, AWS, Akamai, Fastly and Automattic prepared mitigations for customers who cannot patch immediately. A web application firewall rule is a stopgap, not a fix.
- Has anything in our logs suggested an attempt? Wiz lists specific signals to look for: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker churn.
If you are on managed WordPress hosting with a reputable provider, there is a decent chance this was handled for you overnight. Ask anyway, and get the date in writing. If you are on a cheap shared plan, or on a server a developer set up for you in 2021 and has not touched since, assume it has not been handled until someone proves otherwise.
Patching closes the door, it does not undo what walked through
This is the step most businesses will skip. The flaw allows secrets in server memory to be read. Patching stops future reads. It does not invalidate a key that was already copied.
If your site handles payments, sends email through an API, connects to a CRM, or holds admin sessions for staff, the sensible follow-up is to rotate those credentials after patching. Payment gateway keys, SMTP and transactional email keys, any third-party API tokens, and admin passwords. It is an hour of annoying work. It is cheaper than finding out in March that someone has had your mail API key since October.
There is no public evidence of mass exploitation before disclosure. There is also no way for most small businesses to prove the negative. Rotating keys is the cheap insurance.
If nobody can answer, that is the answer
The thing worth noticing this week is not the bug. Bugs happen. It is how quickly you can get a straight answer about your own infrastructure.
A business that can find out its PHP version and patch date within a few hours has a functioning relationship with whoever runs its servers. A business that sends three emails and gets silence has an operational problem that predates this vulnerability and will outlast it. When we take over an existing build at CodeDrips, the first thing we want is a written inventory of what the site runs on and who is responsible for updating each layer of it. Not because it is interesting, but because days like today are when the absence of one costs money.
So: send the email now. Ask for the version number, the patch date, the mitigation if it is not patched, and a log check. Then schedule a credential rotation for the week after. If the answers do not come back, you have learned something important, and it is worth acting on before the next one of these lands.
