CVE-2026-53805: Critical Unauthenticated RCE in NVIDIA SIL GEN3C
Critical CVSS (9.8) reachable over network.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-53805 |
| CVSS score | 9.8 Critical |
| Attack vector | Network |
| Authentication required | None |
| Patch status | Fix available at commit db2ffe12ced12ddafcec5e0422ee46ce8520746b; no confirmed tagged release number from available sources |
TL;DR - Critical unauthenticated RCE in NVIDIA SIL GEN3C inference APIs. - Affects GEN3C builds before commit
db2ffe12ced12ddafcec5e0422ee46ce8520746b. - Prioritize upgrade or restrict access immediately if the API is reachable from untrusted networks.
Vulnerability at a Glance
CVE-2026-53805 is a critical remote code execution vulnerability in NVIDIA Spatial Intelligence Lab’s GEN3C project, also referenced as nv-tlabs/GEN3C. The issue exists in the inference API server, where raw HTTP request bodies sent to /request-inference and /seed-model were deserialized using Python pickle.loads() without authentication or adequate input validation.
That matters because Python pickle is not a safe wire format for untrusted data. A crafted pickle payload can trigger arbitrary object reconstruction logic, including __reduce__ gadget chains, resulting in code execution during deserialization. According to the NVD description and upstream patch context, an attacker only needs network access to the exposed inference API port to exploit the bug, making this especially serious for internet-exposed research, demo, or self-hosted inference deployments.
What Is This Vulnerability?
The root cause is unsafe deserialization of attacker-controlled input. In the vulnerable implementation, the API server accepted raw POST bodies and decoded them with pickle.loads(). That is fundamentally unsafe when the sender is not trusted, because pickle is designed for Python object serialization, not hostile input handling.
The exposed endpoints specifically called out in available source material are /request-inference and /seed-model. If those endpoints are reachable, an attacker can send a malicious serialized object that executes code as soon as the server attempts to parse the request. In practical terms, this is not just a crash or data corruption condition. It is a code execution path in the inference process itself, with impact dependent on what privileges that process has and what adjacent assets it can reach.
Technical Notes
The vulnerable pattern is conceptually similar to the following:
from flask import request
import pickle
@app.route("/request-inference", methods=["POST"])
def request_inference():
obj = pickle.loads(request.data) # unsafe
return handle(obj)
A malicious pickle can abuse __reduce__ to execute commands during deserialization:
import pickle
import os
class Exploit:
def __reduce__(self):
return (os.system, ("id",))
payload = pickle.dumps(Exploit())
The upstream fix reportedly replaces pickle-based transport with a safer serialization design using safetensors plus explicit JSON metadata and allow-listed object reconstruction, which is the right class of remediation for this bug family.
Who Is Affected?
The affected product is NVIDIA SIL GEN3C, tracked in public sources as the GitHub project nv-tlabs/GEN3C. Based on the available references, the vulnerable window includes builds and commits before the upstream fix was merged in June 2026. The available research note indicates the code and model were released on 2025-06-06, and the fix pull request was dated 2026-06-11.
The most precise version statement supported by the provided source material is commit-based, not release-based. Specifically, affected versions are GEN3C builds prior to commit db2ffe12ced12ddafcec5e0422ee46ce8520746b, and the fixed version is code at or after commit db2ffe12ced12ddafcec5e0422ee46ce8520746b. No formal semver range or tagged fixed release number was confirmed in the available sources. If you deploy from source, containerize from repository snapshots, or forked the project internally, you should assume you are vulnerable until you verify your code includes that exact fix or equivalent changes.
For defenders, the lack of a confirmed numbered release is important operationally. Many teams rely on package managers, image tags, or release pages to determine exposure. In this case, that information was not confirmed from the supplied references. If your deployment record only says “latest from before mid-June 2026” or references a pre-fix commit, treat it as affected until proven otherwise.
CVSS Score Breakdown and Risk
CVE-2026-53805 has a CVSS v3.1 base score of 9.8 Critical. The exact vector string was not provided in the available output, but a 9.8 rating is consistent with a remotely reachable, low-complexity, no-authentication RCE with high impact to confidentiality, integrity, and availability.
From a practitioner standpoint, the score aligns with the observed mechanics. The attack appears to require no prior credentials, no user interaction, and no local foothold. If the service is exposed to an untrusted network, exploitation may be as simple as sending a crafted request body to a known endpoint. Even if the inference process runs with reduced privileges, code execution in an ML-serving context can still expose model artifacts, API tokens, local files, environment variables, cloud metadata, or lateral movement paths to adjacent systems.
A second risk factor is exploit reliability. Unsafe pickle deserialization is a well-understood bug class, and defenders should not assume obscurity or niche deployment meaningfully reduces risk. Even without a public proof of concept, reproducing exploitation from the vulnerability description alone is plausible for a capable attacker.
Exploitation Status
Based on the available source material, there is no confirmed evidence of in-the-wild exploitation at this time. The vulnerability is not listed in CISA KEV as of 2026-06-17, which means there is no authoritative U.S. federal signal here that exploitation has been broadly confirmed in active campaigns.
Also based on the provided research note, no primary-source public PoC repository was confirmed during collection. A third-party advisory exists, but the supplied material does not establish a public exploit repository or a vendor-published reproducer. Therefore, the most accurate current status is: exploitation in the wild not confirmed, public PoC not confirmed from primary sources.
That said, absence of a known PoC should not lower priority. This vulnerability is a textbook unauthenticated deserialization RCE, and the affected endpoints and root cause are already documented. In the absence of confirmed exploitation telemetry, defenders should assume opportunistic scanning and exploit development are likely once exposure is understood by the wider community.
What Changed in the Fix
The patch is notable because it does not try to sanitize pickle input or bolt on superficial validation. Instead, it replaces the unsafe wire format with a constrained serialization design. Based on the provided research note, the project introduced safe_serialization.py, moved request encoding away from pickle, used safetensors for array data, and stored metadata in JSON with an allow-list of supported request object types.
That is important because unsafe deserialization flaws are rarely fixed safely by filters alone. The upstream change appears to acknowledge that the transport itself was the problem. By limiting which request classes can be reconstructed and removing arbitrary executable object restoration from the request path, the maintainers addressed the bug at the right layer.
How to Detect It
Detection is challenging if the service does not log request parsing details, because the malicious content is carried in a raw binary request body rather than a simple query parameter. Still, defenders have several practical angles: identify exposed instances, monitor for requests to the known endpoints, inspect application errors around deserialization, and watch for post-exploitation process behavior from the inference service.
Start with exposure validation. Inventory all deployments of nv-tlabs/GEN3C, including lab servers, demo instances, GPU workstations, and ephemeral cloud nodes. Then determine whether /request-inference or /seed-model is reachable from anything beyond a tightly controlled management network. If those endpoints are internet-exposed, prioritize containment before waiting for perfect detection logic.
Technical Notes
Look for HTTP access to the vulnerable endpoints, especially unusual POST requests with opaque or nonstandard binary bodies:
POST /request-inference HTTP/1.1
POST /seed-model HTTP/1.1
Content-Type: application/octet-stream
A basic reverse-proxy or web log grep can help identify candidate requests:
grep -E 'POST /(request-inference|seed-model)' /var/log/nginx/access.log
If your logging stack captures response codes and user agents, hunt for repeated failures or requests from unfamiliar automation:
index=web_logs ("POST /request-inference" OR "POST /seed-model")
| stats count by src_ip, user_agent, status
| sort - count
Application-side errors may include Python deserialization or request parsing failures. Exact strings are not confirmed from the provided sources, but defenders should search for stack traces containing pickle.loads, UnpicklingError, or exceptions near request-body decoding:
grep -R -E 'pickle\.loads|UnpicklingError|request-inference|seed-model' /var/log/
On the network, a coarse IDS-style signature can at least flag suspicious requests to the exposed paths:
alert tcp any any -> $HOME_NET any (
msg:"Possible GEN3C CVE-2026-53805 exploit attempt";
flow:to_server,established;
content:"POST"; http_method;
content:"/request-inference"; http_uri;
sid:10053805; rev:1;
)
Because payload contents may be binary and the exact exploit body is not confirmed, path-based detection plus host telemetry is more realistic than payload fingerprinting alone. Pair HTTP request logs with EDR detections for shell spawning, unexpected outbound connections, or child processes originating from the Python inference service.
Mitigation and Patching
The confirmed fix point is commit db2ffe12ced12ddafcec5e0422ee46ce8520746b. That commit replaces unsafe pickle-based request serialization with a safer mechanism using safetensors and constrained metadata handling. Because no fixed tagged release number was confirmed in the available sources, the safest guidance is to update your deployment to code that includes this commit or a later verified state from the upstream repository.
If you run GEN3C from a source checkout, verify the current revision and update explicitly. If you consume it through an internally built container or fork, trace the embedded source commit and rebuild from a fixed state. Do not assume that “pulled recently” means patched unless you can map the image or artifact to the fixing commit.
Technical Notes
Check your deployed commit:
git rev-parse HEAD
git log --oneline --decorate -n 5
Update to the known fix commit from upstream:
git fetch origin
git checkout db2ffe12ced12ddafcec5e0422ee46ce8520746b
If you track the main branch and have validated compatibility, update to a revision containing the fix:
git fetch origin
git checkout main
git pull --ff-only origin main
git log --oneline --grep="replace pickle with safetensors"
If immediate upgrade is not possible, apply compensating controls. Restrict access to the inference API so only trusted internal clients can reach it. For example, block external access at the host firewall:
sudo ufw deny in to any port <GEN3C_API_PORT>
sudo ufw allow from <trusted_subnet>/24 to any port <GEN3C_API_PORT>
Or with iptables:
sudo iptables -A INPUT -p tcp --dport <GEN3C_API_PORT> -s <trusted_subnet>/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport <GEN3C_API_PORT> -j DROP
If you must keep the service online before patching, place it behind an authenticating reverse proxy, disable public ingress, and run the inference process with the least privileges possible. Those workarounds do not remove the bug; they only reduce exposure while you move to fixed code.
References
Primary tracking and remediation references available from the supplied material include the NVD record, the upstream fix commit, and the pull request documenting the serialization change. Those are the best sources for verifying exposure and remediation state.
- NVD CVE record: CVE-2026-53805
- Fix commit:
https://github.com/nv-tlabs/GEN3C/commit/db2ffe12ced12ddafcec5e0422ee46ce8520746b - Pull request:
https://github.com/nv-tlabs/GEN3C/pull/62 - Additional PR reference:
https://github.com/nv-tlabs/GEN3C/pull/63 - Third-party advisory:
https://www.vulncheck.com/advisories/nvidia-sil-gen3c-unauthenticated-rce-via-pickle-deserialization-in-inference-api
If you are defending a GEN3C deployment, the practical takeaway is straightforward: verify whether your code predates commit db2ffe12ced12ddafcec5e0422ee46ce8520746b, restrict exposure to the API immediately, and move to the fixed code path as soon as possible.
For more information on related vulnerabilities, you can check out our articles on vishing and open redirect vulnerabilities.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.