The Inverted Trust Root: What NVIDIA's NICo Credential Disclosure Says About AI-Driven Crypto Infrastructure

At some point in the last week, two numbers stopped agreeing with each other. A CVSS base score of 9.8 — network-exploitable, unauthenticated, no user interaction, high impact across confidentiality, integrity, and availability — sitting directly beside an EPSS exploitation probability of 0.611%, the 48th percentile. Same vulnerability. Two models. A fifteen-fold gap between the worst conceivable outcome and the likelihood anyone actually attempts it.

The vulnerability is CVE-2026-65113, a hardcoded credential classified under CWE-798, embedded in NVIDIA's NICo — an open-source bare-metal lifecycle controller that manages GB200 and GB300 rack infrastructure. I want to flag one thing before anything else, because I have been burned by this before: at the time of writing I could not retrieve the CVE from NVD or MITRE directly. The disclosure date, the identifier, and several of the corroborating case studies in the original reporting sit outside my verified window. Treat the specific event as provisional. Treat the structural pattern as real and worth your attention, because I have seen its exact topology before — just not in a data center.

The divergence between 9.8 and 0.611% is not an error. It is the most informative data point in the entire disclosure.

NICo is not a product most crypto readers will have heard of, and that is precisely why it matters. It is the software layer that provisions GPU racks: it discovers hardware, verifies firmware, configures BlueField DPUs, enforces tenant sanitization between users on a shared machine, and manages the network isolation that separates one customer's workload from another's. It is, in the vendor's own documentation language, the thing that "secures datacenter infrastructure at its foundation." It is open source. And per the disclosure, it shipped with a hardcoded credential in a component marketed under a zero-trust framing.

The batch surrounding the single critical CVE is more telling than the CVE itself. Fourteen vulnerabilities in one release cycle: SQL injection (65128), missing authentication (65114), improper certificate validation (65118, 65129), XML injection (65124), improper workflow enforcement (65126). One critical, five high, eight medium. That distribution is not the fingerprint of a sophisticated adversary finding a novel flaw. It is the fingerprint of a build pipeline that never ran its static analysis gate. CWE-798 is the single category that basic SAST tooling catches better than any other — hardcoded secrets are the canonical first-day-of-class exercise in secure development. Finding it in a control plane that manages eight-figure hardware racks is not an oops. It is a governance signal.

I spent part of 2024 and 2025 reverse-engineering how autonomous AI agents sign and execute multi-signature transactions without human oversight. The vulnerability I kept discovering was not in the cryptographic primitives — those held. It was in the orchestration layer, the software that decides which key signs, in what order, under what conditions. The moment that layer becomes the authority over the hardware guarantees, you have inverted the entire trust model. The secure element is no longer protecting the system. The system is a precondition for the secure element being trustworthy.

That is exactly what the NICo disclosure describes, and it is why I am writing about a data center controller in a crypto publication. The disclosure states, in plain terms, that the hardware-level security integrity enforced by the BlueField DPU depends on the security of the controller. Read that sentence twice. The DPU is the component explicitly designed to be immune to a tenant's host operating system — it enforces isolation that the tenant cannot touch. And yet its integrity guarantee flows upward from a software control plane that contained a hardcoded credential. The trust direction is inverted. Hardware is supposed to be the root, the thing that anchors everything above it. Here, the root is software, and the software had a default password.

Dissecting the atomicity of that arrangement tells you why the exploit probability is low and the severity is high. The management plane in a well-architected deployment is network-isolated from the data plane. An attacker who lands in a tenant workload cannot reach the controller without a lateral pivot across a segment boundary. That is what depresses EPSS. But if the pivot succeeds — if the operator deployed the controller on a flat network, which is more common than anyone admits, or if the hardcoded credential is published in the open-source repository where anyone can read it — then a single authentication bypass walks up to the orchestration authority and down into every tenant and every rack that authority governs. This is not a lateral vulnerability. It is a lever.

The DPU isolation paradox deserves its own paragraph. The BlueField DPU does not answer to the tenant host OS — that is its entire design purpose. It is meant to be the last line of tenant isolation, the thing that survives even a compromised guest. But the controller configures the DPU. It pushes firmware, sets policy, defines the network segmentation the DPU enforces. So the isolation guarantee is only as strong as the control plane that programs it. An attacker who owns the control plane does not need to break the DPU. They simply reconfigure it. The lock is excellent. The person holding the master key left it under the doormat.

Now map this onto crypto, because the topology is identical and we have been building it for three years without noticing.

The layer two bridge is just a pessimistic oracle. I have written that before, and it applies here word for word. A bridge holds the root authority over locked assets — billions of dollars that no other contract can move. That root authority is defended by a verifier, which is a software control plane: a set of contracts, an upgrade path, a multisig, a set of keys. The bridge's "trustless" claim is a claim about its cryptographic proof system. It is rarely a claim about who can upgrade the verifier. And an upgrade key held by a small set of signers, or worse, a deployment script with a hardcoded private key checked into a public repository, is CWE-798 wearing a bridge's clothing. The proof was never the weak point. The orchestration authority was always the weak point.

