Zero-Day vs N-Day: How Hackers Use a Flaw After It’s Fixed
When I wrote up the PHP2Shell vulnerabilities, the obvious question is a fair one. If the researchers found it first and reported it, how did attackers end up using it at all?
The answer is the part of security most people never hear about: the moment a flaw is fixed is often the moment it becomes dangerous. This post explains how that works, in plain words, with PHP2Shell as the example.
What is the difference between a zero-day and an n-day vulnerability?
A zero-day is a flaw that attackers use before any fix exists. An n-day is a flaw that attackers use after a fix has been released, against the systems that have not installed it yet. The names count days. "Zero-day" means the people who maintain the software have had zero days to respond. "N-day" means the fix has been out for some number of days, and the attack works only because somebody has not applied it. (You will sometimes see "one-day" for the first day or so after a fix, when it is at its most dangerous.)
Zero-days get the headlines, and they are rare and valuable, so they tend to be used carefully against high-value targets. N-days are what actually happen to ordinary websites. The fix exists, the attack is known, and the only thing standing between a site and an attacker is whether somebody has installed the update.
PHP2Shell was both. A handful of attempts came before the fix was released on October 21, 2026, which made it briefly a zero-day. Then, once the details were out, it was an n-day, tried against servers by the million.
What is a CVE?
A CVE is a public ID number for a specific security flaw, so everybody can refer to the same problem by the same name. CVE stands for Common Vulnerabilities and Exposures, and the numbers look like CVE-2026-109618: the year, then a sequence number. The ID itself says nothing about how bad a flaw is.
How bad it is comes from a separate severity score, usually CVSS, on a scale of 0 to 10. Anything from 9 up is rated critical. PHP rated both PHP2Shell flaws 9.2, largely because an attacker needs no password and no help from the site to take over the server.
How does a vulnerability go from discovery to attack?
Most serious vulnerabilities follow the same path: found, reported privately, fixed in secret, released, reverse-engineered from the fix, and then swept across the internet. Here is each step, and what happened at each one with PHP2Shell.
One. Somebody finds it. Usually a security researcher, sometimes the maintainers themselves, and sometimes an attacker. If an attacker finds it first and keeps quiet, it stays a zero-day for as long as the secret holds. PHP2Shell was found by two research teams in August 2026, both using AI.
Two. It is reported privately. The finder tells the maintainers and nobody else, and everyone agrees to stay quiet until a fix is ready. This is called coordinated disclosure, and it is the reason most serious flaws have a fix on the day the public hears about them. Wiz reported PHP2Shell to PHP's security team on August 24.
Three. The fix is built in secret. The maintainers write and test a fix. Companies that package the software, such as the Linux distributions most web servers run, often get early copies so everyone can ship on the same day. For PHP2Shell, that quiet period lasted about two months.
Four. The fix is released. The maintainers publish the fix along with an advisory saying which versions are affected and how serious it is. PHP released its fix on October 21.
Five. Attackers work backwards from the fix. This is the step most people do not know about, and it gets its own section below.
Six. The sweep. Attackers point automated tools at the whole internet, looking for any server still running an affected version. With freely available scanning tools, every address on the internet can be checked in under an hour. Cloudflare saw tens of thousands of PHP2Shell attempts within 45 minutes of the news breaking.
Seven. The long tail. The sweeps never really stop. Sites that are not updated stay on the list for months and years. According to a roundup of Wordfence's reports, one WordPress plugin flaw fixed in February 2026 was still being attacked in June, July and August, with more than 100,000 attempts blocked.
Can hackers use a security fix to find the vulnerability?
Yes. A published fix shows exactly what was broken, and comparing the code before and after the fix is one of the main ways attackers build working attacks. Security people call it patch diffing. It is most direct for open-source software like PHP and WordPress, where the code change itself is public, but it works on closed software too, by comparing the old and new programs.
A fix is a bit like a recall notice for a lock. It protects everybody who acts on it, and it tells everybody else exactly which locks to try. That is not a reason to keep fixes secret, because the people already attacking a flaw do not need the notice. It is the reason the time between a fix being released and a fix being installed matters so much.
Working an attack out from a fix used to take a skilled person days, sometimes weeks. That is changing. After July's wp2shell flaw in WordPress, a security firm testing it said AI made reproducing the bug and building a working attack "trivial." When that step takes hours instead of weeks, release day becomes attack day.
How do vulnerabilities leak before they are fixed?
Vulnerabilities leak because a coordinated fix involves a lot of people, and because two people can find the same flaw independently. Every maintainer, partner company and organization let in on the secret is one more chance for it to get out. Even an ID number showing up early can be enough to tell attackers where to start looking.
With PHP2Shell, the vulnerability IDs started circulating online on October 20, and PHP moved its release up a day to get ahead of them. Earlier still, on October 17, Amazon logged an attack attempt against one of its decoy servers, and nobody has said publicly how that attacker knew. A leak is one possibility. The other is that somebody found the same flaw on their own. Security people call that a bug collision, and it is getting more likely: PHP2Shell was found twice in a few weeks, by two teams using tools anyone can use.
What can an attacker do with a vulnerability on my website?
It depends on the flaw, and the worst kind, remote code execution, lets an attacker do almost anything your web server can do. "Remote" means from anywhere on the internet. "Code execution" means the server follows their instructions as if they had sat down at it. PHP2Shell was that kind. In practice, an attacker with that access can:
- Read what the server holds: the database, customer details, passwords and the site's own files.
- Create hidden admin accounts so they can get back in later, even after the flaw is fixed.
- Plant a backdoor, a small file that lets them run commands whenever they like.
- Use your site against other people: sending spam, hosting scam pages, or serving malware to your visitors.
- Move deeper, from the web server into other systems on the same network.
This is not hypothetical. After wp2shell, Wiz found attackers uploading malicious plugins, creating more than 100 backdoor admin accounts and planting small programs that let them run commands on the server. After PHP2Shell, one business owner told Fortune that attackers had taken their source code and leaked legal documents.
It is also why updating is not always the end of the job. A fix closes the door. It does not remove anybody who already came through it. If a site sat unpatched while a flaw was being swept, somebody should check for accounts, plugins and files nobody added.
Smaller flaws are more common. Some let an attacker read information they should not, some only work if they already have a login, and some can only knock a site offline. Those still matter, and they are why the severity score is worth reading.
Why is the n-day window getting shorter?
The n-day window is getting shorter because the step between a published fix and a working attack is being automated, increasingly with AI. Patchstack, which tracks WordPress security, looked at last year's most heavily exploited WordPress flaws and found a median of five hours between a flaw going public and attacks at scale. With PHP2Shell, it was minutes.
The window used to be days or weeks, and a monthly maintenance visit could mostly keep up with it. That is no longer true for serious flaws, and I go into what that means for developers in the PHP2Shell post.
How do I protect my website from n-day attacks?
You protect a website from n-day attacks by shortening the time between a fix being released and that fix being installed, and by running less software that can need one. Zero-days are mostly outside a site owner's control. N-days are not. In practice:
- Turn on automatic updates wherever they exist. WordPress can update itself in the background, and a firm that tracked wp2shell credited that with cutting down how many sites were exposed.
- Know who updates the parts you cannot. Your host usually looks after the server software, like PHP. Ask them how quickly they apply critical fixes, and get the answer in writing.
- Know who updates the rest, and how fast. If you have a developer or an agency, "within hours for a critical fix" is the answer you want, not "at the next monthly visit."
- Put something in front of the site. Firewall services such as Cloudflare can block known attack patterns quickly. They are a stopgap, not a fix, but they buy time.
- Remove what you do not use. A deactivated plugin is still code on your server. Delete it. The WordPress post walks through that inventory.
- Run less, if you can. A site built from plain files, like this one, has no server software processing each visitor, so most of these flaws have nothing to attack. That is the case for hand-coded websites in one sentence, and it is not a reason to skip the rest of this list.
The takeaway
A zero-day is attacked before a fix exists. An n-day is attacked after, against everyone who has not installed it, and n-days are what happen to ordinary websites. The fix itself tells attackers where to look, and AI is shrinking the time it takes them to act on it from weeks to hours. The part you control is how long your site stays on the wrong side of that gap.
If you do not know who updates your site, or how fast, that is worth finding out this week. If you would like a second opinion, send me a message and I will tell you what I see.