{"id":3158,"date":"2026-06-09T22:38:05","date_gmt":"2026-06-09T22:38:05","guid":{"rendered":"https:\/\/www.upgreat.pl\/?p=3158"},"modified":"2026-06-09T22:59:50","modified_gmt":"2026-06-09T22:59:50","slug":"od-teraz-podatnosc-n-day-staje-sie-podatnoscia-n-hour","status":"publish","type":"post","link":"https:\/\/www.upgreat.pl\/en\/blog\/od-teraz-podatnosc-n-day-staje-sie-podatnoscia-n-hour\/","title":{"rendered":"FROM NOW ON, N-DAY VULNERABILITY BECOME N-HOUR VULNERABILITY \u2013 ANTHROPIC REPORT "MEASURING LLMs' IMPACT ON N-DAY EXPLOITS"\u201e"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

From 0-Day to N-Hour: Why Is AI Reducing Response Time and What Does This Mean for Organizational Security?<\/h1>

\u00a0<\/p>

The day before yesterday, on June 8, 2026, Anthropic published a report Measuring LLMs' impact on N-day exploits<\/a>, which analyzed how advanced AI models can accelerate the creation of exploits for N-Day vulnerabilities, i.e. vulnerabilities already known and patched by vendors but still present in outdated systems.<\/p>

The report's most important conclusion is very practical: the time required to develop a working exploit can be reduced from weeks to hours. This means organizations cannot treat the release of a security patch as the beginning of a long and uneventful update process. In many cases, the moment a patch is released can also be the start of a race between administrators and attackers.<\/p>

\u00a0<\/p>
Anthropic Test Area<\/strong><\/td>The result described in the report<\/strong><\/td>Importance for the organization<\/strong><\/td><\/tr>
Firefox \/ SpiderMonkey<\/td>the first working exploit was created in less than 1 hour<\/td>Exploits for known vulnerabilities can appear very quickly after a patch is released<\/td><\/tr>
Firefox \/ SpiderMonkey<\/td>8 different working exploits in about 12 hours<\/td>N-Day vulnerability can become a real threat on the same day<\/td><\/tr>
Windows kernel<\/td>18 proof-of-concepts for 21 vulnerabilities in 6 hours<\/td>even closed, harder-to-analyze software no longer gives defenders such a big advantage<\/td><\/tr>
Windows kernel<\/td>8 complete privilege escalation chains to SYSTEM<\/td>AI can accelerate not only error detection, but also the construction of a complete attack scenario.<\/td><\/tr><\/tbody><\/table>

\u00a0<\/p>

This report was the direct inspiration for this post. We want to clarify the concepts of 0-Day, N-Day, and N-Hour and demonstrate why regular vulnerability scanning, risk prioritization, and rapid mitigation are becoming fundamental components of an organization's cyber resilience.<\/p>

\u00a0<\/p>

0-Day, N-Day, N-Hour \u2013 what do these terms mean?<\/h1>

\u00a0<\/strong><\/p>

0-Day Vulnerability<\/strong> This is a vulnerability that the software vendor isn't yet aware of, or for which there isn't a publicly available patch. Attackers have an advantage because administrators and security teams don't have a ready-made patch or full information on how to effectively fix the problem.<\/p>

N-Day Vulnerability<\/strong> This is a publicly known vulnerability\u2014usually described in a security bulletin, CVE, or vendor advisory. A patch exists, but not all systems have been updated yet. This period between the release of a patch and its implementation in an organization is often called the "patch gap.".<\/p>

N-Hour<\/strong> This concept accurately captures the new scale of risk. As AI models can analyze patches, compare code versions or binaries, and help create proofs of concept and exploits faster and faster, the real security window may no longer be measured in days. Increasingly, we need to think in hours.<\/p>

\u00a0<\/p>

Why are N-Day vulnerabilities so dangerous?<\/h1>

\u00a0<\/p>

In the case of an N-Day vulnerability, an attacker doesn't have to start from scratch. The security patch itself can be a clue. They can compare the vulnerable version with the patched version, verify what exactly the vendor changed, and then reproduce the bug logic.<\/p>

This process is often called "patch diffing." Until recently, it required significant experience, time, and specialized reverse engineering skills. This left defenders with a margin of error: even if a patch was released, developing a working exploit wasn't always quick.<\/p>

According to Anthropic, this margin is rapidly shrinking.<\/p>

\u00a0<\/p>

What did the Anthropic report show?<\/h1>

\u00a0<\/p>

Anthropic analyzed the impact of large language models on developing exploits for the N-Day vulnerability. Tests included Firefox\/SpiderMonkey vulnerabilities and Windows kernel vulnerabilities.<\/p>

In Firefox, the models received public information from the patch, a test environment, and a vulnerable and patched version. They didn't receive hidden information from internal bug reports. Despite this, Claude Mythos Preview was able to generate multiple working proofs of concept and then progress from failure to a working exploit that allowed code execution.<\/p>

In the case of Windows, the task was more challenging, as the models operated on binaries, decompilations, and public information from security bulletins. Here, too, Anthropic demonstrated that the models could significantly accelerate the process from patch analysis to a working privilege escalation chain.<\/p>

The report's key takeaway isn't "AI uncovers all vulnerabilities." It's more like: AI lowers cost and shortens time to weaponize known vulnerabilities<\/strong>.<\/p>

This is a very important difference.<\/p>

\u00a0<\/p>

What does this mean for companies and public institutions?<\/h1>

\u00a0<\/p>

For administrators, IT departments and those responsible for cybersecurity, this means a change in approach to vulnerability management.<\/p>

In practice, it's no longer sufficient to assume that "we'll update systems at the next maintenance window." If the patch addresses a vulnerability that could be exploited in a real attack, this delay could mean that the organization remains vulnerable even when an exploit is already available or can be quickly developed.<\/p>

Environments where updates are difficult, postponed, or require lengthy reconciliations are particularly vulnerable:<\/p>