AI lowers exploit barriers, but patchability remains the real risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Censys's research: AI is making exploit development cheaper, but the bigger operational risk remains whether exposed software can be identified, maintained, and updated fast enough.

Why it matters: This matters because security teams do not fail only at detection, they also fail at asset visibility, ownership, and remediation speed, including for systems that sit behind hosting providers or inherited platforms.

Context

AI-assisted exploit development changes the economics of vulnerability research, but it does not erase the older problem of exposed systems that remain unpatched for months or years. The real governance gap is not whether a flaw exists, but whether defenders can identify every exposed asset, understand who owns it, and make a safe change quickly enough.

Core web software and internet-facing enterprise platforms often linger in mixed states of support, ownership, and maintenance. That creates a patchability problem as much as a vulnerability problem, especially where cloud hosting, managed services, or embedded dependencies sit between the security team and the system that actually needs fixing. In identity-heavy environments, the same pattern applies to service accounts and other non-human identities that outlive the controls around them.

The pattern is familiar across the internet: the oldest software tends to move least, while newer or better-supported versions respond faster when pressure rises. That split is typical, not exceptional, and it is one reason remediation maturity matters as much as disclosure speed.

Key questions

Q: What should security teams do first when prioritising exploitable vulnerabilities over raw CVE counts?

A: Start with exposure validation, not enumeration. CVE counts alone do not tell you whether a flaw is reachable, exploitable in your environment, or likely to be used by attackers. Prioritise assets that are internet-facing, business critical, or linked to known exploit activity, then verify whether the issue can actually be abused before spending remediation effort.

Q: Why does patchability matter as much as vulnerability severity?

A: Patchability matters because exploitability depends on both the flaw and the ability to remove it. A severe weakness in code that can be patched quickly often creates less lasting risk than a lower-severity issue in firmware, appliances or embedded systems that stay exposed for months. Teams should rank vulnerabilities by severity, reachability, compensating controls and patch deployment speed.

Q: How should teams handle legacy software that cannot be updated quickly?

A: Teams should treat legacy software that cannot be updated quickly as a managed exception and contain it with network segmentation, application allowlisting, virtual patching and restricted privileged access. They should also document the owner, business dependency and compensating controls, because unsupported or delayed patching turns the system into a long-lived exposure rather than a short-term risk.

Q: What is the best way to maintain an inventory of internet-facing systems?

A: The best way is to maintain a continuously updated asset record that ties each exposed system to an owner, location, internet-facing service and business purpose. Teams usually build it from discovery scans, cloud inventory, DNS and certificate data, then reconcile it against change records so new public systems are found, classified and tracked before they drift out of control.

Technical breakdown

Why AI changes exploit economics, not just exploit volume

AI reduces the time and expertise required to convert a disclosed flaw into a usable exploit. That shifts the attacker’s constraint from specialist knowledge toward iteration speed and automation, which means obscure bugs can become operational far more quickly once public details exist. The practical effect is not that every vulnerability becomes critical, but that defenders have less time to separate theoretical exposure from active risk. The security problem therefore moves from counting CVEs to understanding which ones are reachable, weaponisable, and tied to assets that cannot tolerate delay. See the Initial Access Techniques Guide.

Practical implication: Prioritise exploitability, exposure, and business reachability over raw vulnerability counts.

Patchability depends on ownership, dependencies, and maintenance paths

A patch is only useful if the organisation can safely apply it. In many environments the real obstacle is not the vendor fix itself, but the dependency chain around it: managed hosting, downstream distributors, application compatibility, or an internal owner who no longer exists. That makes patching a governance problem, not just a technical one. Systems that are years behind current versions often need migration planning, not routine patching, and software embedded in operational environments may have no easy remediation path at all.

Practical implication: Map each internet-facing system to an owner, a maintenance path, and a tested upgrade route before the next emergency hits.

Old software persists because update processes are uneven

The long tail of vulnerability exposure is usually explained by maintenance asymmetry. Products with active communities, repeatable release cycles, and strong automation tend to move steadily, while niche or legacy platforms often stay frozen until a crisis forces action. That is why emergency patching spikes can coexist with large pockets of unmodified infrastructure. From a control perspective, this is less a failure of awareness than a failure of sustained lifecycle discipline, where upgrade capability varies more than the severity of the vulnerability itself.

Practical implication: Treat lifecycle maintainability as a control requirement for every critical platform, not an optional operations task.

Threat narrative

Attacker objective: The attacker aims to convert a reachable weakness into sustained access or service compromise before defenders can patch or isolate the affected system.

