A defender briefing for teams that self-host models: what is reachable without credentials, and what belongs in your pentest scope.
Self-hosting models adds an HTTP service to the estate. It holds GPU memory, API keys, system prompts and other users' in-flight conversations, but architecturally it is a web listener with a JSON API and, in several popular products, no authentication of its own. Most inventories file it under "AI infrastructure," and it never reaches the perimeter scope document.
No vendor named in this post was compromised, and no primary source cited here claims in-the-wild exploitation. This is a patching and network-placement problem: an authentication bypass in NVIDIA Triton, an information leak in vLLM that chains into memory corruption in a dependency, an out-of-bounds read in Ollama that exfiltrates as an ordinary model publish, and an integer-overflow class in GGUF parsing that bypassed its own prior fix.
The serving tier is ordinary attack surface with an extraordinary blast radius
First, classification, because 2026 filed structurally different events under one headline:
Category | What it means |
|---|---|
A. Jailbreak or safety bypass | A guardrail defeated by prompting. No system was accessed. |
B. Platform misuse | An external attacker used an AI product against third parties. |
C. Product vulnerability | A flaw in shipped software, with a fix and a version floor. |
D. Corporate breach | The vendor's own systems, data or network were compromised. |
E. Model-initiated action during evaluation | The vendor's own model, in an authorised evaluation with no attacker involved, acted against a real third party. A through D do not fit. |
Everything here is Category C. Nothing is a Category D corporate breach, and nothing is E. A C generates a patch ticket and a scope change, not a vendor-risk escalation or a customer notification.
C on the serving tier earns priority through blast radius: the process answering inference requests holds credentials for a model registry, an object store and a vector database, the system prompts encoding your product logic, and every session's working memory. A read primitive is a credential-disclosure event; a write primitive is a foothold on a GPU host. More in our AI attack surface analysis for 2026.
NVIDIA Triton CVE-2026-24207: an authentication bypass, and what "might lead to code execution" means when the vendor writes it
Category C. NVIDIA Triton Inference Server contains a flaw where an attacker could cause an authentication bypass, and a successful exploit "might lead to" code execution, escalation of privileges, data tampering, denial of service or information disclosure (NVD). Published 20 May 2026, CWE-288.
The 9.8 Critical figure is NVIDIA's, not NVD's. The record's only CVSS block comes from psirt@nvidia.com, typed Secondary, on CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, with no NVD primary. NVIDIA is the CNA here, so use that number but record whose it is. The conditional stays too: "might lead to code execution" is not "unauthenticated remote code execution." Unconditional is the authentication bypass, on a service that ships without authentication.
The same NVD publication date covers three siblings, all before 26.03 per NVD's product data and each stated as possibly leading to denial of service.
CVE | Weakness | Score and source |
|---|---|---|
CVE-2026-24209 | CWE-22 path traversal | 7.5 High, NVIDIA secondary; no NVD primary |
CVE-2026-24210 | CWE-190 integer overflow | 7.5 High, NVIDIA secondary; no NVD primary |
CVE-2026-24215 | CWE-400 resource consumption, DALI backend | NVD primary 7.5 High on |
CVE-2026-24215 is where the authorities disagree. NVIDIA's vector requires low privileges and user interaction; NVD's requires neither, a spread driven by whether an anonymous client can reach the DALI backend. NVD holds the primary score and NVIDIA is the vendor CNA; print both and let your deployment posture break the tie.
NVIDIA's deployment guidance is the useful defender text: Triton is meant to sit inside a larger framework or service mesh, not exposed directly to an untrusted network, and solution security is the deployer's responsibility. It warns that dynamic model-repository updates "can lead to arbitrary code execution," recommending --model-control-mode set to none unless required (NVIDIA Triton deployment guide).
vLLM CVE-2026-22778: an error message that leaks a heap address, and a chain that crosses a dependency boundary
Category C. Two primary records describe different halves of one chain.
NVD covers the leak: from 0.8.3 to before 0.14.1, an invalid image sent to vLLM's multimodal endpoint causes PIL to raise an error, vLLM returns that error to the client, and the response leaks a heap address, reducing ASLR from roughly four billion guesses to about eight. The description ends by stating this can be chained with a heap overflow in the JPEG2000 decoder in OpenCV and FFmpeg to achieve remote code execution, fixed in 0.14.1 (NVD). The GitHub advisory covers the other half, titled for remote code execution in video processing and locating the overflow in OpenCV's bundled FFmpeg (GHSA-4r2x-xpjr-7cvv).
The information leak is vLLM's bug. The memory corruption is not. vLLM's advisory carries CWE-122 heap-based buffer overflow alongside CWE-209 and CWE-532, while NVD's record lists only the two information-exposure classes. Upgrading to 0.14.1 removes the leak primitive that makes the overflow practical, and says nothing about other services in your estate decoding media through the same native stack.
Both CVSS blocks in NVD read 9.8 Critical, both typed Secondary, with no NVD primary. Neither description exempts text-only deployments, so use the multimodal entry point to prioritise, not to exclude.
Ollama CVE-2026-7482: an out-of-bounds read that leaves the network as a legitimate model push
Category C. Ollama before 0.17.1 contains a heap out-of-bounds read in the GGUF model loader. Per NVD, the /api/create endpoint accepts an attacker-supplied GGUF file whose declared tensor offset and size exceed the file's actual length, and during quantization the server reads past the allocated heap buffer. The leaked memory may include environment variables, API keys, system prompts and concurrent users' conversation data, and can be exfiltrated by uploading the resulting model artifact through /api/push to an attacker-controlled registry (NVD). Published 4 May 2026, CWE-125.
The exfiltration channel is a legitimate product feature. The stolen memory leaves as a model publish, which an Ollama host is supposed to do sometimes. Detection turns on destination and timing: a push to a registry not on your allowlist, or any push from an inference-only host.
Both scores are the CNA's, and they disagree with each other. NVD carries a CVSS 4.0 base of 8.8 High and a CVSS 3.1 base of 9.1 Critical, both typed Secondary from the same assigning source, with no NVD primary. If your process escalates on "Critical," the newer standard puts the same flaw one band lower.
There is no Ollama vendor advisory. The CVE was CNA-assigned and the fix artefacts are the record: commit 88d57d0, pull request #14406, release v0.17.1 (NVD; GHSA-x8qc-fggm-mpqg). If your process waits for a vendor bulletin, this is the case that breaks it.
Model files are untrusted input: llama.cpp GGUF, and a bug class that has now been fixed twice
Category C. A GGUF file is not inert data. Its header, metadata and tensor descriptors are parsed by native code doing pointer arithmetic and heap allocation against numbers taken from the file.
That class has been closed twice in the same file and returned once. CVE-2026-27940, published 12 March 2026, is an integer overflow in gguf_init_from_file_impl() in gguf.cpp leading to an undersized heap allocation, and NVD states outright that it is a bypass of a similar bug in the same file, CVE-2025-53630, whose fix "overlooked some areas." It is fixed in build b8146 (NVD; GHSA-3p4r-fq3f-q74v). A second flaw, CVE-2026-33298, overflows the tensor-size calculation in ggml_nbytes(), and is fixed in build b7824 (GHSA-96jg-mvhq-q7q7). Both carry CWE-190 and CWE-122 and both are scored 7.8 High by the GitHub CNA, again with no NVD primary.
Read the vectors side by side. The llama.cpp flaws are AV:L/AC:L/PR:N/UI:R: local, where the "interaction" is loading a model. The Ollama loader flaw is AV:N/.../UI:N: only reaching the port is required. Model provenance is the control for the first shape; network placement for the second. More on the parser class in one malicious GGUF file can own your local LLM.
What is actually exposed: default binds, documented 0.0.0.0 deployments, and why download counts are not exposure counts
Ollama. NVD states that /api/create and /api/push have no authentication in the upstream distribution, that default deployments bind to 127.0.0.1, and that the documented OLLAMA_HOST=0.0.0.0 configuration is widely used in practice, closing with the qualitative parenthetical "(large public-internet exposure observed)" (NVD). The safe default exists; the documented override that removes it is common.
vLLM. The project's own security documentation states that --api-key protects only the OpenAI-compatible endpoints under the /v1 path prefix and similar paths, while many other sensitive endpoints sit on the same HTTP server without any authentication enforcement. Multi-node communication is insecure by default, TCP initialization has PyTorch create a store that by default listens on all network interfaces, and the recommended posture is an isolated network behind a reverse proxy that allowlists only the endpoints you want to expose (vLLM security documentation).
Then the negative finding: no primary source in this cluster enumerates how many instances are exposed or vulnerable, and NVD's parenthetical is an observation, not a count. Download counts measure adoption, not exposure. The only number governing your remediation is the one you produce: how many inference listeners you run, what each binds to, and what version it is on.
Detection and remediation: version floors, network placement, authentication in front of endpoints that ship without it, and model provenance
The patch ticket is four numbers.
Component | CVE | Category | Version floor | Notes |
|---|---|---|---|---|
NVIDIA Triton Inference Server | CVE-2026-24207, -24209, -24210, -24215 | C | 26.03 or later | Range from NVD product data. Scores are NVIDIA's except -24215. |
vLLM | CVE-2026-22778 | C | 0.14.1 or later | Affected 0.8.3 to before 0.14.1. Removes the leak half of the chain. |
Ollama | CVE-2026-7482 | C | 0.17.1 or later | No vendor advisory; fix artefacts are commit 88d57d0, PR #14406, v0.17.1. |
llama.cpp and ggml | CVE-2026-27940, CVE-2026-33298 | C | build b8146 or later | Later than b7824, so it clears both. Track the build vendored inside tools. |
Five controls that survive the next disclosure:
Put the serving port where an anonymous client cannot reach it. Bind to loopback or an internal interface and put authenticated ingress in front; NVIDIA and vLLM both say a version of this themselves.
Authenticate at a layer that covers every path. A proxy that allowlists intended endpoints, not a flag covering one path prefix.
Turn off dynamic model loading unless you need it, and restrict model-repository writes to trusted identities.
Treat model files like unsigned binaries. Verify publisher and checksum before a file reaches a parser, and parse untrusted files in a constrained process with no egress.
Instrument the model-management path, not just the inference path. Alert on
/api/createcalls from a source with no business creating models, pushes to a registry not on your allowlist, and inference processes making new outbound connections.
What a pentest should now cover: the serving tier, the model-file supply chain, and the GPU multi-tenancy boundary
Most AI-application scopes stop at the chat interface and the API in front of it; these CVEs sit behind that line.
The serving tier as a normal web target. Enumerate every listener on every inference host and test it as an unauthenticated web service. The question is not "is the API key set" but "does the thing enforcing authentication cover every path on that port." Include management endpoints, the metrics endpoint, the gRPC port and any inter-node channel.
The model-file supply chain. Test how a model artifact reaches a serving host from a public hub or a fine-tuning job: who can publish, what is verified before parsing, and whether parsing is isolated from credentials.
The GPU multi-tenancy boundary. Where teams, tenants or models share a serving host, test whether one tenant's requests can influence another's, whether system prompts and keys are readable from the shared process, and whether one tenant's model-management actions reach the others. On managed infrastructure, our guide to AWS Bedrock and AI infrastructure penetration testing covers the cloud-side equivalent.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing service provider at firm level, founded in 2021 with teams in Toronto and London, with individual testers holding CREST CRT. Our team has 18 published CVEs and holds 5.0 out of 5.0 across 19 Clutch reviews.
Serving-tier and model-supply-chain testing is human-led offensive security: our senior pentesters map every inference listener, test authentication against every path rather than the documented ones, and probe the tenancy boundary on shared GPU hosts, the same discipline behind our red teaming practice. Our autonomous agent Snipe covers the application and API around the model: scoped to web application penetration testing, hunting the classes generic scanners miss, IDOR, broken authorization and business logic flaws. Both feed the same PTaaS program.
Web-app engagements are US$3,000 one-time or US$450 per month for Autonomous, and US$6,800 one-time or US$1,275 per month for Hybrid, where every finding is validated by a human pentester. Both tiers carry our "No High or Critical Finding = Don't Pay" guarantee, and Enterprise covers estates like these; see the pricing page and services overview. This evidence supports a secure-SDLC program and the questions that arise in ISO 27001 and SOC 2 work, where independent offensive testing is commonly requested evidence. Where a mandate applies, PCI DSS v4.0.1 requires penetration testing across a general population of in-scope organisations, and CMMC requires it at Level 3.
Frequently Asked Questions
Is Ollama safe to expose on a network?
Not without something in front of it. NVD's record for CVE-2026-7482 states that the /api/create and /api/push endpoints have no authentication in the upstream distribution, that default deployments bind to 127.0.0.1, and that the documented OLLAMA_HOST=0.0.0.0 configuration is widely used in practice (NVD). On a build before 0.17.1 that port can be made to read past a heap buffer, so bind it to loopback, put authenticated ingress in front, and run 0.17.1 or later.
Does Ollama have authentication?
Not on the model-management endpoints in the upstream distribution: NVD's CVE-2026-7482 record states that /api/create and /api/push have no authentication there (NVD). Authentication has to come from whatever sits in front of the service, a reverse proxy or gateway covering every path rather than only the inference endpoints.
Is vLLM vulnerable to remote code execution?
On versions from 0.8.3 up to but excluding 0.14.1, through a chain. NVD's description of CVE-2026-22778 explains that an invalid image sent to the multimodal endpoint produces an error vLLM returns to the client, leaking a heap address and collapsing ASLR, and that this can be chained with a heap overflow in the JPEG2000 decoder in OpenCV and FFmpeg to achieve remote code execution (NVD). The leak is vLLM's own bug and the memory corruption is in a dependency, so upgrade to 0.14.1.
What is CVE-2026-24207 in NVIDIA Triton?
It is an authentication bypass in NVIDIA Triton Inference Server, published 20 May 2026 and classed CWE-288, where NVIDIA's own text says a successful exploit "might lead to" code execution, escalation, tampering, denial of service or information disclosure (NVD). The CVSS 3.1 score of 9.8 Critical is NVIDIA's as the CNA, typed Secondary, with no NVD primary score, and NVD's product data puts the affected range at all versions before 26.03.
Can a GGUF model file contain an exploit?
A crafted GGUF file can trigger memory corruption in the code that parses it, which is why model files are untrusted input rather than inert data. CVE-2026-27940 is an integer overflow in llama.cpp's GGUF loader leading to an undersized heap allocation, fixed in build b8146, and NVD records it as a bypass of the earlier CVE-2025-53630 whose fix overlooked some areas (NVD). A second flaw, CVE-2026-33298, is fixed in build b7824.
How do you secure a self-hosted LLM inference endpoint?
Start with the version floors: Triton 26.03 or later, vLLM 0.14.1 or later, Ollama 0.17.1 or later, and llama.cpp build b8146 or later. Then bind to loopback or an internal interface, put authenticated ingress in front, and do not treat an API key flag as full authentication: vLLM's own security documentation notes that --api-key covers only the /v1 path prefix and similar paths while other sensitive endpoints on the same HTTP server are not protected (vLLM security documentation).
Should inference servers be in scope for a penetration test?
Yes, as web services rather than as opaque AI infrastructure. Every flaw described here is reachable through an HTTP or gRPC listener that many inventories never classify as an application, and the products ship with authentication that is absent or narrower than teams assume. A useful scope adds the serving tier and its management endpoints, the path a model artifact travels from a public hub to a serving host, and the tenancy boundary on shared GPU infrastructure.
How do I verify a model file downloaded from a public hub?
Verify the publisher identity and compare the file's checksum against the hash the publisher states before the file reaches a parser, because the malicious values in these flaws live in structural fields the loader reads rather than in the weights. Then parse anything you did not produce yourself in a constrained process with no network egress and no access to production credentials, since converting or quantizing a file requires parsing it first.
References
NIST National Vulnerability Database. CVE-2026-24207. Published 20 May 2026. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-24207. NVIDIA Triton authentication bypass, CWE-288, source identifier
psirt@nvidia.com; CVSS 3.1 9.8 Critical typed Secondary with no NVD primary score; affected range all versions before 26.03.NIST National Vulnerability Database. CVE-2026-24209, CVE-2026-24210, CVE-2026-24215. Published 20 May 2026. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-24215. Triton siblings covering path traversal (CWE-22), integer overflow (CWE-190) and uncontrolled resource consumption in the DALI backend (CWE-400); CVE-2026-24215 carries an NVD primary score of 7.5 High alongside NVIDIA's secondary 5.7 Medium.
NVIDIA Triton Inference Server. Secure Deployment Considerations. https://github.com/triton-inference-server/server/blob/main/docs/customization_guide/deploy.md. Vendor guidance that Triton is not intended to be exposed directly to an untrusted network, that solution security is the deployer's responsibility, and that dynamic model-repository updates can lead to arbitrary code execution.
NIST National Vulnerability Database. CVE-2026-22778. Published 2 February 2026. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-22778. vLLM heap-address leak via returned PIL error, CWE-532 and CWE-209, affected 0.8.3 to before 0.14.1; both CVSS 3.1 9.8 Critical blocks typed Secondary with no NVD primary score.
GitHub Security Advisory (vllm-project/vllm). GHSA-4r2x-xpjr-7cvv: vLLM has RCE In Video Processing. 2 February 2026. https://github.com/advisories/GHSA-4r2x-xpjr-7cvv. Vendor advisory carrying CWE-122 in addition to CWE-209 and CWE-532, locating the exploitable overflow in the JPEG2000 decoder in OpenCV's bundled FFmpeg; patched in 0.14.1.
vLLM. Security. https://docs.vllm.ai/en/latest/usage/security.html. Project security documentation stating that
--api-keyprotects only/v1and similar path prefixes while other sensitive endpoints on the same HTTP server are unprotected, that multi-node communication is insecure by default, and that the gRPC port should not be exposed to untrusted clients.NIST National Vulnerability Database. CVE-2026-7482. Published 4 May 2026. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-7482. Ollama heap out-of-bounds read in the GGUF model loader before 0.17.1, CWE-125; CVSS 4.0 8.8 High and CVSS 3.1 9.1 Critical both typed Secondary from the assigning CNA with no NVD primary; records that
/api/createand/api/pushhave no authentication upstream, that default binds are 127.0.0.1, and thatOLLAMA_HOST=0.0.0.0is widely used.GitHub Advisory Database. GHSA-x8qc-fggm-mpqg. 4 May 2026. https://github.com/advisories/GHSA-x8qc-fggm-mpqg. Advisory mirror for CVE-2026-7482 with the Go module affected range below 0.17.1 and the fix artefacts commit 88d57d0, pull request #14406 and release v0.17.1. No Ollama vendor advisory is referenced.
GitHub Security Advisory (ggml-org/llama.cpp). GHSA-3p4r-fq3f-q74v. 12 March 2026. https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-3p4r-fq3f-q74v. CVE-2026-27940, integer overflow in
gguf_init_from_file_impl()leading to an undersized heap allocation, CWE-122 and CWE-190, CVSS 7.8 High, affected at or below b8145 and patched at b8146; stated as a bypass of the CVE-2025-53630 fix.GitHub Security Advisory (ggml-org/llama.cpp). GHSA-96jg-mvhq-q7q7. March 2026. https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-96jg-mvhq-q7q7. CVE-2026-33298, integer overflow in
ggml_nbytesallowing a crafted GGUF file to bypass memory validation, CWE-122 and CWE-190, CVSS 7.8 High, patched in b7824.NIST National Vulnerability Database. CVE-2026-27940 and CVE-2026-33298. Published 12 and 24 March 2026. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-27940. NVD text confirming the b8146 and b7824 fix builds and recording CVE-2026-27940 as a bypass of CVE-2025-53630 whose fix overlooked some areas.
