Why Your Vulnerability Management Program Can't Score a Prompt Injection Finding

Prompt injection and tool-call abuse findings rarely fit CVE-based vulnerability management. Here's why they get dropped, and a framework to score them instead.

Why Your Vulnerability Management Program Can't Score a Prompt Injection Finding

Why Your Vulnerability Management Program Can't Score a Prompt Injection Finding

Prompt injection and AI tool-call abuse findings from a penetration test typically don't receive a CVE or CVSS score because they are behavioral, configuration-specific issues in a given deployment, not defects in a shipped software product. Vulnerability management workflows built around CVE intake fields have no way to file, score, or track them, so the findings often stall or get dropped.

A pentest report lands in your inbox. Twelve findings, cleanly formatted, ready to load into the vulnerability management platform your team has used for years. Eleven of them slot in without friction: CVE number, CVSS score, affected asset, remediation owner, due date. The twelfth finding is different. It says your customer support chatbot can be manipulated, through a crafted message, into ignoring its instructions and pulling account data it shouldn't disclose. There's no CVE. There's no CVSS score. The ticketing system has a required field for both, and nobody on the team knows what to type into it.

This is the quiet failure point of prompt injection vulnerability management right now. In our assessments, we consistently see organizations that handle CVE-based findings well and prompt injection or tool-call abuse findings badly, not because the second category is less dangerous, but because the intake process was never built to receive it. A May 2026 Help Net Security report on OWASP's agentic AI research noted that prompt injection remains the leading driver of security failures in production AI systems [1], and that gap is widening as more companies put agents in front of real data and real actions.

Why Doesn't Prompt Injection Get a CVSS Score?

CVSS was built to score defects in software: a specific version of a specific product has a specific flaw, and that flaw behaves the same way in every environment that runs it. A prompt injection or excessive-agency finding discovered in your penetration test doesn't work that way. It's usually a combination of your system prompt, your tool permissions, your retrieval pipeline, and your specific data sources. The same underlying model can be perfectly safe in one deployment and exploitable in another, because the vulnerability lives in how the application was built around the model, not in the model itself.

That distinction matters because it's exactly why a CVE number usually isn't coming. MITRE assigns CVEs to vulnerabilities in specific, identifiable products and versions. When a real prompt injection flaw exists in a widely used library or framework, one can and does get assigned. A March 2026 CVE for a memory-poisoning prompt injection path in a popular Java AI framework's chat memory advisor is a clear example [2]. But the finding your pentest team hands you almost never looks like that. It looks like: "an attacker who controls the content your support agent retrieves can get it to take an action outside its intended scope." That's a finding about your architecture, not a patchable defect in a vendor's code. There's nothing to assign a CVE to.

The OWASP Framing Confirms the Gap, It Doesn't Close It

OWASP's Top 10 for LLM Applications and its newer Top 10 for Agentic Applications both rank prompt injection and excessive agency as top risks [3]. That's useful for awareness. It does almost nothing for your Tuesday-morning ticketing workflow. A risk category on a published list still doesn't produce a CVSS vector string, and most vulnerability management platforms weren't built to score, route, or trend a finding that only has a severity rating your assessor assigned by hand.

What Happens to These Findings When They Don't Fit

Watch what actually happens to a prompt injection finding inside a CVE-shaped process, and the failure mode becomes predictable.

It Gets Filed as "Informational" and Never Revisited

Most ticketing systems default an un-scoreable finding to the lowest severity bucket, because that's the only bucket that doesn't require a CVSS input. An informational-severity ticket sits at the bottom of every prioritized queue, indefinitely, next to findings that genuinely don't matter.

It Gets Manually Re-Scored to Fit, and the Score Lies

Some teams force a CVSS-like number onto the finding so it fits the required field. This solves the intake problem and creates a worse one: a fabricated score gives leadership a false sense of precision about a finding that was never actually measured against the CVSS rubric it claims to use.

It Gets Verbally Acknowledged and Then Lost

The finding gets discussed in the pentest debrief call, everyone agrees it's important, and then nothing tracks it afterward because it was never entered into the system of record the rest of the security program runs on. Three months later, nobody can produce evidence it was ever remediated, which is precisely the kind of gap an auditor or examiner will find first. It's the same tracking failure we've written about before in Why Your Annual Penetration Test Isn't Covering Your AI Systems.

Test Your Own Environment: The Three-Question Check

