LLM Platform Vulnerabilities: IDOR, BOLA, GPU Leaks, and the Seven Attack Classes That Bypass Prompt Security

The LLM application layer has a new attack surface that most security teams are not monitoring. IDOR and BOLA vulnerabilities let authenticated users read other tenants' chat histories. GPU memory leaks expose cross-tenant inference data. OAuth redirect bypasses steal authentication tokens. Decompression bombs crash inference servers. PostMessage confirmation bypasses let attacker pages execute actions as the victim. Seven platform-level vulnerability classes, backed by 30+ real security advisories from Open WebUI, vLLM, and Langflow, are the threat that prompt injection defenses were never designed to catch.

Why LLM platform vulnerabilities are a different problem

Most LLM security content focuses on what goes into and comes out of the model: prompt injection, context poisoning, output exfiltration. Those are real threats, and Context Guard defends against them. But there is a second threat surface that receives far less attention: the platform the model runs on.

LLM platforms are web applications. They have APIs, authentication systems, multi-tenant data stores, file upload endpoints, OAuth flows, and session management. They have all the vulnerabilities that web applications have always had. The difference is that a compromised LLM platform does not just leak a database row. It leaks every conversation every user has ever had with the model, every custom system prompt, every uploaded document, every agent configuration. The blast radius is the entire knowledge base, not a single record.

In 2026 alone, Open WebUI has disclosed 29 security advisories covering IDOR, BOLA, stored XSS, OAuth SSRF, postMessage bypass, path traversal, LDAP authentication bypass, and unauthorized API access. vLLM has disclosed advisories for GPU memory leaks, audio decompression bombs, SSRF, and dependency confusion. Langflow has disclosed advisories for IDOR, BOLA, unauthenticated RCE, and path traversal. These are not theoretical. They are assigned GHSA IDs with working proofs of concept.

The common thread: none of these vulnerabilities are caught by prompt injection detection. They exist at the platform layer, below the model, in the application code that hosts it. A defense that only inspects prompts will miss every one of them.

Seven platform vulnerability classes

1. IDOR and BOLA: accessing other users' data

Insecure Direct Object Reference (IDOR) and Broken Object Level Authorization (BOLA) are the most common vulnerability class in LLM platforms. The attack is simple: an authenticated user changes a chat ID, file ID, or user ID in an API request and gains access to another user's data without authorization checks.

Open WebUI has disclosed multiple IDOR and BOLA vulnerabilities in 2026. GHSA-4r4w-2wgp-w7cj documented that prompt version-history endpoints authorize the prompt_id in the URL but then act on caller-supplied history_id values without verifying that the history row belongs to that prompt. An attacker could read and delete any user's prompt history by iterating history IDs.

GHSA-vrhc-3fr6-pc3c showed that an authenticated user could attach arbitrary file_id values to their own chat message without checking whether they own or can read those files. By then sharing the chat and granting themselves read access, the platform's has_access_to_file() function treated the victim's file as accessible, allowing the attacker to read or delete it.

GHSA-f3g7-59qc-pqg6 revealed that calendar event endpoints validated write access to the calendar an event currently belonged to but did not validate the destination calendar_id supplied in the request body, allowing users to re-parent events into other users' calendars.

GHSA-wch8-mhj5-9frg demonstrated that the /api/chat/completions endpoint accepts an image_url.url value that, when it does not start with http://, https://, or data:image/, is interpreted as a file ID and resolved against the global file table with no ownership check.

On the Langflow side, GHSA-qrpv-q767-xqq2 (rated critical) disclosed that the /api/v1/responses endpoint allowed any authenticated user to execute another user's flow by specifying the victim's flow ID. The get_flow_by_id_or_endpoint_name helper function queries the database directly by UUID without checking whether the authenticated user owns that flow. GHSA-9c59-2mvc-vfr8 (rated high) found that 7 monitor API endpoints performed read, write, and delete operations on user-owned resources without verifying ownership.

