How to Remediate Vulnerabilities with AI Agents

AI vulnerability remediation uses a coding agent to investigate one confirmed security finding, make the smallest justified change, run the relevant tests, and return a pull request or triage note for human review. The agent accelerates repository work; it does not decide risk acceptance, invent fixed versions, or gain permission to change production.

Here, agentic vulnerability remediation means AI agents fixing traditional software, dependency, container, and repository-configuration vulnerabilities. It does not mean securing the agent, model, tool, memory, identity, or connector system itself. Use AI Agent Security for that workstream. This method is also distinct from endpoint agents that only recommend actions for an operator to perform.

Last updated August 21, 2026. Stephen M Abbott maintains this guide with Security Recipes contributors in the public source and revision history. See the review methodology and corrections policy. The method follows evidence and change-control principles from the NIST Secure Software Development Framework, while product and vulnerability facts remain anchored to the affected vendor, CVE record, NVD, and CISA evidence.

These playbooks are reusable, bounded instructions for that workflow. Each one should tell an AI agent:

• what kind of finding it can handle,
• what context it needs,
• what files it should avoid,
• what tests or checks matter,
• when to stop and write a triage note,
• what a reviewer should see in the output.

The goal is not to automate every security task. The goal is to make safe, bounded fixes easier to delegate while keeping source authority, change approval, and final review with people.

How to remediate a vulnerability with an AI agent

Before granting write access, require a named finding, proven affectedness, an authoritative fix or mitigation, repository ownership, an allowed path set, a protected test or scan, a rollback state, and a required reviewer. Dependency, SAST, container, and repository-configuration findings can usually enter this workflow. Endpoint patching, firmware, secret rotation, production-only infrastructure, end-of-life products, and unclear ownership should stop for operator-led triage unless separate authority and evidence are supplied.

1. Identify one finding. Start with a CVE, dependency alert, SAST result, exposed secret, vulnerable container layer, or similarly concrete signal.
2. Establish exposure. Confirm the affected product, version, code path, configuration, and deployed artifact before changing anything.
3. Choose the narrowest playbook. Give the agent only the repository files, evidence sources, and allowed operations needed for this finding.
4. Capture rollback before mutation. Record the current manifest, lockfile, configuration, image, or source state and the trigger that would restore it.
5. Apply an authoritative fix. Prefer a vendor-supported release or a documented mitigation. Never infer a fixed version from absence of evidence, leftover draft text, or a guessed next tag.
6. Verify the result. Run focused regression tests, rebuild from a clean state, rescan, and confirm the deployed component identity where applicable.
7. Require human review. Return the evidence, diff, tests, residual risk, and rollback path. Stop with TRIAGE.md when ownership or safe remediation cannot be proved.

Start with the CVE Database for an exact vulnerability, the Quick Start for a first agent-assisted fix, or the playbooks below for a specific finding class.

CVE-specific remediation guides

Use a CVE-specific recipe only when its product and affected-version evidence match the finding you are investigating. The CVE Database publishes 57 search-indexable CVE pages: 33 human-reviewed stable guides and 24 AI-qualified pages that already name a vendor or GHSA fixed release. Development drafts stay noindex so leftover version text cannot become a search or MCP floor.

• CVE-2026-9198: Langflow auto-login to code-validation RCE
• CVE-2026-35616: FortiClient EMS improper access control
• CVE-2026-48027: Nx Console 18.95.0 extension compromise
• CVE-2025-2747: Kentico Xperience staging authentication bypass
• CVE-2025-1976: Brocade Fabric OS code injection
• CVE-2024-9465: Palo Alto Expedition SQL injection
• CVE-2024-40711: Veeam Backup & Replication deserialization
• CVE-2026-72898: Metabase unauthenticated SQL injection
• CVE-2026-64849: MLflow unauthenticated webhook SSRF
• CVE-2026-63077: TeamCity unauthenticated agent-polling RCE
• CVE-2026-55255: Langflow flow-ownership IDOR
• CVE-2026-48172: LiteSpeed cPanel plugin root privilege escalation
• CVE-2026-45321: TanStack npm supply-chain compromise
• CVE-2026-39987: Marimo pre-auth terminal RCE
• CVE-2026-14956: Bricksforge Pro Forms privilege escalation
• CVE-2025-48384: Git submodule code execution
• CVE-2025-11953: Metro4Shell React Native CLI RCE
• CVE-2025-62593: Ray dashboard jobs RCE
• CVE-2025-3248: Langflow unauthenticated RCE
• CVE-2022-26134: Confluence Server and Data Center OGNL RCE
• CVE-2024-23897: Jenkins CLI arbitrary file read
• CVE-2024-37079: VMware vCenter Server heap-overflow RCE
• CVE-2024-6387: OpenSSH regreSSHion race-condition RCE
• CVE-2021-44228: Log4Shell in Apache Log4j
• CVE-2024-3094: xz-utils supply-chain backdoor
• CVE-2021-35395: Realtek AP-Router SDK buffer overflow
• CVE-2014-6271: Shellshock Bash environment-variable RCE
• CVE-2014-0160: Heartbleed in OpenSSL

