CVE-2026-24207: Critical NVIDIA Triton Authentication Bypass
Critical CVSS (9.8) reachable over network.
TL;DR - CVE-2026-24207 is a critical authentication-bypass vulnerability in NVIDIA Triton Inference Server, scored 9.8 by NVD. - Linux deployments from 22.09 through 24.03 are reported affected; upgrade to 24.04 or later after validating NVIDIA’s advisory. - A public proof of concept is reported by a secondary source, but confirmed in-the-wild exploitation has not been established.
Vulnerability at a Glance
CVE-2026-24207 affects NVIDIA Triton Inference Server and can allow a remote, unauthenticated attacker to bypass intended authentication controls. The available description says successful exploitation may lead to code execution, privilege escalation, data tampering, denial of service, or information disclosure.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-24207 |
| Product | NVIDIA Triton Inference Server |
| CVSS | 9.8 Critical |
| CVSS version | 3.1 base score |
| Attack vector | Network |
| Authentication or privileges required | None indicated by the available scoring context |
| User interaction | None indicated |
| Patch status | Yes, according to secondary reporting |
| Reported affected versions | Linux 22.09 through 24.03 |
| Reported fixed version | 24.04 |
| CISA KEV status | Not listed at the time of lookup |
The version and remediation details require qualification. The retrieved NVD summary did not include affected-version ranges, and NVIDIA’s primary advisory could not be retrieved during research. A Centre for Cybersecurity Belgium advisory reports the 22.09–24.03 range and remediation in 24.04. Treat those values as operationally useful, but verify them against NVIDIA’s advisory before making a production change.
Analyst’s Take: Prioritize network-reachable Triton instances, especially those exposed through internet-facing load balancers or shared infrastructure. The reported proof of concept and 9.8 score justify immediate triage, but available sources do not independently confirm the exploit details or in-the-wild activity.
What Is This Vulnerability?
CVE-2026-24207 is an authentication-bypass vulnerability. Triton has an intended authentication boundary protecting functionality, but an attacker can reportedly reach protected behavior without successfully satisfying that boundary. Because Triton commonly exposes HTTP, gRPC, or metrics-related services through infrastructure and ingress layers, an exposed instance can become a high-value target.
The available technical material does not identify the precise vulnerable endpoint, protocol operation, component, code path, or implementation error. It is therefore not appropriate to claim a specific malformed request or exploit sequence. Defenders should assume that any network-reachable Triton service in the affected version range may be exposed until the deployment is patched or isolated.
The NVD description states that exploitation might enable code execution, privilege escalation, data tampering, denial of service, or information disclosure. These are impact possibilities, not confirmation that every affected deployment is exploitable to each outcome. The actual post-exploitation impact depends on Triton’s container privileges, host permissions, mounted model repositories, credentials, network access, and surrounding controls.
For background on remote code execution terminology, see the RCE definition.
Who Is Affected?
The affected product is NVIDIA Triton Inference Server for Linux. A secondary advisory from the Centre for Cybersecurity Belgium identifies versions 22.09 through 24.03 as affected and 24.04 as the remediated version. Available research does not establish whether every packaging format, container image variant, deployment method, or platform-specific build within those releases is affected.
Inventory more than package-manager installations. Triton is frequently deployed as a container, Kubernetes workload, VM service, or embedded inference component. Search container registries, Kubernetes manifests, Helm values, Compose files, systemd units, CI/CD pipelines, and image labels for Triton version references. Identify services behind reverse proxies or API gateways as well; a service that is not directly internet-facing may still be reachable by untrusted tenants, workloads, or partner networks.
The following range should be used for initial triage:
| Deployment | Initial assessment |
|---|---|
| Triton Linux 22.09–24.03 | Treat as affected pending vendor validation and upgrade |
| Triton Linux 24.04 or later | Reported remediated at 24.04; confirm advisory and support status |
| Version unknown | Treat as potentially affected until identified |
| Non-Linux or vendor-integrated build | Do not assume status; verify with NVIDIA |
If a deployment uses a vendor appliance or managed platform that bundles Triton, the platform owner must confirm the underlying version and remediation status. Do not infer safety solely from the appliance release date.
CVSS Score Breakdown
NVD assigns CVE-2026-24207 a CVSS 3.1 base score of 9.8, classified as Critical. The available record summary did not provide the authoritative vector string. Research context indicates a network-reachable flaw requiring no privileges and no user interaction, but the exact vector should be confirmed in NVIDIA’s advisory or the complete NVD record before it is quoted as authoritative.
The score indicates a vulnerability that can be attacked remotely and without prior access to an account. The absence of required privileges and user interaction increases exposure because an attacker does not need a valid session or a victim to click a link. The reported impacts include confidentiality, integrity, and availability consequences, explaining the critical rating.
CVSS is a severity measure, not an exploitability forecast or business-risk calculation. A Triton instance bound only to a protected management network has a different practical exposure from one published through an internet-facing load balancer. Internal services can still be at risk in environments with weak segmentation or compromised workloads. Prioritize externally reachable instances first, then shared inference infrastructure and systems holding sensitive models or data.
Exploitation Status
CVE-2026-24207 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of the referenced lookup. There is therefore no CISA KEV date added, due date, required action, or ransomware-campaign designation to report. This does not prove that exploitation has not occurred; it means only that CISA had not included the CVE in KEV at that point.
A Centre for Cybersecurity Belgium advisory reportedly states that a proof of concept was published for NVIDIA Triton Inference Server vulnerabilities and recommends immediate patching. The advisory page and technical PoC details could not be independently retrieved during the research process, so exploit reliability, affected endpoint, and exploit prerequisites remain unverified here. The correct status is therefore: a public PoC is reported by a secondary source, but its technical details are not independently confirmed in this analysis.
Confirmed in-the-wild exploitation has not been established from the available sources. The combination of a 9.8 score, network reachability, no indicated privilege requirement, and reported PoC still warrants emergency-style triage. Security teams should not wait for KEV inclusion or confirmed exploitation before restricting exposure and upgrading.
How to Detect CVE-2026-24207
Detection should begin with asset and version discovery. Review Kubernetes workloads, container image tags, Docker metadata, package inventories, and service banners. A basic search across deployment repositories can identify common Triton references:
grep -RInE 'tritonserver|nvcr.io/nvidia/tritonserver|Triton Inference Server' \\
./k8s ./helm ./compose ./terraform ./ansible 2>/dev/null
For running containers, collect image and process information rather than relying only on a manifest:
docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}' | grep -i triton
docker inspect <container_id> \\
--format '{{.Config.Image}} {{range .Config.Env}}{{println .}}{{end}}'
The exact exploit request is not available from the retrieved sources, so defenders should avoid deploying an unverified signature as authoritative. Correlate access logs for unauthenticated requests to Triton endpoints with unusual response codes, request rates, and subsequent administrative or inference activity. Depending on the deployment, relevant paths may include health, readiness, model, inference, repository, HTTP, or gRPC routes. Path names vary by configuration and should not be treated as definitive exploit indicators.
For reverse-proxy logs using a combined format, an initial hunt can identify requests to common Triton API paths:
index=proxy
| search uri_path IN ("/v2/health/live", "/v2/health/ready", "/v2/models/*",
"/v2/repository/*", "/v2/infer")
| stats count min(_time) as first_seen max(_time) as last_seen
values(status) as status values(src_ip) as source_ips by host, uri_path
Investigate requests that are unauthenticated where authentication is expected, originate from untrusted networks, or are followed by model changes, process launches, unexpected outbound connections, or access to mounted repositories. Preserve proxy, ingress, Kubernetes audit, container runtime, and host telemetry before rotating or rebuilding systems so that potential compromise evidence is not lost.
Technical Notes
A useful detection pattern is not a single known exploit string but an authentication-policy violation: requests reaching Triton API routes without the expected identity header, token, mTLS principal, or gateway authorization decision. Example pseudocode for a log pipeline is:
IF service = "triton"
AND request_path matches "^/v2/"
AND auth_result IN ("missing", "failed", "bypassed")
THEN alert("Triton request reached API without expected authentication")
Tune this against the actual gateway architecture. Some health endpoints are intentionally unauthenticated, so alerts should distinguish permitted liveness checks from model-management and inference operations. Compare Triton access logs with gateway logs to identify requests that appear authorized at the backend but were not authorized at the edge.
Mitigation and Patching
The reported remediation is NVIDIA Triton Inference Server 24.04 for affected Linux versions 22.09 through 24.03. Upgrade to 24.04 or a later supported release after confirming the exact NVIDIA advisory, compatibility requirements, CUDA dependencies, model behavior, and organizational support policy. Because the primary advisory details were not available in the retrieved material, do not assume that 24.04 is the newest or universally recommended release.
For container deployments, first identify the currently approved image and then pull and deploy the fixed image through the normal validation pipeline. The exact registry tag should be selected from NVIDIA’s official distribution and your platform compatibility requirements; do not substitute an unverified tag. A generic operational sequence is:
# Record the current image and deployment state
docker inspect <triton_container> --format '{{.Config.Image}}'
docker ps --no-trunc | grep -i triton
# Pull the vendor image tag corresponding to Triton 24.04 or later
docker pull <approved-nvidia-triton-image>:<24.04-or-later>
# Recreate through the controlled deployment process
docker stop <triton_container>
docker rm <triton_container>
docker run ... <approved-nvidia-triton-image>:<24.04-or-later>
For Kubernetes, update the image through the deployment or Helm release rather than editing a running pod:
kubectl -n <namespace> set image deployment/<triton-deployment> \\
<container-name>=<approved-nvidia-triton-image>:<24.04-or-later>
kubectl -n <namespace> rollout status deployment/<triton-deployment>
The placeholders are deliberate. NVIDIA image names, registry locations, container names, and supported tags vary by deployment. Confirm the exact fixed image and digest through NVIDIA’s official advisory or approved internal mirror before production rollout.
Until patched, apply layered containment. Restrict Triton listeners to trusted networks, remove direct internet exposure, enforce authentication at a reverse proxy or API gateway, limit access to model-management operations, and use network policies to prevent unnecessary east-west connectivity. A proxy is not a complete fix if attackers can reach the backend directly or if the vulnerable service has an alternate exposed port.
Review credentials, API tokens, model-repository permissions, and cloud identities available to the Triton process. If an affected instance was internet-facing or shows suspicious access, rotate relevant secrets, inspect mounted files and models, review process and network telemetry, and consider rebuilding the workload from a trusted image. Validate health checks, model loading, inference behavior, GPU compatibility, and rollback procedures after upgrading.
Technical Notes
A temporary firewall or security-group control should permit only known management or application networks. For example, a host-level policy can be expressed conceptually as:
# Example only: replace the source network and port with your environment
sudo ufw deny 8000/tcp
sudo ufw deny 8001/tcp
sudo ufw deny 8002/tcp
sudo ufw allow from <trusted-inference-network> to any port 8000 proto tcp
sudo ufw allow from <trusted-inference-network> to any port 8001 proto tcp
sudo ufw allow from <trusted-inference-network> to any port 8002 proto tcp
Do not copy these commands without confirming Triton’s configured ports and the impact on health checks and production traffic. The objective is to remove untrusted reachability while the upgrade is prepared, not to disrupt service blindly.
For organizations reviewing broader cloud security controls alongside vulnerability remediation, see our guide explaining what FedRAMP authorization means.
References
The NVD record is the primary public vulnerability reference and identifies CVE-2026-24207, NVIDIA Triton Inference Server, the authentication-bypass description, and the 9.8 CVSS score:
NVIDIA’s security advisory is the primary source that should be used to confirm affected builds, the authoritative CVSS vector, fixed versions, and any vendor-specific workarounds:
The CVE record provides the identifier and coordinated vulnerability information:
Additional references include the GitHub Advisory Database entry and a Centre for Cybersecurity Belgium advisory. The latter reports Linux versions 22.09–24.03, remediation in 24.04, and a published proof of concept, but those details should be cross-checked with NVIDIA before final production decisions:
As of the referenced lookup, CISA KEV did not list this CVE. That status can change, so organizations should recheck the catalog during incident triage and patch prioritization.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.