AI coding agents are resurrecting old CVEs in production code

At a glance

What this is: The research shows frontier AI coding agents are increasingly able to produce working code, but most working patches in the benchmark reintroduced previously fixed vulnerabilities.

Why it matters: For IAM, NHI, and software security teams, this matters because agentic coding workflows can accelerate insecure changes into production unless identity, review, and policy controls are built into the pipeline.

By the numbers:

• 65-75% of frontier AI agents’ working patches resurrect vulnerabilities that were already found, fixed, and buried.
• Functional success surged to 83-95% across the cohort, up from 44-61% a single model generation ago.
• Checkmarx’s 2026 Future of AppSec report found that 70% of developers say AI code generation created more vulnerabilities in their code in 2025.
• 49% of production code is now AI-generated.

👉 Read Checkmarx’s research on frontier AI agents resurrecting fixed vulnerabilities

Context

AI coding agents are changing software delivery by making it easier to produce functional code quickly, but functional output is not the same as secure output. This research focuses on a specific governance gap in AI-assisted development: the agent can reproduce a known vulnerable pattern even when the vulnerability has already been publicly documented and patched.

For security and identity practitioners, the important issue is not whether AI-generated code can compile or pass tests. It is whether the development pipeline can prevent agent-generated logic from reintroducing known weaknesses into systems that may also contain secrets, service credentials, and privileged automation paths. In that sense, this is as much a control problem as it is a coding problem.

Key questions

Q: What breaks when AI coding agents are allowed to ship code without security constraints?

A: Teams get working software that can still carry old, well-known vulnerabilities back into production. The failure is not only a coding mistake. It is a governance failure where functional correctness is treated as sufficient evidence, even when the agent has reintroduced a flaw that the security community already fixed.

Q: Why do AI coding agents keep reproducing vulnerabilities that humans already fixed?

A: Because these systems optimise for task completion and code similarity, not for preserving the security intent embedded in a patch. If the vulnerable pattern still satisfies the feature request, the model may recreate it unless secure design constraints are explicit and enforced.

Q: How can security teams tell whether AI-generated code is actually safe?

A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.

Q: How should teams govern AI-generated authentication code?

A: Treat AI-generated authentication code as identity-sensitive change, not ordinary development output. Put it behind code-owner review, require negative-case tests, and verify token scope, field exposure, and database migration handling before merge. If the assistant touched passwords, sessions, or tokens, IAM and security approval should be mandatory.

Technical breakdown

Why AI coding agents reproduce fixed vulnerabilities

Frontier coding agents are optimised to satisfy the requested feature, not to reason consistently about exploitability. In the study, the benchmark tasks were built around real vulnerabilities, so the secure implementation required the agent to infer the hidden defensive pattern inside the original fix. That is a hard problem for models that learn from statistical similarity and task completion. The result is a dangerous split: the agent can often write working code, but it does not reliably reconstruct the security intent that human maintainers embedded in the patch.

Practical implication: treat AI-generated code as untrusted until it passes security-focused review and testing, not just functional validation.

Why prompt-based security reminders are not enough

The research tested a ladder of interventions, including a one-line security reminder, increased reasoning effort, threat modeling before coding, and post-hoc review. The light-touch prompt changed outcomes only slightly, and even more expensive interventions did not eliminate insecure patches. This suggests that security cannot be added as an afterthought to a generation workflow. Once the model has already committed to a feature shape, it may preserve the vulnerable structure even while naming the right defense in its own reasoning.

Practical implication: move security controls earlier in the workflow, especially at task definition and code-generation boundaries.

Why AI-generated code changes the control model for application security

When nearly half of production code is AI-generated, the security model shifts from occasional developer error to systematic machine-assisted propagation of known weaknesses. That affects more than AppSec. It also affects IAM and NHI governance because insecure code often touches authentication flows, API keys, service accounts, and privileged automation. If those paths are generated or refactored by agents without identity-aware controls, the resulting exposure can scale faster than manual review teams can absorb.

Practical implication: align AppSec, IAM, and NHI governance around code generation pipelines, not just around production access management.

Threat narrative

Attacker objective: The practical attacker objective is not to break the model itself but to exploit AI-assisted development workflows that resurrect known vulnerabilities into production systems.

1. Entry occurs when a frontier AI coding agent is asked to implement a feature that already had a known vulnerability pattern in its original form.
2. Escalation happens when the agent reproduces the vulnerable logic while preserving functional correctness, making the flaw easier to ship through ordinary development workflows.
3. Impact follows when insecure AI-generated code reaches production and reintroduces exploitable weaknesses that the security community had already fixed.

NHI Mgmt Group analysis

