Prompt Injection CWE: The ID Exists and EchoLeak Never Used It

Prompt injection has a CWE, and the two incidents everyone cites were not filed under it.

That is not a clerical detail. A CWE ID is a claim about root cause, and every entry carries a mitigation table that follows from the root cause it names. When a record says CWE-1427, it is saying the product failed to neutralise input before building a prompt, and it is implying that neutralising the input is the fix. When a record says CWE-77 or CWE-74, it is saying the same thing one or two levels more generically. The whole prompt injection record, from the entry to the flagship CVEs, currently says the fix is neutralisation.

For an agent that reads untrusted content and holds real credentials, that fix cannot complete, and the weakness that let the data out has a different ID.

CWE-1427 Is the CWE for Prompt Injection, and Its Own Notes Exclude Half of It

CWE-1427 describes a product that uses externally provided data to build prompts for a large language model in a way that causes the model to fail to distinguish user-supplied input from developer-provided system directives.

It was submitted by Praetorian in June 2024, reviewed by the CWE Artificial Intelligence Working Group, and published in CWE 4.16 that November. It sits at Base abstraction, which MITRE describes as the preferred level for mapping real-world vulnerabilities, and it has one parent in the research view: CWE-77, Improper Neutralization of Special Elements used in a Command. Above CWE-77 sits CWE-74, the generic injection class, and above that CWE-707, the Improper Neutralization pillar. Prompt injection, in the taxonomy, is a species of command injection, which is a species of injection, which is a species of failing to neutralise.

The entry lists “prompt injection” as an alternate term and qualifies it: an attack-oriented term for modifying prompts, whether due to this weakness or other weaknesses. That qualifier is the first sign the authors knew the attack name covers more than the weakness does.

The second sign is the mapping notes. The Vulnerability Mapping section rates the entry Allowed and then adds a comment: ensure the weakness involves improper neutralization during prompt generation, because a different CWE might be needed if the core concern is inadvertent insertion of sensitive information, generating prompts from third-party sources that should not have been trusted, as may occur with indirect prompt injection, or jailbreaking, where the root cause might be a different weakness.

Read that sentence as the entry’s own scope statement. Indirect prompt injection, which is the form that reaches production agents, and jailbreaking, which OWASP files inside the same risk entry, are both flagged as possibly belonging elsewhere. Jailbreaking has no CWE at all, because a model’s refusal training is a model property rather than a product weakness. Indirect injection has no dedicated ID either. It has a note.

The entry is also a member of two AI categories: CWE-1446, Weaknesses Specific to AI/ML Technology, and CWE-1447, General Software Weaknesses that Appear in Products that Use AI/ML. Membership in both is a fair summary of the ambiguity: is this a new weakness or an old one wearing a new interface.

The Flagship Prompt Injection CVEs Were Filed Above It in the Tree

EchoLeak was never CWE-1427. Its NVD record carried CWE-77 from disclosure in June 2025, and on 20 February 2026 Microsoft removed CWE-77 and added CWE-74.

The change is in the NVD change history for CVE-2025-32711 as an informational update: the description, “AI command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network,” did not change, and neither did the score. What changed was the weakness ID, and it moved up the tree rather than down to the entry created for it. CWE-74 is Improper Neutralization of Special Elements in Output Used by a Downstream Component, the class that covers SQL injection, OS command injection and everything else where untrusted data reaches an interpreter. The best-documented prompt injection incident on the public record is now classified alongside them, one level more general than the ID that names LLM prompting specifically.

The GitHub Copilot remote code execution, CVE-2025-53773, was filed as CWE-77 and stayed there. Its description reads as ordinary command injection: improper neutralization of special elements used in a command allows an unauthorized attacker to execute code locally. The word “prompt” does not appear in the weakness field.

So the three assignments on the record are CWE-77, CWE-74 and CWE-77, and none is CWE-1427. That does not mean the assignments are wrong. A CNA choosing a parent class for an emerging weakness is being conservative, and CWE-77 is a defensible ancestor. It means the record does not distinguish a prompt injection from a shell injection at the weakness level, which is the level where mitigations are prescribed.