1. Entry begins when an attacker leverages a publicly exposed weakness or reused credential to reach an internet-facing service without needing a bespoke exploit.
2. Escalation follows when tooling, automation, or AI assistance turns a previously difficult flaw into a working proof of concept that can be reused at scale.
3. Impact occurs when unpatched systems remain reachable long enough for code execution, persistence, or broader compromise before defenders can coordinate remediation.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI is compressing the exploitation timeline, but it is not eliminating the defender’s real problem. The meaningful change is that flaws can move from disclosure to usable exploit much faster, especially when attackers can automate iteration. That makes exposure windows shorter and prioritisation harder, but it does not change the underlying governance burden: defenders still need asset visibility, ownership, and a way to change systems safely before exploitation starts.

Patchability is now a first-class security property. A system that cannot be updated quickly is already carrying latent risk, regardless of whether it has a known CVE today. That is especially true for stolen credential breaches and internet-facing platforms where third-party hosting, dependency chains, or compatibility constraints slow remediation. Practitioners should treat maintainability as part of security design, not an afterthought that only matters during a crisis.

The old software problem is a lifecycle failure, not a headline problem. The oldest releases tend to lag because upgrade work is expensive, disruptive, or simply nobody’s responsibility. That creates a persistent exposure class where disclosure events expose the gap, but do not create it. The lesson for security leaders is that vulnerability response must be designed into the operating model long before the next urgent advisory arrives.

Support ecosystems matter as much as patches. Software with reliable migration paths, documentation, and downstream packaging is easier to keep safe than software that requires bespoke effort every time it changes. That means the market should stop treating safe upgrade paths as merely a customer experience issue. In practice, security teams should demand evidence that critical platforms can be patched, migrated, or isolated without breaking the business.

In internet exposure terms, visibility is the control before the control. The difference between a manageable vulnerability and a business-wide remediation crisis is often whether teams know what is exposed in the first place. Discovery, ownership, and dependency mapping are therefore not adjacent tasks. They are the foundation that determines whether patching is even possible when exploitation pressure rises.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Initial Access Techniques Guide

What this signals

Patchability debt: organisations accumulate risk when software can be discovered faster than it can be safely changed. That debt is operational as much as technical, because remediation timelines depend on ownership, dependency chains, and upgrade pathways that are often invisible until a crisis hits.

The next phase of vulnerability management will reward teams that can prove maintainability, not just exposure awareness. That means the programme has to know which assets can be fixed in hours, which require planned migration, and which need isolation because no safe update path exists.

For practitioners

• Build a complete exposure inventory Track every internet-facing system, its version, its owner, and whether it can be patched, migrated, or isolated on demand.
• Create tested remediation paths for legacy platforms Document compatibility testing, rollback options, and hosting-provider dependencies for systems that cannot absorb emergency change safely.
• Prioritise exploitable weaknesses over raw CVE counts Rank vulnerabilities by reachable attack path, active exploitation evidence, and the value of the exposed asset rather than by volume alone.
• Treat patchability as a design requirement Require vendors and platform owners to show how updates can be applied without long outages, major rewrites, or unsupported downtime.
• Plan for systems that cannot be patched quickly When remediation is slow or impossible, isolate the service, reduce exposure, and assign an explicit compensating control owner.

Key takeaways

• AI-assisted exploit development matters because it shortens the time between disclosure and practical abuse, not because it makes every vulnerability catastrophic.
• The evidence from long-lived internet software shows that the oldest versions move least, so exposure persists long after headlines fade.
• Security teams need remediation paths, ownership clarity, and maintainability standards before the next emergency, or patching will remain too slow to matter.

Related NHI Mgmt Group resources: Initial Access Techniques Guide · T1190 Exploit Public-Facing Application Defensive Guide · Stolen credential breaches

Key terms

• Exploitability: Exploitability is the likelihood that a weakness can be turned into actual harm. In cybersecurity, it measures how readily an attacker can abuse a vulnerability, misconfiguration, exposed secret, or weak control, considering access required, available tools, and the value of the target asset or identity.
• Patchability gap: The point at which a system can no longer be safely maintained through normal vendor patches. In practice, the gap turns vulnerability management into a governance problem because exposure can be identified but not eliminated through standard maintenance.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.
• Initial Access: Initial access is the first successful entry point an attacker gains into a target environment. In application security, that foothold often comes from an unpatched flaw rather than a stolen password, which is why exploitability and exposure time matter as much as control coverage.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security operations and remediation work their programmes depend on.