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.

Expanded Definition

A resurrected vulnerability is not a brand-new defect. It is a previously patched weakness that returns when code is regenerated, copied, refactored, or adapted by an automated system that reproduces the same insecure pattern while meeting the requested feature. In NHI and agentic environments, that often means the same broken auth flow, unsafe token handling, or insecure default permission model comes back in a fresh repository, prompt response, or code path.

Definitions vary across vendors on whether the term should apply only to exact reintroductions or also to semantically equivalent flaws that create the same exposure. NHI Management Group treats the term operationally: if a control failure has already been understood and remediated once, but reappears in a new implementation, it is a resurrected vulnerability regardless of whether the syntax changed. That distinction matters because regression testing, secure code review, and policy guardrails must detect recurrence, not just novel defects.

The concept aligns closely with guidance in CISA cyber threat advisories and the NHI control focus described in Top 10 NHI Issues. The most common misapplication is treating a reintroduced flaw as a new issue, which occurs when teams lack historical defect context in automated code generation pipelines.

Examples and Use Cases

Implementing prevention rigorously often introduces review overhead, requiring organisations to weigh delivery speed against the cost of stronger regression controls and provenance tracking.

• An AI coding assistant recreates hardcoded API key usage after a prior incident had already been fixed in the same service.
• A service account is refactored into a new microservice, but the original broad privilege scope returns because the generated code copies the old role assignment pattern.
• A pipeline emits a token refresh routine that omits expiration checks, reproducing a vulnerability previously removed during remediation. See the JetBrains GitHub plugin token exposure case for how token handling failures can surface quickly.
• A prompt-driven agent builds a new integration with insecure secret storage, despite an earlier fix that moved secrets into a vault and enforced rotation.
• Regression tests fail to capture a known insecure deserialization pattern, so a patched issue reappears in a new release branch after automated merge completion.

At the standards level, secure development guidance in CIS Controls v8 reinforces the need for continuous vulnerability management, while NHI-focused analysis in OWASP NHI Top 10 shows how agentic systems can reproduce insecure patterns at scale.

Why It Matters in NHI Security

Resurrected vulnerabilities are especially dangerous in NHI environments because service accounts, API keys, and automation agents can replicate defects faster than human review can catch them. Once a flawed pattern returns, it can propagate across environments, workloads, and tenants before defenders notice that the issue is not novel but recurring. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which means a reintroduced flaw often lands inside an already over-permissioned identity surface, increasing blast radius immediately.

This matters for governance because repeated defects reveal that prior fixes were local, not systemic. Organisations that rely on one-time patching without regression policy, secret scanning, or identity lifecycle controls tend to see the same exposure return in code, configuration, or CI/CD automation. The operational lesson is reinforced by broader risk guidance in ENISA Threat Landscape, where recurring weaknesses compound across supply chains and software delivery paths.

Organisations typically encounter the full impact only after an incident review reveals that the “new” flaw was already fixed once before, at which point resurrected vulnerability management becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• Why does AI-driven vulnerability discovery change NHI governance?
• What is the difference between vulnerability scanning and continuous exposure management?
• What is the difference between theoretical vulnerability and reachable risk?