NVIDIA Brev: SSH keys potentially exposed, how to check the real risk

Activity reported from October 4 to 20, 2026; customer notifications relayed at the end of October. Extracts from notifications attributed to NVIDIA, reported by the press, describe unauthorized access to Brev and possible exposure of SSH keys used for customer virtual machines. The reported notification says that keys have been replaced and no misuse has been found at this point. We have not identified a public NVIDIA incident report detailing the initial vector, number of affected accounts, or VM compromise. The 16 day interval describes activity reported on the platform, not 16 days of proven access to each machine.

What does a private SSH key allow?

An SSH pair separates a public key, authorized on the machine, from a private key, used by the client to prove its identity. If an attacker copies a private key and can reach a server that still accepts the corresponding public key, they can attempt authentication under the associated account. Success also depends on machine configuration, network controls, possible key protection and other access mechanisms. The possible exposure of a key therefore demonstrates neither a successful connection nor the reading of data from the VM.

The Brev documentation describes key management by its command line tool and the files held in the local directory ~/.brev/. This explains why the rotation must be checked on both ends: a new key on the client side and the replacement or deletion of the old public key in the authorized accounts of the instances. A rotation announced by the platform does not exempt from examining other copies of the key, other servers that trust it and the authentication logs during the reported window.

What the investigation must establish

Four questions must be distinguished: which keys could be read, which were still valid, on which instances they gave access and what uses appear in the SSH logs. Inspection of authorized_keys, logins, and newly added accounts or keys may reveal continued access independent of the initial key. Workloads should also verify their own secrets, as a compromised VM could expose environment variables; no workload compromise has been established by the public sources consulted.

This record is published as a conditional analysis of a reported notification. We must not attribute to it the mode of entry, a number of victims or an exploitation of keys that the available elements do not demonstrate. A technical publication from NVIDIA would clarify these points.

Sources: customer notification reported by Tom’s Hardware, official Brev CLI documentation.