Claude Security 2026: Catch Vulnerabilities That Reappear in Code

Teams that patch a bug often see the same bug return a few months later. A developer copies the old vulnerable helper into a new service, a refactor undoes a fix, or someone writes a slightly different version of the same injection flaw in a module nobody reviewed. Anthropic’s latest Claude Security update targets that problem: it now flags vulnerabilities that reappear after they were fixed. The timing is pointed. It shipped the same week AI agents found a critical flaw in some of the web’s foundational code, a sign that AI-driven bug hunting has moved past demos. The tools that find bugs are getting faster, so your defenses need to remember what they already found.

What’s actually new in Claude Security

The main change is memory. Until now, most AI security code review worked like a single snapshot: scan the diff, report findings, move on. The updated Claude Security treats a fixed vulnerability as a pattern to keep watching. Once a flaw is patched, Claude can detect three kinds of recurrence:

• Copy-pasted bugs: the vulnerable code was duplicated elsewhere before or after the fix.
• Regressions: a later change reintroduces the original problem.
• Variants: the same class of mistake written differently, such as a second unsanitized query builder that never shared code with the first.

Variant analysis without hand-written queries

Security researchers call the third category variant analysis, and it has traditionally been slow, expert-heavy work. Someone fixes a bug, then a skilled engineer writes a custom query in a tool like CodeQL or Semgrep to find its relatives. Anthropic’s pitch is that a model which understands what a bug means can find variants without anyone writing the query. It can reason that “this function trusts a user-controlled path the same way the patched one did,” even when the syntax, variable names, and file structure differ completely.

Where this fits in Anthropic’s security tooling

Anthropic has been building out its security tooling all year. That includes the open-source Claude Code security review GitHub Action, the built-in /security-review command in Claude Code, and reported plans to bring its more capable Mythos model to Claude Code and Claude Security. Recurring-vulnerability detection fits that direction: Claude Security is becoming a system that remembers your security history, not a one-off linter.

Why Claude Security’s recurring detection matters

• Recurring bugs are a real share of the risk. Many serious incidents trace back to a “fixed” bug that was fixed in only one place. Even Anthropic’s own Claude Code has shipped several patches in 2026 for bypasses of the same trust and write-protection checks. If the vendor is fighting variants in its own product, everyone else is too.
• AI-generated code makes copy-paste worse. Coding assistants produce a lot of similar boilerplate. A model that learned one insecure pattern from your repo can repeat it across a dozen files in an afternoon. Regression detection is the matching countermeasure.
• Small teams get variant analysis. Large companies employ staff who write custom static-analysis queries. A five-person startup doesn’t. Semantic, AI-driven variant analysis gives smaller teams some of that capability without the specialist headcount.
• Attackers already work this way. When a CVE drops, attackers look for the same flaw in related code paths and forks. Defenders who run variant searches only after an incident are behind.
• Less repeat triage. Linking a new finding to a known, already-fixed issue gives reviewers instant context: “this is the same bug as ticket #482.” That cuts triage time sharply.
• It raises the baseline for AI code review. A security tool that only reads the current diff now looks out of date.

How to use Claude Security today

Availability and controls depend on your plan and your organization’s Claude Security setup, so check your admin console first. The workflow below works now with the tools Anthropic ships publicly: Claude Code, the /security-review command, and the open-source GitHub Action. It reproduces the same “find the bug again” behavior in a way you can audit.

1. Build a known-vulnerabilities file

Recurring detection works best when Claude knows what you have already fixed. Keep a short, plain-language record in your repo. It’s cheap to maintain and gives the model concrete targets.

# SECURITY_HISTORY.md
## SEC-014: SQL injection in report export (fixed 2026-06-03)
- Root cause: user-supplied `sort` param concatenated into ORDER BY
- Fix: allowlist of sortable columns in reports/export.py
- Watch for: any raw string building of ORDER BY / WHERE clauses

## SEC-021: Path traversal in avatar upload (fixed 2026-08-19)
- Root cause: filename joined to upload dir without normalization
- Fix: secure_filename() + resolved-path prefix check
- Watch for: os.path.join with request-derived filenames

2. Run a variant hunt locally with Claude Code

Open the repo in Claude Code and give it a targeted prompt. Ask for evidence, not guesses.

Read SECURITY_HISTORY.md. For each fixed vulnerability, search the
entire codebase for:
1. Copies of the original vulnerable code (exact or near-exact),
2. Regressions where the fix has been removed or bypassed,
3. Variants: different code that makes the same underlying mistake.

For every finding, report: file and line, which SEC-ID it relates to,
why it is the same class of bug, a concrete exploit input, and a
minimal patch. Do not report style issues. If you are not confident,
say so and explain what would confirm it.

3. Run the built-in security review on every branch

Before opening a pull request, run the slash command inside Claude Code. It reviews pending changes for security issues, and with the history file in the repo you can tell it to check the diff against past fixes.

/security-review

Also check whether any change in this branch reintroduces a
vulnerability listed in SECURITY_HISTORY.md.

4. Automate it in CI with the GitHub Action

Anthropic’s open-source action reviews pull requests and posts findings as comments. Add custom instructions so every PR is checked against your history file.