# Langflow IDOR: Attacker executes victim's flow
# src/backend/base/langflow/helpers/flow.py:399-414
async def get_flow_by_id_or_endpoint_name(flow_id_or_name, user_id=None):
    async with session_scope() as session:
        try:
            flow_id = UUID(flow_id_or_name)
            # When using UUID, query directly WITHOUT checking user_id
            flow = await session.get(Flow, flow_id)  # No ownership check!
        except ValueError:
            # Only when using endpoint_name is user_id checked
            stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)
            if user_id:
                stmt = stmt.where(Flow.user_id == uuid_user_id)

# Attacker with API_KEY_A executes victim (user B)'s flow:
curl -X POST "http://target:7860/api/v1/responses" \
  -H "x-api-key: sk-ATTACKER_API_KEY" \
  -d '{"model": "VICTIM_FLOW_ID", "input_value": "exfil data"}'

The IDs are often UUIDs, which provides some obscurity but no security. UUIDs appear in URLs, API responses, log entries, and error messages. And even when UUIDs are not guessable, the API may accept sequential integer IDs as well, as Langflow's monitor endpoints demonstrated.

Detection: llm_platform_idor_bola (high) detects attempts to iterate through user IDs, file IDs, or session IDs to access other users' data. llm_platform_idor (high) catches IDOR-specific patterns referencing Langflow and other platforms. Both are mapped to OWASP LLM06.

2. Unauthorized API access and data enumeration

Closely related to IDOR but distinct: platforms that expose API endpoints without proper authentication or authorization. The difference is that IDOR exploits a broken access control on an authenticated endpoint, while unauthorized API access exploits endpoints that require no authentication at all, or that fail open when authentication is missing.

GHSA-65pg-qhhw-mxwg disclosed that Open WebUI's RAG configuration endpoint was accessible without authentication, allowing anyone to read the platform's retrieval-augmented generation configuration. GHSA-6c2x-gcp3-gp73 showed that knowledge base meta-collection enumeration was accessible without authorization, exposing the existence and names of all knowledge bases on the platform.

GHSA-cx9v-4qj2-jrw6 documented a BOLA vulnerability in the built-in search_knowledge_files tool: when native function calling was enabled and the selected model had no attached knowledge bases, an authenticated user could call search_knowledge_files with an arbitrary collection name, searching any knowledge base on the platform regardless of ownership.

GHSA-7r82-qhg4-6wvj (rated high) revealed that the /api/v1/retrieval/process/web endpoint accepted a user-supplied collection_name and an overwrite parameter defaulting to True. With no authorization check on whether the calling user owned the target collection, an attacker could overwrite any knowledge base on the platform with attacker-controlled content, achieving both data destruction and RAG poisoning.

The attack is devastating in multi-tenant deployments. A SaaS LLM platform that hosts conversations for multiple organizations is giving any authenticated user a path to every other tenant's data. The knowledge base that contains your proprietary documents is one API call away from enumeration, exfiltration, or destruction.

Detection: llm_platform_api_unauthorized_access (high) detects attempts to access, enumerate, or download data through LLM platform API endpoints without proper authorization. Mapped to OWASP LLM06.

3. GPU memory leaks and cross-tenant data extraction

In multi-tenant LLM serving environments, GPU memory is shared across tenants. When one tenant's inference request completes, the GPU memory that held their data should be cleared before the next tenant's request is processed. GHSA-5jv2-g5wq-cmr4 showed that this does not always happen.

The vulnerability is an integer truncation bug in vLLM's GGUF dequantize kernels. The to_cuda_ggml_t function pointer type declares its element count parameter as int (32-bit), but the caller passes m * n as an int64_t product. When m * n exceeds INT_MAX, the truncated value is smaller than the actual tensor size. The CUDA kernel processes only the truncated number of elements. The remaining elements in the output tensor are never written and contain stale GPU memory from a previous tenant's inference request.