Before your next AI-focused assessment, ask your team these three questions.

  1. Where does a finding with no CVE and no CVSS score get filed today? If the honest answer is "wherever the analyst decides," you don't have a process, you have an improvisation.
  2. Who owns remediation for a finding that isn't a patch? Prompt injection fixes are usually architecture changes: tightening a system prompt, scoping a tool's permissions, adding an output filter. If your remediation workflow assumes "apply patch, rescan," it has no lane for that kind of fix.
  3. Can you show an auditor, six months from now, that this finding was tracked to closure? If the answer depends on someone's memory of a debrief call, the answer is no.

A "no" to any of these is the actual finding, independent of whatever the pentest report says.

The Clone Systems AI Finding Severity Framework

Because CVSS doesn't fit, we score AI-specific findings from our assessments against a four-factor framework built for exactly this gap: Data Sensitivity (what can the exploited behavior expose or access), Action Reach (can the manipulated agent only respond, or can it also write, transact, or call other tools), Detection Blindness (would your current monitoring even notice this happening), and Repeatability (does the same crafted input reliably reproduce the behavior, or is it inconsistent). Each factor is scored High, Medium, or Low, and the combination determines a remediation timeline the same way a CVSS band would, giving these findings a defensible place in the queue instead of a default "informational" label.

If your last assessment scored AI-specific findings this way, you already know where they stand. If it didn't, that's worth fixing before your next penetration testing engagement, not after.

How Clone Systems Can Help

Clone Systems runs penetration testing and red-team assessments against AI-integrated applications, and our reports don't leave prompt injection, tool-call abuse, or excessive-agency findings for your team to figure out how to file. Every AI-specific finding is scored against the framework above, mapped to a concrete remediation action, and handed to your team in a format your existing ticketing workflow can actually ingest, so nothing sits in an "informational" bucket by default. If your last penetration test scope didn't explicitly cover your AI-integrated applications, that's the first gap worth closing before the next one does it for you.

Learn more at clonesystems.com or contact our team to scope an assessment that covers your AI-integrated systems.

Frequently Asked Questions

Does prompt injection have a CVE? A specific prompt injection flaw in a shipped software product or library can and sometimes does receive a CVE, such as vulnerabilities found in AI framework components. A prompt injection finding discovered during a penetration test of your own custom AI application almost never does, because it reflects your specific configuration rather than a defect in distributed code.

Why doesn't prompt injection have a CVSS score? CVSS scores technical defects in software that behave consistently across environments, and prompt injection findings are usually specific to how a particular application was built around a model. Most vulnerability management platforms have no scoring path for a finding that doesn't fit that model.

How should I prioritize a prompt injection finding without a CVSS score? Score it against factors that actually apply, such as what data or actions the exploited behavior can reach and whether your monitoring would detect it happening, rather than forcing a CVSS number that wasn't measured against the CVSS rubric. A four-factor severity framework built for AI-specific findings gives the finding a defensible place in your remediation queue.

Is prompt injection covered by a standard penetration test? Not automatically. A penetration test scoped only to network and application infrastructure will typically miss AI-specific behaviors like prompt injection and tool-call abuse unless the AI-integrated systems are explicitly included in the engagement scope.

What's the difference between prompt injection and excessive agency? Prompt injection is the technique of manipulating a model's behavior through crafted input, while excessive agency is the underlying condition that makes that manipulation dangerous, such as a model having tool permissions or data access broader than its task requires. The two are usually found together in a real assessment.

Ready to see whether your penetration testing program actually covers your AI-integrated systems? Contact Clone Systems to scope an assessment that scores AI-specific findings the way they actually need to be scored, not the way a CVE intake form assumes they will be.

References

[1] Help Net Security — Prompt injection still drives most agentic AI security failures in production, June 2026. https://www.helpnetsecurity.com/2026/06/11/owasp-prompt-injection-ai-security-failures/ [2] Spring.io Security Advisories — Prompt Injection via Memory Poisoning in PromptChatMemoryAdvisor (CVE-2026-41713), 2026. https://spring.io/security/cve-2026-41713/ [3] OWASP Gen AI Security Project — OWASP Top 10 for Agentic Applications 2026 and OWASP Top 10 for LLM Applications. https://genai.owasp.org/ [4] Clone Systems — Why Your Annual Penetration Test Isn't Covering Your AI Systems. https://www.clone-systems.com/why-your-annual-penetration-test-isnt-covering-your-ai-systems/ [5] Clone Systems — Automated Penetration Testing Services. https://www.clone-systems.com/automated-penetration-testing-service/

Ready when you are

Have a scoping question this post didn't answer?

A senior specialist will walk you through it. No junior sales handoffs, no scripted qualifying rounds.