What an AI remediation agent should and should not do

An AI coding agent is most useful as a bounded repository operator. It can trace dependency resolution, locate a vulnerable call site, prepare a narrow patch, update tests, and assemble review evidence. It should not be treated as the authority for affected versions, exploitability, business risk, or release approval.

The agent may do	Keep human-owned
Read the named alert, advisory, manifests, lockfiles, source, and tests	Decide whether the finding is accepted, deferred, or remediated
Prove which package, image, configuration, or code path is present	Confirm production ownership, exposure, and maintenance windows
Apply a vendor-supported upgrade or a documented mitigation	Approve breaking changes, compensating controls, and residual risk
Run focused tests, rebuild, rescan, and record command output	Review the diff and authorize merge or deployment
Stop with a precise triage note when evidence is missing	Supply credentials, secrets, production access, or broader authority

Securing the remediation agent is a separate workstream from the finding it is assigned to fix. Use AI Agent Security for threat modeling, identity, tool and connector authorization, context poisoning, memory, browser isolation, evaluation, and incident readiness. For a remediation run, start read-only, define an explicit file boundary, grant the smallest necessary write capability, and provide no production credentials by default.

Choose an AI agent for vulnerability remediation

Use the agent your team already governs. Start with AI agents for vulnerability remediation to compare supported tools and their native instruction surfaces. Each guide maps the same evidence, scope, verification, rollback, and human-review contract onto that agent.

Agent guide	Focused remediation recipe
Remediate vulnerabilities with Codex	Codex vulnerable dependency remediation prompt
Remediate CVEs with Claude Code	Claude Code CVE remediation skill
Remediate vulnerable dependencies with Cursor	Cursor vulnerable dependency remediation
Remediate vulnerabilities with GitHub Copilot	GitHub Copilot vulnerability remediation template
Run scheduled vulnerability remediation with Devin	Devin scheduled vulnerability remediation

Hypothetical workflow: remediate a dependency CVE with an AI agent

Suppose a dependency alert reports a CVE in a transitive package. A weak instruction such as “fix all vulnerabilities” invites unrelated upgrades and gives the reviewer no proof that the reported component was removed. A bounded run starts with the alert, the authoritative advisory, the repository’s manifest and lockfile, and the exact tests permitted for the affected area.

Agent prompt template

Remediate one finding:  in .

Allowed scope:
- Read , , , affected source, and named tests.
- Change only files required for the smallest vendor-supported remediation.
- Do not deploy, rotate secrets, change permissions, or update unrelated packages.

Required evidence before editing:
1. Show the resolved vulnerable version and dependency path.
2. Cite the vendor-supported fixed version or documented mitigation.
3. State whether the affected code path or configuration is present.
4. Record the current lockfile or artifact state for rollback.

Verification:
- Preserve the original alert, reproducer, or scan result and its checksum
  before editing.
- Do not weaken, delete, skip, or reconfigure the scanner, CI gate, or original
  regression that proves the finding.
- Run .
- Rebuild from a clean dependency state.
- Show that the vulnerable version is absent from the resolved graph.
- Run the protected reproducer or an independently owned verifier after the
  patch.
- Report residual risk and the exact rollback command or revert path.

If affectedness, ownership, or a supported fix cannot be proved, stop and
write TRIAGE.md. Do not guess a version or broaden the change.

Evidence a reviewer should receive

A reviewer-ready result contains the finding identity and source URL, the before-and-after dependency path, a small diff, test and build output, a rescan or equivalent absence check, rollback instructions, and remaining uncertainty. “The tests passed” is not sufficient if the old package still exists in another workspace, container layer, generated artifact, or deployed image.

The correct result may be a triage note rather than a patch. For example, stop when the only fixed release requires an unowned platform migration, when the alert refers to a package that is not in the shipped artifact, or when a vendor has not published a supported remediation. Those outcomes require a human risk decision, not a more confident prompt.

Real repository case study: CVE-2026-13149 in brace-expansion

On July 21, 2026, this repository’s Dependabot alert 9 identified CVE-2026-13149 / GHSA-3jxr-9vmj-r5cp in the transitive development dependency brace-expansion. The lockfile resolved minimatch to brace-expansion 1.1.15; the advisory marks the 1.x line below 1.1.16 as vulnerable to exponential CPU consumption from a short brace-pattern input.

A bounded, agent-assisted task produced the dependency portion of pull request 89, which was reviewed and merged the same day. That pull request also fixed a separate Fail2Ban deployment bootstrap problem. The evidence below therefore describes only the dependency slice; it does not present the entire pull request as a one-finding change.