// vLLM GGUF dequantize kernel: integer truncation exposes GPU memory
// ggml-common.h:1067 — 32-bit element count parameter
using to_cuda_ggml_t = void (*)(const void* __restrict__ x,
                                dst_t* __restrict__ y,
                                int k,              // 32-bit!
                                cudaStream_t stream);

// gguf_kernel.cu:80-85 — full-size allocation, truncated processing
at::Tensor DW = torch::empty({m, n}, options);  // UNINITIALIZED memory
// ...
to_cuda((void*)W.data_ptr(), (scalar_t*)DW.data_ptr(), m * n, stream);
// m*n truncated from int64_t to int: elements beyond INT_MAX
// retain data from previous tenant's inference request

In multi-tenant inference deployments, the residual GPU memory may contain tensor data from other users' inference requests, including prompt text, system configurations, and uploaded document content. This constitutes cross-tenant information disclosure at the hardware level.

Detection: gpu_memory_leak_malformed_model (high) detects attempts to exploit GPU memory leaks through malformed model files or integer truncation. gpu_memory_leak_exploitation (high) catches the pattern of repeatedly loading and unloading models to accumulate leaked memory. Both are mapped to OWASP LLM06.

4. OAuth redirect bypass and SSRF

LLM platforms that support OAuth login have a particularly dangerous attack surface: the OAuth redirect flow. If the redirect URL is not properly validated, an attacker can manipulate the flow to steal authentication tokens.

GHSA-226f-f24g-524w (rated high) disclosed that Open WebUI's _process_picture_url function calls validate_url() on the initial URL but then invokes aiohttp.ClientSession.get() without allow_redirects=False. aiohttp's default is allow_redirects=True with max_redirects=10. An attacker with a valid OAuth IdP identity can submit a public URL that 302-redirects to an internal network address, achieving SSRF past the URL validation layer.

This is an incomplete fix sibling of CVE-2026-45401, which previously addressed OAuth SSRF in the same component. The fix validated the initial URL but forgot to block redirects to internal addresses after the initial validation passed. This pattern, where a security fix addresses the obvious attack vector but leaves an equivalent bypass through a related path, is common in LLM platform security.

# Open WebUI OAuth SSRF: validates initial URL but follows redirects
# backend/open_webui/utils/oauth.py:1435-1470

async def _process_picture_url(picture_url: str) -> Optional[str]:
    # Validates the INITIAL URL only
    if not validate_url(picture_url):  # checks scheme, domain, etc.
        return None
    
    # But then follows up to 10 redirects without re-validating!
    async with aiohttp.ClientSession() as session:
        resp = await session.get(picture_url)
        # aiohttp default: allow_redirects=True, max_redirects=10
        # Attacker URL: https://evil.com/redirect -> http://169.254.169.254/...
        # validate_url() passes on https://evil.com/redirect
        # aiohttp follows the 302 to http://169.254.169.254/ (internal AWS metadata)

Detection: oauth_ssrf_redirect_token_exfiltration (high) detects OAuth callback manipulation, double URL-encoding bypasses, and profile picture URL SSRF. Mapped to OWASP LLM06.

5. PostMessage confirmation bypass

Modern LLM chat UIs are single-page applications that communicate with iframes and popup windows using the browser's postMessage API. When an LLM agent requests user confirmation before executing a tool call, the UI sends a postMessage to the parent window. If the message origin is not validated, an attacker-controlled page can forge confirmation messages, bypassing the user's explicit approval gate.

GHSA-3vv5-8xxp-4f55 (rated high) documented exactly this vulnerability in Open WebUI. The chat page's window message listener in Chat.svelte processes input:prompt and action:submit message types without enforcing same-origin restrictions. An attacker-controlled page can set prompt text via input:prompt and then immediately trigger action:submit, causing unauthorized POST /api/v1/chats/new and POST /api/chat/completions requests under victim credentials.

Normally, the input:prompt:submit message type shows a "Confirm Prompt from Embed" confirmation dialog. But by combining the two other types, input:prompt followed by action:submit, the attacker achieves the same effect without any confirmation.