AI coding quality is outpacing secure coding quality. The central finding here is not that AI agents fail to code. It is that they increasingly succeed at generating working code while failing to preserve the security properties already established in upstream fixes. That widens the governance problem for application security teams. Practitioners should stop treating secure code generation as a model-quality issue and start treating it as a pipeline assurance issue.

Resurrected vulnerability: the new failure mode in agentic development. This study gives a useful name to a pattern many teams are already seeing: the agent does not invent a new flaw, it revives a known one. That matters because known CVEs often sit in the exact code paths that AI agents are asked to extend, refactor, or rebuild. The practical conclusion is that code provenance and patch lineage now matter as much as static analysis results.

Identity and access controls become part of secure coding governance. AI-generated code frequently touches authentication handlers, service-to-service calls, tokens, and administrative workflows. If agents can create or modify those paths without identity-aware guardrails, a code quality issue becomes an IAM and NHI issue. That means engineering teams need traceability over which agent touched which privileged code path and under what approvals.

Security review must move left into task construction. The study shows that after-the-fact review helps, but not enough. The better control point is before the agent writes code, when the task can be constrained with secure design rules, approved patterns, and explicit forbidden constructs. Practitioners should interpret this as a governance requirement, not a tooling preference.

The benchmark gap is a warning for production workflows. The researchers scoped tasks where the vulnerability was the natural way to build the feature, which is exactly why the results are operationally relevant. Real repositories contain many such patterns, especially in authentication, routing, and input handling. Teams should therefore assume that agentic coding will reintroduce old defects unless secure-by-construction guardrails are enforced.

What this signals

The operational signal is clear: AI coding is moving into the same risk class as other machine-assisted production workflows, where speed can outpace assurance. Teams that already struggle to govern secrets, service accounts, and privileged pipelines will feel the pressure first, because insecure code can now be generated faster than it can be reviewed.

Resurrected vulnerability risk: organisations should treat agent-generated code as a source of repeated historical defects, not just novel bugs. That means pairing AppSec controls with IAM and NHI oversight so that privileged application logic, secrets handling, and service account usage are all covered by the same review boundary.

The next maturity step is not more generic AI policy. It is tighter engineering governance around task specification, code provenance, and security regression testing. Organisations that can link AI-generated changes to control evidence will be better placed to absorb agentic development without expanding their breach surface.

For practitioners

• Block known-vulnerable patterns at generation time Create policy checks that reject agent output matching high-risk patterns such as traversal, unsafe deserialisation, and weak auth handling before code reaches review.
• Add security intent to the task spec Require developers to provide secure implementation constraints, forbidden APIs, and expected control behaviour before an AI agent begins generating code.
• Gate merges on security-relevant tests Make passing functional tests insufficient for merge approval by adding security regression tests tied to the vulnerability classes most likely to recur.
• Track which agents touch privileged code paths Maintain auditability for agent-generated changes in authentication, token handling, and service account workflows so reviewers can spot repeated risky edits.
• Align AppSec and NHI governance Review agent-built code that interacts with secrets, service accounts, and API credentials under both application security and NHI controls, not one or the other.

Key takeaways

• Frontier AI coding agents are now better at shipping working code than at preserving the security fixes already present in the codebase.
• The evidence points to a repeatable control gap, where functional success rises while secure-and-functional success remains far lower.
• Security teams should move from prompt-level advice to governance over task design, code provenance, and regression testing.

Key terms

• Resurrected vulnerability: A resurrected vulnerability is a previously discovered and patched flaw that reappears in new code, often because an automated system reproduces the vulnerable pattern while satisfying the feature request. It matters because the defect is not new, but its reintroduction can be fast, repeated, and hard to spot without regression controls.
• Secure-and-functional success: Secure-and-functional success is the state where code both works as intended and avoids introducing the security weakness that the task could easily recreate. It is a more useful measure than functional success alone because it captures whether the output is deployable from both an engineering and security perspective.
• Security regression testing: Security regression testing is the practice of checking new code against known vulnerability classes and previously fixed defects so they do not return. In AI-assisted development, it is the main control that distinguishes correct output from safe output, especially in authentication, input handling, and secrets-related logic.

What's in the full report

Checkmarx's full research covers the operational detail this post intentionally leaves for the source:

• Per-CWE breakdown showing which vulnerability classes were most often resurrected by frontier AI agents.
• Intervention cost analysis comparing prompt reminders, reasoning effort, threat modelling, and post-hoc review.
• Full failure-mode taxonomy explaining how agents preserved functionality while reintroducing insecure logic.
• Benchmark design details for SusViBes and the model cohort used in the study.

👉 The full Checkmarx research covers the benchmark design, intervention costs, and per-CWE failure patterns.

Deepen your knowledge

NHI Mgmt Group’s 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 workflows that now include AI-generated code and agentic systems.