A zero-day attack targets a vulnerability that the vendor does not yet know about or for which no patch is available. Why revisit it now?
According to Google's Threat Intelligence Group (GTIG), newly disclosed vulnerabilities per month rose from 5,045 in January to 10,740 in August. From January through August this year, 141 vulnerabilities were exploited in actual attacks, already exceeding last year's full-year total of 127 (Boan News, October 3).
The bigger change is speed. AI turns patches into attack maps (KCBCA Signals p.26).
That means managing the time after a patch becomes available as well as zero-day attacks. Reduce exposure and, after patching, verify whether the root cause has also been fixed (p.27).
How zero-day and n-day vulnerabilities differ
A zero-day (0-day) vulnerability is exploited before the vendor knows about it; an n-day vulnerability has already been disclosed with a patch (Boan News, October 3).
| Category | Zero-day | N-day |
|---|---|---|
| Status | Unknown to the vendor, or no patch available | Disclosed with a patch |
| Clues for attackers | An unknown flaw | Patches, advisories and proof-of-concept code |
| Response | Reduce exposure, apply mitigations and check for signs of compromise | Update quickly and verify the fix |
GTIG attributed this year's rise in exploitation to the rapid weaponization of high-risk vulnerabilities rather than a flood of new zero-days. Its assessment is that attackers can use AI tools to automatically analyze version differences, patches, advisories and proof-of-concept code to weaponize n-days, which is easier and more efficient than finding new zero-days (Boan News, October 3).
AI compresses the timeline: 10 minutes and one hour
In Anthropic's chart of Firefox exploit reproduction cited by KCBCA Signals, a working proof of concept emerged in under 10 minutes and a fully working exploit in under one hour (p.26). With agents watching changes and generating attack code, defenders cannot expect days to respond (p.26).
In the paper's hypothetical example, a mainnet contract loses its balance 20 minutes after a patch is posted to a public testnet (p.26). The scenario is discussed in the October 15 article on smart contract hacking.
In a BeyondTrust vulnerability case cited by GTIG, one attack group exploited the flaw four days after disclosure, and five more groups joined within seven days (Boan News, October 3).
A recent case: a zero-day attack on email security equipment
On October 1, Fortinet warned that a vulnerability in the management interface of its FortiMail email security equipment (CVSS 9.8, critical) was being exploited in zero-day attacks. Some versions had no security update at the time, so it advised disabling the relevant feature or blocking internet access to the management interface as interim measures.
Indicators of compromise were also published, and US CISA added the flaw to its Known Exploited Vulnerabilities catalog (BleepingComputer, October 1). Check the vendor advisory (FG-IR-26-175) for affected versions.
GTIG's analysis also found that 14% of vulnerabilities exploited from January through August this year affected network perimeter and security equipment. US CISA said newly disclosed Common Vulnerabilities and Exposures (CVEs) this year had exceeded 67,000 and projected a year-end total of 96,000 (Boan News, October 3).
The overseas exchange Bitget also said a zero-day in a third-party security product was used in the theft of $387.5 million (The Hacker News, October 1). The incident is covered further in the October 22 article on cryptoasset hacking.
Early disclosure and incomplete fixes are separate risks
The paper calls for treating two risks separately. One is 'early disclosure', which reveals a fix too soon.
The other is an 'incomplete fix', which blocks only the original exploit demonstration while leaving the root cause intact. Google Project Zero has documented cases in which a different route bypassed such a patch to reach the same vulnerability (p.26–27).
Private testing alone does not resolve incomplete fixes (p.26, Figure 3).
An organizational checklist
| Item | What to check | Basis |
|---|---|---|
| Asset inventory | Products and versions; internet exposure of management interfaces | General precautions |
| Priorities | Patch or mitigate vulnerabilities already being exploited first | Vendor and CISA warnings |
| Root cause | Was the weakness removed, or was only the original demonstration blocked? | p.27 |
| Private testing | Prepare and rehearse a production-like test path before an emergency | p.27 |
| Release approval | Evidence of approval for this release and who owns the remaining uncertainty | p.27 |
| Actions during validation | What can safely be done before validation is complete | p.27 |
For high-impact changes, the paper proposes including private AI-assisted adversarial testing in the release approval process (p.27).
What can individuals do?
Personal zero-day precautions (general guidance)
- Enable automatic updates on phones, PCs and browsers, and do not postpone notifications
- Replace or remove devices and apps that are no longer supported
- Check firmware for home devices such as routers
- Download updates only through official channels
Frequently asked questions
Q. Can zero-day attacks be prevented?
Without a patch, complete prevention is difficult, but exposure can be reduced. Keep management interfaces off the public internet, promptly apply vendor mitigations and check published indicators of compromise for signs that an attacker has already entered (BleepingComputer, October 1).
Q. Is patching enough?
No. Once a patch is public, the race to exploit the n-day begins. A patch may block only the original demonstration, so check whether it removed the weakness or merely blocked that demonstration (p.27).
Q. Is antivirus software enough?
Antivirus software detects known malware. The vulnerability itself needs to be fixed through updates, making prompt updating a basic habit.
At a glance
- Zero-day attacks target gaps before patches, while n-day attacks target gaps after patches
- The 141 vulnerabilities exploited from January through August already exceeded last year's total (GTIG)
- AI has shortened the time needed to turn patches into attack code (p.26)
- After patching, check whether the root cause was fixed (p.27)
For more on security and trust in the AI era, read the KCBCA Signals report.
Read KCBCA Signals Vol.1 Issue 1 in full
References: KCBCA Signals Vol.1 Issue 1; Anton Kaiser (Vice President of Cyber Assurance, Corpay), p.26–27. Reporting: Boan News, October 3 (GTIG report); BleepingComputer, October 1; The Hacker News, October 1.
