A zero-day is a software flaw that attackers are already using before the people who make the software have released a fix. The name comes from the defender's position: when the attack starts, the vendor has had zero days to protect its customers. August 2026 was a clear reminder of how these attacks play out, with a Windows flaw used by a state-backed group and a print-management server hijacked by unauthenticated attackers within the same month.
This article explains what happened, who was affected, and the practical steps that reduce your exposure to the next zero-day, which is the one nobody can patch in advance.
What happened in August
Windows: CVE-2026-68820, used by the Lazarus group
On 11 August, Microsoft's monthly security release fixed around 400 vulnerabilities. One of them, CVE-2026-68820, was already being exploited. It is a use-after-free flaw in afd.sys, the Windows driver that sits behind the WinSock networking stack. An attacker who already has a foothold on a machine, even with a low-privilege account, can use it to gain full SYSTEM control.
Researchers at Check Point, who reported the flaw, linked its use to Lazarus, the North Korean state-sponsored group. Lazarus used it to install a new version of FudModule, its kernel-level rootkit, which is designed to switch off security tools from deep inside the operating system. The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalogue the same day and gave US federal agencies until 25 August to patch.
The same release also fixed two other flaws whose details had been published before a fix existed: CVE-2026-62832 in the Windows User Profile Service, which can let a local user gain administrator rights, and CVE-2026-72971 in a Windows container filter driver. Neither was confirmed as exploited, but public details shorten the time before attackers start using them.
PaperCut: unauthenticated takeover of print servers
On 27 August, PaperCut warned that attackers were exploiting a previously unknown flaw in PaperCut NG and MF, print-management software used widely in schools, universities, councils and businesses. The weakness, later tracked as CVE-2026-81578 and CVE-2026-82078, let an attacker with no login change the server's configuration and then run their own code on it.
Security firm Huntress confirmed exploitation in two customer environments. In one, the whole intrusion lasted less than two minutes: the attacker ran discovery commands to profile the server, dropped a small Java payload, collected what it found and then deleted its own files and the application log to cover its tracks. Huntress also noted that about 47% of the roughly 2,500 PaperCut installations it monitors were running version 23 or older, for which no fix was initially available.
PaperCut released emergency builds for versions 25 and 26 straight away, and extended fixes to version 24 the following day.
Why zero-days matter to every organisation
It is tempting to think zero-days only concern governments and large enterprises. August showed otherwise:
- The targets were everyday software. Windows and a print server are found in almost every office. Attackers go where the installed base is.
- Exposed management interfaces are the front door. The PaperCut attacks only worked against servers whose web interface could be reached from the internet. Many organisations do not realise how many admin panels they expose.
- Privilege escalation turns a small breach into a big one. The Windows flaw needs an existing foothold, which usually comes from a phishing email or a stolen password. Once inside, the zero-day turns a limited account into total control.
- Attackers clean up after themselves. Deleted logs mean that, without independent monitoring, a victim may never know what was taken.
How to protect yourself before the next one
By definition you cannot patch a zero-day before the fix exists. What you can do is shrink the number of ways in, make a successful attack less damaging, and shorten the time between a fix appearing and it being installed.
1. Patch fast once a fix appears
Most real-world damage happens in the days and weeks after a fix is released, as attackers reverse-engineer the patch. Turn on automatic updates for Windows, browsers and phones. For servers and business applications, set a target: critical fixes for internet-facing systems within 48 hours, everything else within 14 days. Subscribe to your key vendors' security advisories and to the CISA Known Exploited Vulnerabilities list.
2. Take admin interfaces off the internet
Print servers, remote-access tools, firewalls, routers, CCTV and website control panels should not be reachable by anyone on the internet. Put them behind a VPN, or restrict them to known IP addresses. This one step would have blocked the PaperCut attacks entirely.
3. Know what you run
Keep an up-to-date list of your systems and software versions, including the ones nobody thinks about, such as print management, building systems and old servers. You cannot patch what you do not know you have.
4. Remove local admin rights
Day-to-day accounts should not be administrators. Combined with multi-factor authentication on email and remote access, this makes the initial foothold that privilege-escalation zero-days depend on much harder to get.
5. Detect, don't just prevent
Use endpoint detection and response (EDR) on laptops and servers, and send logs to a separate system the attacker cannot easily delete. Watch for the warning signs seen in August: server software launching command shells, unexpected files appearing in application folders, and logs that suddenly go missing.
6. Plan for the bad day
Keep offline or immutable backups and test that you can restore them. Write down who you will call, and how you will isolate systems, before you need to. A short, practised incident plan is worth more than an untested long one.
If you think you were affected
If you run PaperCut NG or MF and its web interface was reachable from the internet in August, do not just upgrade and move on. Preserve the server's logs and configuration first, then look for unexpected .class files in the server's lib folder and for missing or truncated log files. Upgrading or restarting can destroy evidence you will need to understand what happened.
For Windows, confirm that the August updates are installed across every machine, not just most of them. One unpatched server is enough.
Our incident response team can help you check for signs of compromise, preserve evidence properly and close the gaps. Contact us, or call +44 7520 644325 at any time.