CVE-2025-64097 is a critical flaw in NervesHub, the web service for over-the-air firmware updates, scored CVSS 9.8. User API tokens had a predictable format and could be brute forced. Fixed in NervesHub 2.3.0, so upgrade and replace tokens issued before that.
What's affected
The NVD record and the GitHub advisory say NervesHub versions starting at 1.0.0 and before 2.3.0 are affected. The fix is version 2.3.0. The advisory lists the container image ghcr.io/nerves-hub/nerves-hub, the nerves_hub OTP package and the git repository. It was published on 22 January 2026, and it rates the issue Critical, 9.5 on CVSS v4.
The weakness is CWE-330, use of insufficiently random values. The advisory says tokens included user identifiable parts and were not cryptographically secure, so they could be guessed or enumerated, and that the issue was demonstrated with a proof of concept.
How to check if you're exposed
Find the NervesHub version you run. For the container image, read the tag of the deployed image. For a source deployment, read the version from your release or lock file.
If it is 1.0.0 or later and below 2.3.0, you are affected. The advisory says no practical workaround exists other than upgrading.
Then look at your token inventory. List the user API tokens that exist in your deployment and who owns them. Tokens issued before the upgrade are the ones that were produced in the weak format.
Check server logs for runs of failed authentication with API tokens, and for API calls from unfamiliar addresses.
What to do now
- Upgrade NervesHub to 2.3.0 or later.
- Read the 2.3.0 release notes and the revamp of token storage, which the advisory lists as the change that introduces strong random tokens, hashed storage and separate session and API token handling.
- Have users create new API tokens after the upgrade, and delete the old ones, since old tokens came from the weak scheme.
- Firewall the NervesHub server so that only trusted networks reach it, as a temporary measure for sensitive environments.
- Review device and firmware changes made through the API over the exposure period. Look for firmware uploads, deployments or device actions you did not authorize.
- Add alerts for repeated failed token authentication.
Why it matters
The class is CWE-330, use of insufficiently random values. A token is a password for a program. If a token follows a pattern, an attacker does not need to steal one. They can generate candidates and test them, and a service that answers each guess helps them. Tokens need to come from a cryptographic random source and be long enough that guessing is not realistic.
The fix does three things. It uses strong random bytes from the Erlang crypto module, it hashes tokens before saving them so a database leak does not give away working tokens, and it stores tokens with context so session tokens and API tokens are treated differently. Hashing at rest is worth copying in your own systems for any bearer secret.
The stakes are high for an update service. Access to the API can mean control of what firmware runs on devices in the field. That puts weak tokens in the same class as a stolen deployment key, and it is the reason the advisory scores the downstream impact so high. The KEV flag is false, and the advisory does not say the flaw was exploited against real deployments.
Continuous monitoring helps here because the risk comes back whenever an old image tag is redeployed. Watching for versions below 2.3.0 in running environments catches that.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a workaround?
The advisory says there is no practical workaround other than upgrading. For sensitive setups it suggests firewalling access to the server until you can upgrade.
Do I need to replace tokens after upgrading?
The advisory does not state it. Because earlier tokens came from the predictable scheme, replacing them is the careful choice.
Sources
Last reviewed: 19 October 2026.