The entry’s own observed examples point the same direction. Two of the four are labelled chains on the entry itself, and the other two describe an injection that produced a second effect: leaked system prompts and data, and arbitrary code execution. CVE-2023-32786 is prompt injection (CWE-1427) in an LLM framework that allowed forcing a fetch from an arbitrary URL, described on the entry as essentially SSRF (CWE-918). CVE-2024-5565 is prompt injection (CWE-1427) in a SQL-generation library that allowed running arbitrary Python (CWE-94). MITRE’s own curated examples treat 1427 as the first link and name a second weakness for the consequence. The incidents on the public record have the same shape, and their CVE records name only the first link.

A Neutralization Weakness Prescribes a Neutralization Fix

The mitigation table on CWE-1427 is what the ID commits you to.

The first row, at the Architecture and Design phase, says LLM-enabled applications should ensure proper sanitisation of user-controllable input so that no intentionally misleading or dangerous characters can be included, and identify user-controllable input as untrusted. Effectiveness: High. The second row, at Implementation, says prompts should be constructed to differentiate user-supplied input from developer-constructed system prompting. Effectiveness: Moderate. Later rows cover training data, external guardrail components at operation time, and fine-tuning.

There are reasons the table reads that way. The entry was drafted for the chatbot era, and its demonstrative examples are a CWE-lookup bot that gets asked to write a pirate haiku and a joke-telling agent that leaks a token when asked. In both, the attacker’s text contains something distinctive, and both fixes are input validation on the prompt string. The mitigation ratings are accurate for that class.

The class that reaches production agents contains nothing to sanitise. The payload most likely to succeed against an agent is a grammatical sentence asking for an authorised action, with no dangerous characters, no override phrasing and no encoding. Sanitising characters does nothing to it. Marking it untrusted does something, and the measured record puts that something between thirty-five and forty-five percent for plain-language asks. A mitigation rated High against a payload class that has been unbundled from the weakness is a rating for a different problem.

The UK’s NCSC put the alternative diagnosis in one phrase: prompt injection is a confused deputy problem rather than an input-sanitisation bug. The model holds authority it exercises on behalf of whoever wrote the text in front of it. That is a weakness with a CWE of its own, CWE-441, Unintended Proxy or Intermediary, and it prescribes a different fix. NCSC’s sharper point is that a classical confused deputy can be corrected and an LLM cannot, which is why the fix is to constrain what the deputy can do rather than to teach it whom to obey. Prevention, on that reading, is a reachability property of the consequence rather than a filtering property of the input.

Here is the useful part. You do not have to wait for CWE to publish an agent-era entry. The consequence-bearing weaknesses already exist in the catalog, and a finding can name them today.

File Agent Findings as a Chain That Names the Consequence-Bearing Weakness

CWE-1427 carries both ordinalities on its entry: Primary, where the weakness exists on its own, and Resultant, where it follows from another weakness. File it as the first link and add the link that produced the harm.

The habit of one CWE per record is common, and CNAs keep to it for good reasons. MITRE’s own root-cause mapping guidance, and the observed examples on this entry, use chains when the harm is separable from the entry point. An agent incident is that case by construction: the injection is how the instruction arrived, and the harm is what the agent was allowed to do with it.

The last row matters as much as the others. A jailbreak that produces text the model should have refused is not a weakness in your product, and there is no ID to file. That is the practical edge of the ownership split: the difference between injection and jailbreak is who owns the fix, and the CWE record encodes it by having an entry for one and not the other.

Keep the catalogs apart, too. CWE names what is wrong with the product. MITRE ATLAS names what the attacker did, and its prompt injection technique, AML.T0051, is an attack identifier that says nothing about the weakness exploited. Mapping ATLAS techniques onto runtime evidence is a detection exercise; filing a CWE chain is a remediation exercise. A finding that cites only ATLAS has named the attack and left the fix open.