# .github/workflows/claude-security.yml
name: Claude Security Review
on:
  pull_request:

permissions:
  pull-requests: write
  contents: read

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
          comment-pr: true
          custom-security-scan-instructions: .github/security-history-instructions.txt

Check the input names against the action’s current README before you commit. Parameters change between versions.

5. Write the custom instructions file

This file connects your history to every automated review.

# .github/security-history-instructions.txt
In addition to standard checks, compare every change against the
fixed vulnerabilities documented in SECURITY_HISTORY.md. Flag:
- reintroduction of any previously fixed pattern (regression),
- duplicated code derived from a previously vulnerable function,
- new code that repeats the same root cause in a different form.
Reference the matching SEC-ID in each finding.

6. Lock fixes in with regression tests

When Claude finds a variant, have it write a failing test that reproduces the exploit, then the fix. A test is your most durable form of memory.

For finding SEC-014-variant in billing/ledger.py, write a pytest
test that demonstrates the injection with a malicious sort value,
confirm it fails on current code, then apply the minimal fix and
confirm it passes. Show me the diff.

7. Update the history with every fix

The loop only compounds if you feed it. Make “add an entry to SECURITY_HISTORY.md” a required item on your security-fix PR template.

How Claude Security compares

Claude Security isn’t the only tool aimed at variant analysis. The core split is semantic, model-driven reasoning versus rule- or query-driven matching. Many mature teams will use both.

Tool	How it finds recurring bugs	Strengths	Trade-offs
Claude Security	Model reasons about the meaning of a past fix and searches for copies, regressions, and variants	Catches variants that look different on the surface; explains findings in plain language; little setup	Results aren’t fully deterministic; findings need human triage; may require a paid Claude plan
GitHub CodeQL (variant analysis)	Engineers write queries that model the bug, then run them across one or many repos	Precise, repeatable, scales across thousands of repos	Writing queries takes specialist skill; slower to respond to a brand-new bug class
Semgrep	Pattern-based rules, with AI-assisted triage and rule writing	Fast, readable rules; good for blocking known patterns in CI	Misses variants that don’t match the rule’s shape
Snyk Code	Hybrid symbolic and AI static analysis with curated rules	Strong developer UX and IDE integration	Less tailored to your own repo’s bug history
Google Big Sleep / research agents	Autonomous AI agents hunting vulnerabilities, often variants of known bugs	Has found real bugs in widely used open-source code	Research-oriented; not a drop-in product for most teams

Our view: use Claude Security for discovery and reasoning, then turn each confirmed variant into a deterministic rule (CodeQL or Semgrep) plus a regression test. The model finds what’s new; the rules keep it from coming back.

What’s next

Cross-repository detection

Most organizations don’t have one codebase. They have forks, internal libraries, and microservices that all copied the same utility in 2023. The obvious next step is for Claude Security to take a fix in one repo and hunt for the same flaw in every repo it can access, which CodeQL’s multi-repository variant analysis already does with queries.

Stronger models

Anthropic keeps opening access to stronger models for security work, and every capability jump improves variant analysis directly, because finding variants is a reasoning problem, not a pattern-matching one. AI agents finding critical flaws in foundational web code the same week this shipped shows where things are heading. Offensive and defensive AI are improving together, and the side with better memory of its own bugs has the edge.

The workflow layer

Watch for auto-generated fix PRs, auto-generated regression tests, and ticketing integrations that reopen the original issue on a recurring finding instead of filing a new one. Teams that set up a security history file and a CI gate now will get far more out of those features when they arrive.

Frequently Asked Questions

What does Claude Security’s recurring vulnerability detection actually catch?

It flags vulnerabilities that return after being patched: copy-pasted vulnerable code, regressions where a later change undoes a fix, and variants where different code repeats the same underlying mistake. Variants are the hardest category for traditional pattern-matching tools, and they’re where AI variant analysis helps most.

Is this different from running a normal SAST scanner?

Yes. Traditional static analysis matches predefined rules. Claude Security reasons about what a past fix protected against and looks for code with the same problem, even when it looks nothing like the original. In practice, run both: let the AI find new variants, then turn confirmed ones into fixed rules.

Do I need to tell Claude about past vulnerabilities?

It helps significantly. A simple SECURITY_HISTORY.md listing each fixed bug, its root cause, and what to watch for gives the model concrete targets. Without it, Claude can still find suspicious patterns but has less context for tying them to your history.

Can I use this in CI/CD?

Yes. Anthropic’s open-source claude-code-security-review GitHub Action reviews pull requests and comments on findings, and you can point it at custom instructions that reference your vulnerability history. Inside Claude Code, the /security-review command does the same for local branches.

Will it replace human security review?

No. AI security review is a strong first pass and a good way to scale variant hunting, but findings still need human triage, especially before high-risk releases. Treat it as a tireless junior analyst who never forgets a past bug, not as the person who signs off.

How do I stop fixed bugs from coming back for good?

Combine three layers: Claude Security to find recurrences, a deterministic rule (Semgrep or CodeQL) for each confirmed pattern, and a regression test that reproduces the original exploit. Then make updating your security history a required part of every fix.