Contract item	Recorded evidence
Finding	One high-severity advisory affecting transitive brace-expansion 1.1.15; the supported first patched 1.x release was 1.1.16.
Scope	package-lock.json and the dependency regression in tests/test_dependabot_config.js; no application API or unrelated package upgrade was required.
Change	The lockfile moved 1.1.15 to 1.1.16 and updated its registry artifact integrity.
Verification	The regression pins 1.1.16, the advisory proof input completed in about 1 ms, npm audit reported zero vulnerabilities, and the repository build, performance budget, and test suites passed.
Review and recovery	The public PR preserves the diff and validation trail. Reverting that dependency slice would restore the vulnerable version, so an operational rollback would need another supported patched release rather than 1.1.15.

The durable proof is the version regression and the public pull-request record, not the agent’s summary. This example shows the useful boundary: an agent can trace a transitive package, prepare a narrow lockfile update, run the protected check, and assemble evidence. A person still accepts the advisory, reviews the combined pull-request scope, and authorizes the merge. It does not prove that every dependency alert, production asset, or breaking upgrade is safe to delegate.

Prioritize evidence before asking the agent to patch

Severity is an input, not a complete remediation decision. FIRST’s CVSS v4 specification separates intrinsic base characteristics from threat and environment-specific metrics. Combine that signal with actual deployment exposure, reachability, asset importance, compensating controls, and evidence of exploitation.

Use this source order for a CVE-driven run:

1. The affected vendor’s advisory and fixed-release notes for product-specific affected ranges, patches, and mitigations.
2. The CVE record and NVD entry for identity, normalized descriptions, CWE, CVSS observations, and source references.
3. The CISA Known Exploited Vulnerabilities Catalog as an explicit prioritization input when exploitation is known in the wild.
4. The repository and deployed artifact for proof that the affected component and path actually exist in your environment.

Never let a model-generated summary outrank a newer vendor advisory. When two sources disagree, preserve both claims, their dates, and the unresolved gap; route the finding to a person who owns the affected system.

Exact scope

Exact scope means a recipe is allowed to handle one concrete finding, not a general backlog theme. The recipe should be narrow enough that a reviewer can tell whether the agent stayed inside the boundary without reconstructing the whole system.

A scoped recipe names:

• the finding identity, such as a CVE, scanner rule, SARIF alert, package, endpoint, or source/sink pair;
• the files, manifests, tests, and configuration the agent may inspect or change;
• the files and actions that are explicitly out of scope;
• the evidence that must be returned before review starts;
• the stop conditions that turn the run into a triage note instead of a patch.

The boundary is useful because it makes failure legible. If an agent needs to touch unrelated ownership areas, change deployment topology, migrate data, edit secrets, broaden permissions, or fix several findings at once, the recipe should stop and ask for a human-owned plan. That is not a failed automation run; it is the guardrail working.

Use Recipe Recommender to choose the single safest recipe before work starts, and use Reviewer Playbook to reject PRs that drift outside the declared scope.

Python remediation suite

Core remediation recipes

Specialized domains

Operating the recipe loop

Secure the remediation agent separately

This pillar governs how an AI coding agent fixes a traditional software finding. It does not fully secure the AI-agent system that interprets untrusted context, holds identities, calls tools, uses browsers or connectors, retains memory, and hands work to other agents. Use AI Agent Security: How to Secure AI Agent Systems for the threat-modeling method, production baseline, source boundaries, and complete control directory for that separate workstream.

Recipe run contract

One finding.
One matching recipe.
One agent run.
One PR or triage note.
Human review before merge.

That contract keeps agentic remediation useful. If a finding requires broad architecture work, production infrastructure changes, unclear ownership, or a high-risk data migration, the correct output is a triage note rather than a heroic patch.

MCP context for recipes

Most recipes get better when the agent can read structured evidence:

• advisory and package data,
• code scanning alerts,
• SBOM or SARIF output,
• repository ownership,
• CI status,
• internal runbooks.

Use MCP Integration to connect those sources as scoped context. Start read-only; add write access only after a separate review.

Common questions about AI vulnerability remediation

Can an AI agent automatically patch every CVE?

No. It can safely handle a subset of findings where affectedness, repository ownership, an authoritative remediation, focused verification, and rollback are all available. Kernel, firmware, infrastructure, data migration, production-only, end-of-life, or ownership-ambiguous findings usually require triage and a human-owned change plan.

Which coding agents can use these playbooks?

The method is tool-independent. Use the setup guides for Codex, Claude Code, Cursor, GitHub Copilot, or Devin to translate the same scope, evidence, stop, and review contract into the agent you already operate.

Should the agent use CVSS to choose what to fix first?

Not by itself. CVSS communicates vulnerability characteristics; it does not prove that your deployed asset is exposed or that a vulnerability is being exploited. Combine it with vendor urgency, CISA KEV status, reachable attack paths, asset criticality, and the cost and safety of the remediation.

What should happen when the agent cannot prove a safe fix?

It should stop without editing and return a triage note naming the missing evidence, affected owner, attempted checks, temporary containment options, and the decision required. A bounded stop is a successful control outcome; an unsupported upgrade is not.

Add or improve a recipe

Good recipes are specific. They name what is in scope, what is out of scope, what evidence is required, and what a safe stop looks like. See Contribute when you have a working recipe or prompt to share.