Read Scanner and Advisory CWEs for What They Leave Out

A finding labelled CWE-1427 tells you where untrusted text enters. It does not tell you what the agent can do once it has.

Posture tools produce that label at design time. An AI security posture scan reads the prompt construction, the connectors, the retrieval sources, and flags the places where external content is concatenated into a prompt without separation. That is real and it is the first link. The second link is only visible in execution: which credential the agent actually exercised, which destination it actually reached, which tool it actually called with which argument. None of that is in the prompt template, so none of it is in a 1427 finding.

The second link is what a runtime record supplies. ARMO records what each agent does in execution from a kernel-level sensor and builds a per-agent behavioral profile, Application Profile DNA (APD™), so that the resultant weakness has evidence attached: the confused-deputy read shows up as a credential exercised against a table the agent has never touched, the exfiltration shows up as an outbound connection with no precedent in the profile. Coercion, where every step is authorised and only the sequence is wrong, is the resultant weakness with a name. The Audit and Enforce sequence then turns that finding into a bound: observe the deviation first, review what a policy would have blocked, arm it per agent. That is the same discipline as progressive enforcement for agent workloads, applied to the CWE nobody filed.

Read vendor advisories the same way. When an advisory closes a prompt injection CVE, ask which link the fix closed. A fix that strips a markdown image renderer closed the CWE-201 link and left the CWE-1427 link open. A fix that adds a classifier moved the 1427 link from exposed to detected at a rate. A fix that removed a tool or scoped a credential closed the CWE-441 link, and that is the fix worth asking for by name.

ARMO’s runtime security for AI workloads supplies the execution record that turns the second link into a finding with evidence. Bring one agent and one scanner report to a working session and the report comes back with the resultant CWE and the runtime evidence for it next to every 1427 row.

The CWE You File Is the Fix You Are Promising

CWE-1427 alone promises that you will neutralise input. For an agent reading tickets, pages and pull requests, that promise cannot be kept, and an auditor who reads the mitigation column will eventually ask why it was made.

A chain promises something checkable: that the destination is unroutable, that the credential is scoped, that the tool is gone, that the deviation is enforced against. Each of those has a control, a test and an evidence row. File the chain and the finding names a fix your team can actually close.

FAQ

Is prompt injection CWE-77 or CWE-1427? Both appear on the public record. CWE-1427 is the Base-level entry created for LLM prompting in November 2024, and it is a child of CWE-77. The flagship CVEs were filed as CWE-77 and, in EchoLeak’s case, later moved to CWE-74. Use CWE-1427 for the entry point when the weakness is improper neutralisation during prompt construction, and add the resultant weakness for the consequence.

Does CWE-1427 cover indirect prompt injection? The entry’s mapping notes say a different CWE might be needed when the core concern is generating prompts from third-party sources that should not have been trusted, and names indirect prompt injection as the example. In practice CWE-1427 is still used for the entry point, and the untrusted-source aspect is best captured by naming CWE-441 in the chain, since the agent is acting as a deputy for content it should not have obeyed.

Is jailbreaking a CWE? No. CWE-1427’s mapping notes list jailbreaking as a case where the root cause might be a different weakness, and no entry exists for it, because the property being defeated is the model’s safety training rather than a weakness in the product built on it. A jailbreak finding belongs with the model vendor; an injection finding belongs with the team that owns the application.

Which CWE should we use for an agent that leaked data after prompt injection? A chain: CWE-1427 for the injection, CWE-441 or CWE-863 for the agent exercising authority it should not have applied to that request, and CWE-201 for sensitive data inserted into what it sent. Naming the middle link is what turns the finding into a scoping and enforcement fix rather than a request for better input filtering.

How do you test for CWE-1427? The entry lists dynamic analysis, with the note that non-deterministic model behaviour requires running the same case several times and re-running after any model change. For an agent, define the test over consequences rather than model output: one plain-request test per action the agent can complete, delivered through the content path it reads, scored on what happened and whether a finding fired.