The LLM Threat Landscape¶

The security landscape shifted in 2025. Large language models made vulnerability discovery, exploit generation, and fuzzing accessible to anyone with an API key and a credit card. The same tools that help developers write code faster help attackers find and exploit weaknesses faster.

This isn't theoretical. AI-powered fuzzing has already found novel vulnerabilities in production software. Automated exploit generation turns CVE disclosures into working attacks in hours instead of weeks. The barrier to entry for sophisticated attacks dropped to commodity pricing.

What Changed¶

Vulnerability Discovery at Scale¶

LLMs can analyze source code and identify potential vulnerabilities with remarkable accuracy. What used to require a skilled security researcher spending days on manual code review can now be partially automated:

• Pattern recognition — LLMs identify insecure coding patterns across entire codebases in minutes
• Variant analysis — Given one vulnerability, LLMs find similar patterns elsewhere in the codebase or in related projects
• Fuzzing guidance — LLMs generate targeted fuzzing inputs that exercise specific code paths, dramatically improving coverage
• Cross-language analysis — LLMs understand multiple languages simultaneously, finding vulnerabilities that span language boundaries in polyglot projects

When the Model Gets Pulled¶

In early 2026, Anthropic released — and then retracted — a model referred to publicly as Mythos. The stated reason: it was too proficient at discovering local privilege escalation vulnerabilities in Linux kernels and system libraries. Not "better than average at." Too good at, by design. The model was surfacing novel LPEs faster than the security community could triage them, let alone patch them.

That's the asymmetry made concrete. Not a theoretical concern about AI-assisted offense — an actual tool, made by a lab committed to safety research, that had to be pulled because the defensive side of the equation couldn't keep pace with what it was finding.

The capability isn't gone. Mythos was publicly visible; the less-scrupulous versions of the same approach are not. Someone is raking in money on the other side of this, and they aren't filing responsible disclosure reports.

The LPE problem in shared environments. Local privilege escalation is particularly dangerous anywhere multiple users share a machine. A university HPC cluster, a shared research compute system, a cloud VM with tenants: in these environments, an LPE isn't just "root on a machine." It's root on a machine where everyone's research data, credentials, queued jobs, and institutional access live.

The practical reality: the window between "LPE disclosed on Reddit" and "a curious user on your cluster ran the PoC to see what it would do" is measured in hours, not days. The PoC is often in the disclosure post. Your users aren't malicious — they're curious. Curiosity is enough.

Pen testing is losing the pace race. Traditional penetration testing engagements run on week-long or month-long timescales. AI-assisted vulnerability discovery runs continuously. The gap between "your last pentest" and "what an attacker knows about your attack surface right now" is widening. This doesn't mean pentests are worthless — the human judgment and context they provide still matters. But they're no longer a sufficient substitute for continuous scanning and a fast response process.

Exploit Generation¶

The time between vulnerability disclosure and weaponized exploit has compressed:

This doesn't mean every CVE becomes instantly exploitable. Complex vulnerabilities still require human judgment. But the long tail of "moderately difficult" exploits — the ones that used to buy you time — that buffer is gone.

Social Engineering¶

LLMs generate convincing phishing emails, fake maintainer personas, and plausible pull request contributions at scale. The xz utils attack required years of a human building trust. LLM-assisted social engineering can run dozens of such campaigns simultaneously, each with distinct writing styles and contribution histories.

Build Pipeline Attacks¶

AI tools can analyze build configurations, CI/CD pipelines, and deployment scripts to find injection points. The Claude Code source leak in early 2026 was a reminder: your build pipeline is source code too, and it's now subject to the same automated scrutiny as your application code.

Your Agent's Config Is Executable Content¶

This one is new, and it's already being exploited.

Agent and editor configuration files run code. .claude/settings.json defines hooks that fire on session start. .vscode/tasks.json can declare runOn: folderOpen. .devcontainer/ builds and executes on attach. MCP server definitions launch processes. None of these require you to install anything or run your application — the trigger is cloning the repository and opening it.

