LLM08: Vector and Embedding Weaknesses
Vector DB misconfiguration: cross-tenant leakage, unauthenticated retrieval, embedding inversion.
Last reviewed October 2026
Why LLM08 evidence is hard
Retrieval brings its own tenancy problem: a vector store that answers any authenticated caller, an index where one customer's chunks sit beside another's, an embedding invertible back toward its source text. The probe library does not reach this one - the 17 templates carrying LLM08 are agent-permission tests left from the 2023 numbering. What does reach it is the separate RAG security scan, which queries the retriever the way an attacker would, with the retriever URL validated at the console and again at the worker before anything is fetched.
How Penaxtra maps to LLM08
The LLM08 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
LLM08 capabilities
Findings tagged with the OWASP LLM Top 10 LLM08 identifier
Penaxtra severity for this control (high)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
LLM08 control coverage
Findings for LLM08 carry the OWASP LLM Top 10 LLM08 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is LLM08 (Vector and Embedding Weaknesses)?
Vector DB misconfiguration: cross-tenant leakage, unauthenticated retrieval, embedding inversion. It is an OWASP LLM Top 10 control; Penaxtra assesses it at high severity.
How does Penaxtra test for LLM08?
The LLM08 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for LLM08 help with an audit?
Each finding is tagged with the OWASP LLM Top 10 LLM08 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.