Zero-Days, Flat Networks, and Forgotten Servers: How One Hole Becomes a Full Breach

This article was written with the help of AI. We used an AI assistant to research recent attacks and draft the text, then reviewed it ourselves. Sources are linked throughout.

A zero-day is a security hole that attackers know about before the company that makes the software has a fix. The name means the vendor has had zero days to patch it. Until a patch ships, every copy of that software is open.

You cannot patch a zero-day on day one. What you can control is how far an attacker gets once they are in. A business with a flat network, old systems still online and nobody watching the logs turns one hole into a full breach. A business that keeps old systems offline, splits its network into zones and watches for odd behavior turns the same hole into a contained incident.

The Life of a Zero-Day

The dangerous window does not close when the patch ships. It closes when you install it, and for forgotten systems that is never.

1. Found. Someone discovers the flaw. If it is a researcher, they report it quietly. If it is an attacker, they keep it and use it.
2. Used in secret. Attackers hit high-value targets while nobody knows the hole exists. BeyondTrust's remote support tool was exploited for 47 days before the public heard about it.
3. Disclosed and patched. The vendor ships a fix and publishes an advisory. The clock is now public.
4. Reverse-engineered. Attackers compare the old and new code to see exactly what was fixed. Working attack code often appears within days.
5. Mass scanning. Automated tools sweep the whole internet for anything still running the old version. Size of business does not matter. Every exposed, unpatched server gets found.
6. The long tail. Months and years later, old systems that never got the update are still being broken into. At this stage the flaw is called an "n-day": known, fixed, and still working because nobody applied the fix.

Most small-business breaches happen in steps 5 and 6, not step 2. Attackers rarely spend a true zero-day on a 20-person company. They don't need to, because the old server in the closet is still running last year's holes.

What Just Happened: PHP, Node.js and the Rest of 2026

The last few months show every stage of that lifecycle at once. Each attack below teaches one lesson.

PHP2Shell (October 2026): One Request, No Login

On October 21, the PHP project shipped emergency fixes for two flaws, CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. They let an attacker run their own code on a web server without logging in. On servers using the older Apache mod_php setup, a single request can do it before the website's own code even runs.

PHP runs about 69% of the world's websites, including most WordPress sites. Amazon's honeypots recorded an attack attempt on October 17, four days before the public knew. Governments in the Netherlands, Finland, France and Canada pulled websites offline as a precaution, and the UK's NCSC told organizations to take any system offline that cannot be fixed quickly.

The lesson: the fixes only cover PHP 8.2 and newer, with do-it-yourself patches back to 7.4. Anything older, such as the PHP 5 site nobody has touched since 2016, may never get a fix. It has to come off the internet.

The npm Worms (Spring to Summer 2026): Your Tools Become the Attacker

Node.js projects pull in hundreds of small packages from the npm registry. Through 2026 a family of self-spreading worms, starting with "Shai-Hulud" and peaking with ChainDrop in August, hijacked those packages. Some of the infected packages are downloaded over 150 million times a week.

Installing an infected package was enough. The worm stole SSH keys, cloud passwords, GitHub and npm tokens, and secrets from build servers. Then it used the stolen tokens to infect more packages and spread on its own.

The lesson: a developer laptop or build server that can reach everything is a skeleton key. When it is compromised, everything it could reach is compromised too.

BeyondTrust Remote Support (August to October 2026): The Remote Access Tool Was the Door

A China-linked group exploited CVE-2026-102764 as a true zero-day for 47 days. Once inside, they planted a hidden web page to keep access, gained full control of the appliance, stole the passwords it stored, moved into the systems it connected to, and deleted the logs to cover their tracks.

The lesson: remote-access tools hold the keys to every system they manage. If logs only live on the box itself, the attacker erases them.

Citrix, Fortinet, Ivanti, Palo Alto (September to October 2026): The Edge Keeps Falling

CISA confirmed Citrix NetScaler zero-days being exploited worldwide in late September. In October alone, CISA added exploited flaws in Fortinet FortiMail, Ivanti Connect Secure, Palo Alto PAN-OS and Cisco's email gateway to its known-exploited list. Palo Alto also confirmed its firewalls are affected by PHP2Shell, with no fix at the time of writing.

The lesson: VPNs, firewalls and email gateways face the internet by design. Assume one of them will be broken someday, and make sure getting past it does not mean getting everything. CISA's own advice for Citrix: forward logs off the device, because local logs "may rotate quickly."

How One Hole Becomes a Full Breach

The first break-in is rarely the damage. The damage comes from what the attacker can reach next.