// Attacker-controlled page sends forged confirmation
// No confirmation dialog required
const iframe = document.getElementById('open-webui-iframe');
iframe.contentWindow.postMessage({
  type: 'input:prompt',
  text: 'Delete all files in /important-directory'
}, '*');  // '*' accepts from any origin

iframe.contentWindow.postMessage({
  type: 'action:submit'
}, '*');

// Open WebUI processes the forged messages and sends:
// POST /api/v1/chats/new
// POST /api/chat/completions
// Under the victim's authenticated session, with no user confirmation

The attack bypasses the tool-call confirmation gate that most agent frameworks implement. The user thinks they are approving a tool call by clicking a button in the UI. The attacker's page submits the confirmation automatically, and the agent proceeds to execute the action, whether that is sending an email, making a payment, or deleting a file.

Detection: postmessage_confirmation_bypass (high) detects cross-origin postMessage confirmation bypass patterns. Mapped to OWASP LLM06.

6. Resource decompression bombs

LLM inference servers accept file uploads for processing: audio for transcription, images for vision, documents for summarization. Most platforms enforce size limits on uploads. But a compressed file can be tiny on disk and enormous when decompressed. A 25MB OPUS audio file expands to 14.9GB of float32 PCM data. A small GGUF model file contains tensors that consume gigabytes of GPU memory when loaded.

GHSA-6pr9-rp53-2pmc demonstrated that vLLM's /v1/audio/transcriptions endpoint rejects uploads over VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB) based on compressed byte length, but the audio decoder accumulates all decoded frames into memory with no size limit before returning. A 25MB OPUS file at 6kbps encodes approximately 8.7 hours of audio. Decoding produces approximately 5.7GB of float32 PCM (232x amplification), and np.concatenate then allocates a second contiguous array, bringing peak RSS to approximately 14.9GB from a single request.

# vLLM audio decompression: 25MB compressed -> 14.9GB decompressed
# speech_to_text.py:184-189
if len(audio_data) / 1024 ** 2 > self.max_audio_filesize_mb:
    raise VLLMValidationError(...)  # Checks COMPRESSED size only
y, sr = load_audio(buf, sr=self.asr_config.sample_rate)  # Decoded size UNCHECKED

# audio.py:77-107 — accumulates ALL decoded frames in memory
chunks: list[npt.NDArray] = []
for frame in container.decode(stream):
    chunks.append(frame.to_ndarray())
audio = np.concatenate(chunks, axis=-1).astype(np.float32)
# 25MB OPUS -> 5.7GB float32 PCM -> 14.9GB peak RSS from one request

The impact goes beyond simple DoS. In multi-tenant environments, a decompression bomb that crashes the inference server can cause cascading failures that affect all tenants. And as we saw in the GPU memory leak section, a crashed and restarted worker may not properly zero its memory, creating a path for cross-tenant data extraction. An unauthenticated attacker can exhaust server memory with a small number of concurrent requests, each a valid upload within the documented size limit.

Detection: resource_decompression_bomb (high) detects crafted compressed uploads designed to crash LLM inference endpoints through OOM. llm_platform_unbounded_dos (high) catches unbounded request and response attacks. Both are mapped to OWASP LLM06.

7. Stored XSS, metadata manipulation, and authentication bypass

LLM platforms store and render user-generated content: chat messages, file names, knowledge base titles, agent configurations, model profile images, and tool descriptions. Any of these fields can contain HTML or JavaScript that the platform renders without proper sanitization. When a victim user's browser renders the malicious content, the script executes in the context of the LLM platform's session.

Open WebUI has disclosed multiple stored XSS vulnerabilities in 2026:

