Select Language

Contact

Company

Service

Product

Media Center

Contact

Company

Service

Product

Media Center

Select Language

Contact

Company

Service

Product

Media Center

오늘 닫기

Go to Top

In an hour of patching, the era of attack codes 'Sometimes check' is no longer security

Security Insights

In an hour of patching, the era of attack codes 'Sometimes check' is no longer security

Kim in-soon

Jun 19, 2026

Content

Microsoft released around 200 vulnerabilities at once in its regular security update on June 9, 2026. This was the largest monthly security update since the introduction of Patch Tuesday in 2003.

Now, enterprise security teams are faced with a list of around 200 vulnerabilities at a time, rather than dozens a month, and must decide "what to block first."

But the bigger issue is not the number of patches. The real problem is that the time it takes for exploit proof-of-concept code to be created after a patch is released has shrunk dramatically.

According to Anthropic's report released on June 8, 2026, 'The Impact of LLMs on N-day Exploits,' the Mithos model generated working exploit code less than an hour after a Firefox security patch was released.

Looking at the timeline makes the change clearer. In the past, it took significant time to exploit a vulnerability after disclosure. Companies had time to review, test, and deploy patches. Recent security reports shows this window is rapidly shrinking.

Some security communities estimate the time from disclosure to exploit has shrunk from hundreds of days to mere hours. Attackers no longer wait. Once a patch is released, they reverse-engineer it to find the fixed flaw. And AI is making that process even faster.

Unrealistic to fix all 200

That is where the issue begins. Once 200 vulnerabilities are exposed at once, no firm can finish patching them all in a day. It is not because the security team is lazy. It is practically impossible.

To apply a patch, you must first check if your system has that vulnerability. You need to see if you use the software, what version it is, if it is exposed externally, and if it is linked to internal systems. For active services, you must check for downtime risks. Systems that cannot stop easily—like manufacturing, finance, government, or healthcare—find patching even harder.

Thus, security teams face the same inquiry.

"When do we fix all 200?"

Treating all flaws with equal weight soon paralyzes the team. The real question to ask is different.

"Which of these could actually lead to a breach today?"

This is the inquiry to answer. High-score flaws are not always the most urgent. Conversely, a lower-score flaw on a web-exposed server with public exploit code, linked to customer databases, can be far more dangerous.

For instance, Flaw A has a high risk score but sits in a private net with no outside access and extra MFA. Flaw B has a lower score but sits on a public web server, has open exploit code, and leads to internal database assets. Here, you must fix B first, not A.

Security should not just stop at asking "Is there a flaw?" We must ask, "Can that flaw lead to an actual attack in our environment?"

Prioritizing in the Era of Patch Explosions

Continuous Threat Exposure Management (CTEM) is not a 'one-time check,' but a 'continuous cycle of measuring and reducing security risks.'

Of course, CTEM is not a tool that patches for you. Nor is it a magic solution that automatically fixes 200 vulnerabilities. Instead, CTEM helps security teams determine "what to fix first."

The core of CTEM consists of five stages. First, define what to protect, known as Scoping. Next, find exposed assets and weaknesses within that scope, which is Discovery. Third, prioritize the discovered risks most likely to be attacked, called Prioritization. Fourth, verify if those risks are indeed exploitable through Validation. Finally, turn validation results into action through Mobilization.

Through this process, a list of 200 vulnerabilities becomes an actionable plan rather than a simple Excel file. It separates "vulnerabilities to fix today," "vulnerabilities to resolve this week," "vulnerabilities hard to patch but needing temporary defense," and "vulnerabilities of low risk in the current environment that can be deprioritized."

If security teams cannot fix every vulnerability at the same speed, they must first block paths attackers are likely to target. CTEM is the exact method for finding those key paths.

An inspect-once-or-twice-a-year pace cannot keep up

Faced with this speed, traditional security audits reveal historical design flaws. Running scheduled reviews like annual penetration tests or quarterly scans leaves vast gaps between checks. When exploits emerge hours after patch releases, systems checked semi-annually remain exposed and undefended nearly the entire time.

In the past, asking "Did we do our regular scan?" was enough. Today, the question must change. We must ask: "Are we verifying right now that our systems cannot be breached by an active attack?"

A pivotal phase in CTEM is validation. Scans merely highlight potential flaws; patch lists show what needs updating. But that is not enough. You must actively test if an attacker can exploit those flaws to get in, if security controls block them, or if chained flaws create an active intrusion path.

This is exactly what CTEM highlights. The goal is not patching every loophole at the same speed. It is finding, validating, and mitigating high-risk threats first. If you cannot fix all doors at once, lock the ones that attackers can breach tonight.

If AI white hackers verify daily, everywhere

This is where the frequency and scope of validation become crucial. Manual penetration testing by humans is precise, but has clear limits in the scope and frequency it can cover at once. Corporate IT environments change constantly. New servers are spun up, cloud configurations shift, APIs are added, and external partner systems are linked. If security validation remains stuck in the state it was six months ago, it cannot address today's risks.

AI-driven white hacker operations supplement this limitation. Rather than inspecting a fixed portion of the system a few times a year, validation can be run again whenever changes occur, new assets are added, or new vulnerabilities are disclosed. The key is not stopping at a single check. The gap in time before the next check must be minimized.

If attackers use AI to weaponize patches rapidly, defenders must also use AI to validate their systems faster. If an attacker can create exploit code within an hour, defenders must confirm within that same hour, "Can this vulnerability actually be exploited in our system?" While the speed asymmetry won't vanish completely, narrowing that gap becomes the new baseline of defense.

Validation is crucial even when patches cannot be applied immediately. If an actual exploit path is confirmed, security teams can apply temporary defenses first. This includes blocking access, modifying firewall policies, applying WAF rules, restricting account privileges, disabling vulnerable services, adding detection rules, or segmenting the network. A perfect patch is best, but severing the attack path first is a critical defense when patching is delayed.

Ultimately, CTEM and AI-powered white hacker validation prevent security teams from feeling overwhelmed by 200 vulnerabilities. It shifts the status from "We don't know what to fix" to "This is the highest priority risk we must reduce today."

In an environment where 200 patches flood in at once and which one will be attacked first is decided in hours rather than days, "continuous validation" holds far greater value than "occasional checks."

In an era where AI compresses attack speeds into hours, defense must also transition from a fixed schedule to a continuous loop. Defining what to protect, finding exposure, prioritizing, validating actual exploitability, and translating those results into action must become an ongoing cycle rather than a one-time event.

References

Anthropic, “Measuring LLMs’ impact on N-day exploits”, 2026.06.08
Zero Day Initiative, “The June 2026 Security Update Review”, 2026.06.09
Microsoft Windows Blog, “Reflecting on 20 years of Windows Patch Tuesday”, 2023.11.09
CTEM.org, “Continuous Threat Exposure Management: A Definitive Guide”
Team Cymru, “What is Continuous Threat Exposure Management?”
Anthropic, “Project Glasswing: Securing critical software for the AI era”, 2026.04.07
Anthropic, “Project Glasswing: An initial update”, 2026.05.22
Anthropic, “Making frontier cybersecurity capabilities available to defenders”, 2026.02.20

Kim in-soon

Start-up College Adjunct Professor at Gachon University

Former desk member of the Electronic Newspaper ICT Convergence Department, active as a cyber security journalist and communication expert for 20 years.