Most small offices run a flat network: the website server, the old file server, staff laptops, the security cameras, the printer and the accounting PC all sit on one network and can all talk to each other. Here is how an attack runs on a network like that, using the examples above:

1. Get in. The attacker uses PHP2Shell on an old website server, or a stolen token from an infected npm package, or a hole in the VPN.
2. Look around. From inside, they scan the network. On a flat network, every device answers.
3. Collect passwords. They pull saved passwords, SSH keys and cloud tokens from the first machine, exactly what the npm worms and the BeyondTrust attackers did.
4. Move sideways. They log into the next system with those passwords. Old systems with known holes, such as a Windows 7 PC or an unpatched camera recorder, fall without a password at all.
5. Take control. They reach the domain controller, the Microsoft 365 admin account or the backup server.
6. Cash out. They copy client data, then encrypt everything, including the backups they can reach, and demand a ransom.

Security people call steps 2 to 5 lateral movement. A flat network makes it easy. Segmentation is what stops it: if the website server cannot talk to the file server, a break-in on the website stays on the website.

Why Unpatched and Unwatched Systems Multiply the Damage

An unpatched system is an open door. An unwatched one means nobody notices someone walked through it.

Unpatched systems stay vulnerable forever. A zero-day is only a zero-day for a short time. After the fix ships, every system that skips it is running a publicly known hole with public attack code. The old PHP 5 site, the Windows server past end of support, the NAS box with firmware from 2019: none of these will ever get a fix. Attackers keep scanning for them for years.

Unmonitored systems give attackers time. The BeyondTrust attackers were inside for 47 days. Ransomware groups often wait weeks before encrypting, so they can find and destroy the backups first. If nobody is watching logins, new admin accounts, or a server suddenly talking to a strange address at 3 a.m., the attacker gets all that time for free.

Logs on the box don't count. Attackers delete logs, as the BeyondTrust group did. Devices also overwrite their own logs quickly. Logs need to be copied somewhere the attacker cannot reach, as soon as they are written.

Put the three together and you get the worst case: an old system nobody updates, on a flat network, that nobody watches. That is how a single website flaw becomes a company-wide ransomware event.

The Fix: Patch, Isolate, Watch

The rule is simple: if it is not getting updates, it does not get the internet, and it does not share a network with anything important.

1. Patch everything that can be patched, fast

Turn on automatic updates where you can. For internet-facing systems (websites, VPNs, firewalls, email gateways), critical fixes go in within days, not at the next quarterly maintenance window. PHP2Shell went from leak to emergency patch in a day.

2. Disconnect what can't be patched

Some systems have to stay old: a machine running software the vendor abandoned, a lab instrument, a legacy accounting package. Those systems lose internet access completely. No browsing, no email, no inbound connections. If they need to share files, they share with one specific system through one specific port.

3. Segment the network

Split it into zones that cannot freely talk to each other:

• Public servers (website, anything reachable from outside) in their own zone, with no path into the office.
• Staff devices in their own zone.
• Servers and backups in their own zone, reachable only on the ports staff actually need.
• Cameras, printers, phones and smart devices in their own zone, with no access to anything else.
• Legacy systems in a locked-down zone with no internet.
• Guest Wi-Fi completely separate.

Even basic business firewalls and switches can do this with VLANs and firewall rules between them.

4. Remove standing access

Remote access tools, build servers and admin accounts should not have a permanent open path to everything. Use multi-factor sign-in, give each account only what it needs, and keep passwords and keys out of files on laptops.

5. Watch for the attacker, not just the hole

Send logs off each device to a central place the attacker can't erase. Run endpoint detection (EDR) on every computer and server. Set alerts for new admin accounts, logins from new countries, and servers making connections they never made before.

6. Keep one backup the attacker can't touch

At least one copy should be offline or immutable (cannot be changed or deleted, even by an admin). Test restoring from it.

Checklist to Hand to Your IT Team

• List every device and server on the network, with its operating system and software versions.
• Mark each one: still getting security updates, or not.
• Check every website and server for PHP versions older than 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, and update.
• Take anything that can't be updated off the internet, or put a web application firewall in front of it until it can be replaced.
• Split the network into zones: public, staff, servers, devices, legacy, guest.
• Block traffic between zones except what is needed.
• Patch VPNs, firewalls and remote-access tools within days of a critical fix.
• Rotate passwords, SSH keys and tokens on any system that installed a compromised npm package.
• Turn on multi-factor sign-in for every admin and remote access account.
• Send logs to a central system and set alerts for unusual logins and new admin accounts.
• Run EDR on every computer and server.
• Keep an offline or immutable backup, and test a restore.