You Will Get Hacked by a Zero-Day. Should You Be Worried?

Most zero-days are never reported. The ones you read about in advisories are the ones a researcher chose to disclose. The rest are kept quiet and used for espionage, ransomware or plain financial gain.

Freely downloadable open-weight models such as GLM-5.3, Qwen3.8 and DeepSeek V4.1 have made these bugs far easier to find, and their smaller variants run on an ordinary workstation. “Abliterated” versions also exist, which strip out the safety controls that frontier models and the original releases ship with, so researchers, and attackers, can hunt for security bugs without the model refusing to help.

Researchers and attackers pair these models with open-source agentic frameworks that orchestrate the testing and vulnerability identification. PentAGI and HexStrike AI drive standard penetration-testing tools on the model’s behalf, and REA (Reverse Engineer Anything) lets an agent take apart compiled binaries and apps without source code.

Zero-Days and What We Can Do

PHP2Shell: Where There Was One, There Were Many

Calif, OpenAI and Wiz found two critical flaws that had sat in PHP for more than a decade, using public models, and worked with the PHP maintainers on security patches ahead of public disclosure. Cloudflare protected a large portion of the internet by deploying web application firewall (WAF) rules hours before the details went public on 21 October (more details in our article here).

However, within hours, the rest of the world had turned its LLMs on PHP. Before release day was out, a public repository had appeared that claimed remote code execution against PHP 8.5.12, the recently patched version. While it needs a specific configuration, it shows the pace at which vulnerabilities can now be found. System administrators, defenders and businesses can’t keep up, and this week governments and large organisations fell back on taking infrastructure offline as a temporary mitigation.

Have We Been Here Before?

To many security people this feels like the first zero-day wave, but it isn’t. In 1990, Barton Miller’s group at the University of Wisconsin fed random input to standard Unix utilities and crashed roughly a quarter of them. As fuzzing matured, it uncovered more than 13,000 vulnerabilities and 50,000 bugs in open-source projects through Google’s OSS-Fuzz alone, and vendors were swamped. But the industry adapted: Microsoft made fuzzing a requirement in its Security Development Lifecycle for code that parses untrusted files, catching issues before they shipped.

Each time the arc was the same: a new technique, a flood of bugs in software everyone thought was solid, years of patching, then a new baseline once defenders used the tools as routinely as attackers. We’re early in the AI version, where new techniques and approaches are still being found. This week’s theme has been use-after-free bugs, and the approach Calif and others used to find them is likely to trend. Expect more bugs like PHP2Shell this week, and a wave that runs for the next few years.

Detection as a Foundation

Zero-days will keep being found: remote code execution, XML external entity (XXE) injection, server-side request forgery (SSRF) and more. Servers will get hacked, but what an attacker does next doesn’t change. That has always been true, and it’s why large organisations such as Google, Amazon and Microsoft are often the first to spot a zero-day being exploited. They have invested in detection infrastructure that baselines normal activity and flags anomalies and malicious behaviour: unexpected commands, unusual files and connections to attacker infrastructure.

There are various detection approaches, including static rules, anomaly detection, threat intelligence-enriched detection and threat hunting. Unfortunately, humans can’t keep up with this work either. Defenders need to employ AI to keep pace, not only with detection but also with robust digital forensics and incident response (DFIR). SensorZero learns your environment, baselines it and detects anomalies across your infrastructure. It uses AI to triage and escalate alerts, and correlates and investigates on an analyst’s behalf so the work scales. SensorZero is also the only product that continuously collects the forensic artefacts that are vital to response. If you’d prefer to host it yourself, open-source alternatives such as Wazuh and the Elastic Stack (ELK) are a good starting point.

Deception’s Role in the New World

The effectiveness of deception has long been debated. In 2026 and beyond we must move towards detection, and detection through deception is a highly effective way to identify zero-day intrusions. Eviant recommends two forms:

1. Canary tokens. These can be access keys, passwords, documents or really anything that should never be touched. Your staff know they’re decoys, but attackers don’t. When attackers get into the network and access them, they trigger a detection. Free tools such as Canarytokens make it easy to start.
2. Honeypots. These are best left to your security vendors and trusted partners to host. They expose deliberately vulnerable applications to the internet and capture the payloads attackers send while scanning for infrastructure to compromise. Researchers then analyse those payloads to work out what attackers are doing and whether any services are affected, often before a vulnerability is public.

Bringing It All Together

The industry is not prepared for the wave of vulnerabilities to come, particularly the ones that are found and never reported. AI has made zero-days easy to find, and we’re not going back. PHP2Shell showed how quickly one bug becomes many, but we need to be realistic: many of the bugs found will never be reported, only used in the wild.

We can’t control how quickly attackers find bugs and keep them quiet. But we can be smarter: deploy detection, plant decoys and catch attackers before they impact your organisation.

Stay safe.

---

Appendix

Calif’s PHP2Shell write-up explains why a first bug is rarely the only one. After their initial finding, they had an LLM generalise it into a pattern to search for across the codebase. We include it here because it shows how a single bug can quickly become a repeatable method for finding others, which is the shift this article describes. Calif flags:

publish or destroy state
        → perform fallible work
        → initialize, commit or restore

nonlocal fatal during fallible work
        → commit/rollback skipped
        → surviving consumer trusts false state

This article contains no exploit code.