• GHSA-v2qm-5wxj-qhj7 (high): stored XSS via model profile images. Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to model profile images. The ModelMeta class has no validate_profile_image_url field validator, allowing an attacker to store a JavaScript payload that executes when any user views the model.
• GHSA-m8f9-9whg-f4xr (high): stored XSS via attacker-controlled file extension in /api/v1/audio/transcriptions. By uploading a file with a crafted extension containing JavaScript, the attacker achieves XSS in the transcription result page.
• GHSA-hcwp-82g6-8wxc (medium): stored XSS via unsanitized Office/Excel/DOCX file preview rendering using {@html} without DOMPurify.
• GHSA-v8qj-hxv7-mgvv (high): stored XSS in Mermaid markdown preview rendering.

Stored XSS in an LLM platform is particularly dangerous because the attacker can:

• Steal session tokens from other users who view the malicious content, gaining full account access.
• Send postMessage events to the chat UI, bypassing tool-call confirmation gates as described in the postMessage bypass section.
• Forge API requests on behalf of the victim, creating conversations, uploading files, or modifying knowledge bases.
• Inject prompt instructions into the rendered page that the LLM processes when it reads the chat context.

A related attack manipulates model metadata to access other users' data. GHSA-vjqm-6gcc-62cr (high) showed that Open WebUI lets users store arbitrary meta.knowledge entries on their model without checking whether they own the referenced files. Open WebUI then treats those meta.knowledge entries as an authorization source, allowing the model owner to read or delete any file on the platform by referencing it in their model's metadata.

The most severe authentication vulnerability is GHSA-2r4p-jpmg-48f4 (critical): LDAP empty password authentication bypass. Open WebUI's LDAP authentication endpoint does not validate that the submitted password is non-empty before performing a Simple Bind. Per RFC 4513 Section 5.1.2, a Simple Bind with a valid DN and an empty password constitutes "unauthenticated simple authentication," and many LDAP servers return success for this operation. The LdapForm Pydantic model accepts password: str with no minimum length constraint, so an empty string passes validation and the application issues a full session token for the target user.

# Open WebUI LDAP bypass: empty password = full session token
# backend/open_webui/models/auths.py:58-60
class LdapForm(BaseModel):
    user: str
    password: str  # No min_length constraint! Empty string passes validation

# backend/open_webui/routers/auths.py:468-477
connection_user = Connection(
    server,
    user_dn,
    form_data.password,    # Can be "" — RFC 4513 unauthenticated bind
    auto_bind='NONE',
    authentication='SIMPLE',
)
# OpenLDAP default config: empty password = successful bind
# Application issues full session token for target user

Detection: llm_output_xss_stored (high) detects stored XSS patterns in LLM outputs and platform-rendered content. forged_model_metadata_cross_user (high) catches manipulation of model metadata to access other users' data. metadata_filter_sql_injection (critical) detects SQL injection through LLM metadata filters. All mapped to OWASP LLM06.

Why prompt security alone does not help

Every vulnerability in this post exists below the model layer. The model never sees the IDOR request. The model never sees the OAuth redirect. The model never sees the GPU memory that was not zeroed. The model never sees the postMessage event. These are application-level vulnerabilities in the platform that hosts the model, and they bypass every prompt injection detection rule.

This is the gap that most AI security content does not address. Prompt injection defenses are necessary but not sufficient. A complete LLM security posture requires:

1. Input and output inspection for prompt injection, context poisoning, and exfiltration (the layer Context Guard primarily operates at).
2. Application security for the platform that hosts the model: IDOR protections, authorization checks, input validation, XSS prevention, OAuth hardening.
3. Infrastructure security for the serving layer: GPU memory isolation, decompression limits, request size caps, worker process isolation.

Missing any one of these layers leaves a gap that an attacker can exploit. The prompt injection layer gets the most attention because it is the newest and most novel. But the application and infrastructure layers are where the CVEs are, and those CVEs have the most direct impact on multi-tenant data security.

Consider the numbers: Open WebUI alone has disclosed 29 security advisories in 2026. Of those, more than half are IDOR, BOLA, or unauthorized access vulnerabilities that operate entirely at the platform layer. No prompt filter catches them. No context window inspection detects them. They are web application vulnerabilities in a system that happens to host an LLM, and they require web application security controls.

The platform defense architecture