The keyv worm planted exactly these two hooks across hundreds of npm packages in August 2026, and the same technique appeared in the April 2026 PyPI compromises before it. Both editors block automatic task execution in untrusted workspaces by default, which helps — right up until someone marks a repo trusted to stop the prompt from nagging them.

Or right up until the tool doesn't check. CVE-2026-12957, disclosed in June 2026, was Amazon Q Developer loading MCP server definitions from .amazonq/mcp.json in any workspace you opened — no consent prompt, no workspace-trust check — and spawning those processes with your full environment attached, AWS credentials and SSH agent socket included. Plant the file in a repository, wait for someone to clone it and open the folder. See Amazon Q, which is also the clearest available demonstration that "we default to blocking untrusted workspaces" is a property of the editor, not of every extension running inside it.

The problem is that these files read like configuration. They're JSON. They sit next to .gitignore and .editorconfig. Reviewers skim them the way they skim a linter config, and nobody has spent fifteen years being trained to distrust them the way they distrust a postinstall script.

The escalation of this is worth naming separately, because it defeats a defense people are actively buying. When the same attacker who compromised the Amazon Q extension in July 2025 had full write access to the repository — able to ship literally any code they wanted to a million installs — what they shipped was a paragraph of English telling the agent to wipe the home directory and delete the user's AWS resources. That was the optimal choice, not a lazy one: the agent already holds the credentials, so there's no payload to write, and prose has no signature for a scanner to match, no syntax for a linter to reject, and no shape that makes a reviewer's eye stop.

A model in your pipeline turns natural language into a code-execution format, and you have no tooling that reads it as one.

Review agent and editor config with the same rigor as a lifecycle script. Diff .claude/, .vscode/, .devcontainer/, and MCP definitions on every incoming PR and every cloned repository. If you run agents across a fleet of repositories, that diff belongs in CI — an unexpected hook appearing in a config file is a high-signal, low-noise alert.

Your AI Gateway Is a Secrets Store¶

Nearly every team running more than one model has put a proxy in front of them — LiteLLM, an internal gateway, something with an OpenAI-compatible shape. The reason is good: applications shouldn't each carry provider credentials, so you centralize them.

Centralizing them is the point, and centralizing them is the risk. That box holds your OpenAI key, your Anthropic key, your Bedrock and Vertex credentials, and — because it usually runs in a cluster — a Kubernetes service account token. It is a secrets store. Almost nobody has it written down as one, which means it's frequently outside the inventory that governs how secrets stores get patched, monitored, and rotated.

In March 2026 TeamPCP published two malicious versions of litellm using PyPI tokens stolen from LiteLLM's own CI via the compromised Trivy scanner. They were live for forty minutes and reached roughly 2,500 organizations. The payload took environment variables, cloud credentials, and Kubernetes tokens — then used those tokens to create privileged pods. See LiteLLM / TeamPCP.

One mechanism from that incident deserves separate billing, because it generalizes past AI tooling:

Treat the gateway like a vault. Put it in your secrets inventory. Give it its own rotation schedule. Scope its Kubernetes service account down to nothing it doesn't need, since a stolen token there buys pods, not just API calls. And pin it — the official LiteLLM container image was untouched by all of this, because its dependencies were pinned and it never resolved either malicious version.

What Didn't Change¶

Before the anxiety sets in — the fundamentals still hold:

Defense in depth still works. No single control stops a determined attacker. Layers of controls force attackers to chain multiple exploits, and each layer is a chance to detect them.

Visibility is still your best asset. Knowing what you're running (SBOMs), knowing what's vulnerable (scanning), and knowing what changed (audit logs) still matter. An attacker with an LLM is still slowed by a well-monitored environment.

Updates still matter. Patching known vulnerabilities is still the highest-ROI security activity. LLMs make exploitation faster, which makes patching speed more critical — but the practice itself hasn't changed.

Code review still catches things. LLMs are good at finding patterns, but human reviewers catch semantic issues — "this code is correct but shouldn't exist" — that LLMs miss.

Defending Against Automated Attackers¶

Shrink the Attack Surface¶

The most effective defense against an AI-powered attacker is the same as against any attacker — give them less to work with:

Minimize dependencies. Every dependency is code an attacker can analyze. The evaluating dependencies framework matters more now. A dependency you don't have can't be exploited.

Remove dead code. LLMs will find vulnerabilities in code you forgot about. If it's not running in production, delete it.

Reduce public exposure. Services that don't need to face the internet shouldn't. Internal APIs that don't need public documentation shouldn't have it.

Accelerate Your Response¶

If the window between disclosure and exploitation is shrinking, your response has to shrink too:

Automated patching for low-risk updates. Configure Dependabot or Renovate to auto-merge patch-level security updates that pass your test suite. The risk of a broken patch is often lower than the risk of a delayed one.

# Renovate: auto-merge security patches
{
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "matchCategories": ["security"],
      "automerge": true,
      "automergeType": "branch"
    }
  ]
}

Pre-built upgrade paths. For critical dependencies, maintain a tested upgrade path to the next major version. When a critical CVE drops, you don't want to discover that upgrading also requires rewriting your auth layer.

Runbook, not panic. Document your vulnerability response process before you need it. Who triages? Who approves emergency patches? Who communicates? See vulnerability management for the workflow.

Monitor for AI-Assisted Attacks¶

New signals to watch for:

Unusual contribution patterns. Multiple new contributors submitting similar-looking code across related projects. LLM-generated code has stylistic fingerprints — watch for contributions that feel templated.

Rapid-fire vulnerability probing. If you expose any services, watch for scanning patterns that suggest automated vulnerability discovery — many variations of inputs testing the same code path.

Sophisticated phishing targeting maintainers. Messages that reference specific issues, use project-specific terminology correctly, and request access or changes. If someone's helpfulness feels too good — verify through a second channel.

Harden Your Build Pipeline¶

Your CI/CD pipeline is now a first-class attack target:

• Pin action versions by SHA, not tag — tags can be moved
• Minimize secrets in CI — use short-lived tokens where possible
• Review pipeline changes with the same rigor as code changes
• Isolate build environments — builds shouldn't have access to production
• Generate and verify provenance — SLSA compliance matters more when attacks are automated, but know its limit: an attestation proves which pipeline built the artifact, not that the source it built from was clean. The keyv worm shipped malware with valid OIDC and SLSA provenance, and minted fresh attestations for every package it republished.

# Pin by SHA, not tag
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1

# NOT this — tags can be reassigned
# - uses: actions/checkout@v4

Use AI for Defense Too¶

The same tools attackers use are available to you:

AI-assisted code review. Use LLMs to review PRs for security issues. They won't catch everything, but they catch patterns that humans skip when fatigued.

Automated dependency analysis. LLMs can assess whether a newly disclosed vulnerability actually affects your usage pattern, helping you triage faster.

Threat modeling. Describe your architecture to an LLM and ask it to identify attack vectors. It's not a replacement for expert threat modeling, but it's better than no threat modeling.

Fuzz your own code. If attackers are going to use AI-guided fuzzing against you, do it first. Tools like Google's OSS-Fuzz now integrate LLM-guided fuzzing that finds bugs before attackers do.

For Researchers and Small Teams¶

If you're a researcher or small team, this might feel overwhelming. A few grounded takeaways:

You're probably not a specific target. Automated attacks are opportunistic — they scan everything. Good baseline hygiene (updates, scanning, 2FA) still puts you ahead of most targets.

Your data might be the target, not your code. Research data, credentials, and institutional access are more valuable to attackers than your Python scripts. Protect research data and secrets accordingly.

Lean on your institution. University IT security teams, institutional vulnerability scanning, and managed CI/CD reduce the burden on individual researchers. Use what's provided before building your own.

Take the research-specific version. The pressures here aren't the ones a security team writes for — For Researchers translates all of this into grant timelines, sensitive-data compliance, and code that has to still run when the paper is cited five years from now. If you want to go past what this guide covers, Further Reading is where it hands you off.

Don't security-theater yourself into paralysis. Perfect security doesn't exist and never did. Do the basics well: update dependencies, use lock files, scan for vulnerabilities, don't commit secrets. That puts you ahead of 90% of targets.