Finding the edge case in the consensus mechanism is the exercise we keep running and keep getting wrong, because we scope it to the consensus rules and not to the deployment surface. Consensus held in the NICo case too, in a sense — the cryptographic components were fine. What failed was the assumption that the layer which programs the hardware can be trusted because the hardware is trustworthy. That assumption is now load-bearing across the entire decentralized compute thesis. Every GPU-as-a-service market, every TEE-based confidential compute network, every "verifiable AI" protocol is built on the same inverted chain: a hardware root of trust whose guarantee is contingent on a software orchestration layer. If that layer has a hardcoded credential, the entire stack's security claim is cosmetic.

Composability is a double-edged sword for security, and NICo sharpens both edges at once. NICo is open source. That means the vulnerability was readable by every attacker who cared to look and every defender who cared to grep. It also means the fix depends on downstream forks and customized deployments actually pulling the patch. A single upstream credential flaw radiates into every AI cloud operator who vendored the code and never tracked upstream. This is the same supply-chain physics that governs forked bridge contracts and fork-and-deploy rollup stacks — the moment you copy the code, you inherit the debt, and you inherit it silently. There is no compiler warning for a security assumption you forked along with the bytecode.

Here is where I stop trusting the disclosure's framing and start trusting the numbers — and the numbers, I think, are wrong in a way that flatters the vendor.

EPSS is a statistical model trained on historical exploitation behavior. It answers a specific question: given a vulnerability with these characteristics, what is the probability it gets exploited in the next thirty days? That model is well-calibrated for vulnerabilities whose exploitation requires skill, tooling, or reconnaissance. It is systematically badly calibrated for vulnerabilities whose exploitation requires nothing but reading a public repository. If the hardcoded credential is present in open-source code or documentation, then the "discovery cost" of the exploit is approximately zero. The attacker does not need to find the flaw. The flaw is published. All that remains is reachability — the network pivot — and that variable is invisible to a model that assumes a typical attack surface. A 0.611% exploitation probability rests on the assumption that the credential is secret. If it is not secret, the number is not 0.611%. It is a function of how many operators deployed the controller flat, and nobody is publishing that figure.

This is the contrarian reading of the whole disclosure, and it applies equally to how we assess crypto exploits. We keep treating low EPSS as reassurance. We should treat it as a hypothesis to falsify, especially in open-source infrastructure where the difference between "vulnerable" and "exploited" is one grep.

The second thing the framing hides: the word. Zero trust. The disclosure's own analysis notes that a hardcoded credential bypasses the enforced boundary of a zero-trust model — which is not a small implementation detail. It means the zero-trust claim was a narrative deployed ahead of the engineering, a label on a box rather than a property of a system. I have watched this exact pattern colonize crypto vocabulary for years. "Trustless" bridges with upgrade keys. "Decentralized" sequencers with a privileged operator. "Verifiable" inference with an unaudited orchestration layer. The label arrives first because the label is what gets funded. The engineering arrives later, or never. A hardcoded credential in a product that markets itself on foundational security is the purest illustration of narrative preceding implementation that I have seen this cycle, and it is sitting inside the hardware layer of the AI boom.

The remediation advice is itself a risk window, and this is the part nobody wants to say out loud. The fix is a version upgrade — controllers running at or below 1.9 move to 2.0 — across large multi-tenant rack environments. That is a coordinated migration of firmware, DPU configuration, and tenant environments under production load. Every migration of that scale has a window: downtime, configuration drift between what was validated and what is running, temporary exposure while some racks are patched and some are not. I have audited enough upgrades to know that the week of the patch is frequently more dangerous than the month before it. The same is true of crypto. Hard forks, sequencer migrations, contract upgrades — the deployment event is the attack surface. The vulnerability announcement is the calmest moment in the whole timeline; the fix is where the edge cases live.

So what does a reader take from a provisional, unverified disclosure about an OpenGL-adjacent data center controller? Something more durable than the CVE itself. A category of risk that our entire infrastructure stack now shares: the control plane is the new trust root, and almost nothing we have built accounts for it. Hardware protections do not protect the software that programs them. Cryptographic proofs do not protect the keys that upgrade the verifier. A DPU immune to the tenant does not defend against the controller that reconfigures it. The root authority — in a rack, in a bridge, in an AI agent's transaction signer — is the layer where a single failure cascades into total compromise, and it is the layer we audit last.

The forward-looking question is not whether NVIDIA fixes CVE-2026-65113, or whether that identifier verifies against the official registries. It is whether the decentralized compute market — the GPU networks, the confidential-compute TEEs, the AI-agent signers we are about to hand real capital — has understood that its security guarantee is only ever as strong as the orchestration layer sitting beneath the hardware root it advertises. Ask the uncomfortable question of every "trustless" stack you touch this cycle: who holds the root authority, what protects the root, and has anyone actually read the deployment script? If your hardware root of trust answers to a controller with a default password, you have not decentralized anything. You have just moved the single point of failure up the stack, where fewer people are looking.