1. Authorization and access controls

Every API endpoint that serves user-specific data must enforce authorization at the object level, not just at the endpoint level. This means:

• Object-level authorization: every request to access a chat, file, knowledge base, or agent configuration must verify that the requesting user owns or has explicit access to that object. Langflow's monitor API demonstrated that having the correct pattern in one endpoint does not help if seven others omit it.
• UUIDs are not access control: use UUIDs for uniqueness, not for security. A UUID in a URL does not prevent enumeration. Add authorization checks on every endpoint.
• Anti-enumeration controls: rate-limit API requests per user. If a single user makes 100 requests to /api/v1/chats/ with sequential IDs, that is an enumeration attack. Block it.
• Metadata authorization: verify that users own the resources referenced in their model metadata, knowledge base references, and file IDs. Forging metadata to access another user's data should be impossible.
• Collection-level authorization: knowledge base operations must verify that the calling user owns or has explicit access to the target collection. The overwrite parameter on retrieval endpoints should never default to True for collections the user does not own.

2. OAuth and authentication hardening

• Whitelist redirect URLs. The OAuth callback endpoint should only accept redirect URLs that match an exact whitelist. No wildcards. No regex matching. No double-encoding bypasses. Open WebUI's _process_picture_url validated the initial URL but followed redirects to internal addresses.
• Block redirects after URL validation. Any URL the server fetches on behalf of a user must use allow_redirects=False or equivalent. Validate the final destination, not just the initial URL.
• Validate profile picture URLs. Any URL the server fetches must be validated against a domain allowlist. No internal network URLs. No arbitrary external URLs.
• Enforce postMessage origin validation. Every postMessage event received by the chat UI must validate the origin of the message. Accept only messages from the platform's own origin. Never accept "*" as the target origin.
• Validate authentication credentials. LDAP binds must reject empty passwords. OAuth flows must use the state parameter bound to the user's session. Any authentication endpoint must verify the credential is non-empty before processing.

3. GPU memory and resource isolation

• Use 64-bit element counts in GPU kernels. vLLM's integer truncation bug (GHSA-5jv2-g5wq-cmr4) happened because a 32-bit int parameter truncated a 64-bit m * n product. All GPU kernel element counts must be int64_t or size_t.
• Zero GPU memory between tenants. When a tenant's inference request completes, zero the GPU buffers before the next tenant's request is allocated. This is a performance cost, but it eliminates the cross-tenant data leakage path.
• Enforce decompression limits. Set maximum uncompressed size limits on all file uploads. A 25MB OPUS file should not expand to 14.9GB of float32 PCM data without explicit approval. vLLM's SpeechToTextConfig.max_audio_clip_s applied only after the full decode.
• Isolate inference workers. In multi-tenant deployments, run each tenant's inference on isolated workers with separate GPU allocations. A crash in one tenant's worker should not affect other tenants.

4. Input validation and XSS prevention

Every field that accepts user input in an LLM platform is a potential XSS vector. Open WebUI's 2026 advisories show that stored XSS was found in user profile images, webhook profile images, model profile images, audio transcription file extensions, Office/Excel/DOCX file previews, and Mermaid markdown rendering. The lesson is clear: if a field accepts user input and the platform renders it anywhere, it must be sanitized.

• Sanitize all user-generated HTML before rendering. Use a strict allowlist of tags and attributes. Strip script, iframe, form, onerror, onload, and all event handler attributes.
• Apply sanitization consistently. Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot model profile images. Every rendering surface must be covered, not just the obvious ones.
• Content Security Policy headers on every page that renders user content. This provides defense in depth even if the sanitization layer misses an XSS vector.
• Parameterize database queries. The metadata_filter_sql_injection detection rule exists because metadata filter parameters allowed SQL injection in LangChain4j and pgvector. Use parameterized queries for every database operation.

5. Monitoring, logging, and incident response

• Log API access patterns. Track which users access which objects, how often, and from where. Anomalous access patterns (sequential ID enumeration, cross-tenant data access, burst API calls) should trigger alerts.
• Log OAuth flows. Every OAuth callback, redirect, and token exchange should be logged with the full URL, including redirect_uri parameters.
• Monitor GPU memory allocation. Track model load/unload cycles, memory allocation patterns, and buffer reuse. Repeated allocation without zeroing is a security signal.
• Monitor postMessage origins. Log the origin of every postMessage event received by the chat UI. Cross-origin messages should be flagged and reviewed.
• Incident response. Have a plan for revoking compromised OAuth tokens, freezing user accounts, and isolating affected workers. The speed of response determines the blast radius.

How Context Guard detects platform attacks

Context Guard's detection pipeline includes rules for the input-side manifestations of platform vulnerabilities: prompts that attempt IDOR, BOLA, unauthorized API access, OAuth bypass, and postMessage confirmation bypass. These rules catch attackers who try to exploit platform vulnerabilities through the LLM interface itself.

Detection rules for LLM platform vulnerabilities:

• llm_platform_idor_bola (high) , IDOR/BOLA cross-user data access attempts
• llm_platform_idor (high) , IDOR accessing other users' resources
• llm_platform_api_unauthorized_access (high) , unauthorized API access for data exfiltration
• gpu_memory_leak_malformed_model (high) , GPU memory leak via malformed model files
• gpu_memory_leak_exploitation (high) , GPU memory leak exploitation for cross-tenant data extraction
• oauth_ssrf_redirect_token_exfiltration (high) , OAuth/SSRF redirect bypass token exfiltration
• postmessage_confirmation_bypass (high) , cross-origin postMessage confirmation bypass
• resource_decompression_bomb (high) , decompression bomb attacks on inference endpoints
• llm_platform_unbounded_dos (high) , unbounded request/response DoS attacks
• forged_model_metadata_cross_user (high) , forged model metadata for cross-user data access
• metadata_filter_sql_injection (critical) , SQL injection through LLM metadata filters
• llm_output_xss_stored (high) , stored XSS in LLM outputs and platform content

These platform vulnerability rules join the broader detection library covering prompt injection, context poisoning, output exfiltration, and MCP attacks. Every rule carries an OWASP reference so your compliance team can include platform vulnerabilities in their coverage reports.

LLM platform security checklist

Before deploying an LLM platform to production, verify every item on this list:

• Every API endpoint that serves user-specific data enforces object-level authorization, not just endpoint-level authentication.
• UUIDs are used for uniqueness, not security. Object IDs are validated against the requesting user's ownership.
• API enumeration is rate-limited and monitored. Sequential ID access patterns trigger alerts.
• OAuth redirect URLs are whitelisted exactly. No wildcards, no regex matching, no double-encoding bypasses. Server-side URL fetching uses allow_redirects=False.
• Profile picture URLs and external fetches are validated against a domain allowlist. No SSRF to internal services.
• postMessage origin validation is enforced on every cross-origin message. Confirmation gates cannot be bypassed by external pages.
• GPU memory is zeroed between tenant inference requests. Kernel element counts use 64-bit integers. Model load/unload cycles are monitored for exploitation patterns.
• File upload decompression limits are enforced. Maximum uncompressed size caps prevent OOM crashes.
• All user-generated content is sanitized before rendering, including model profile images, file extensions, and markdown previews. Content Security Policy headers are set on every page.
• Database queries are parameterized. Metadata filters and search parameters do not accept raw SQL.
• Model metadata is validated against the requesting user's ownership. Forged metadata cannot reference other users' resources.
• Authentication endpoints validate that credentials are non-empty before processing. LDAP binds reject empty passwords.
• Knowledge base operations verify collection ownership before overwrite or deletion. The overwrite parameter defaults to False.
• Every detection event is logged with a stable request ID, matched rules, risk score, and verdict.

If any of these are missing from your LLM platform deployment, you have a platform-level vulnerability that prompt injection defenses will not catch. The security page has the full architecture. The free trial has the product.