CVE-2022-31004 is a recently disclosed vulnerability in CVEProject/cve-services, an open source project commonly used to run CVE services APIs—critical infrastructure that helps track and assign software vulnerabilities. This long-read post will break down what the vulnerability is, how the code works, and how an attacker might exploit the issue. We'll keep it simple and clear so everyone can understand, even if you're not a security specialist.
## What Is CVEProject/cve-services?
Many organizations run their own CVE services using this Node.js application. It acts as a backend API to manage and issue CVE IDs for new vulnerabilities and is used by the CVE community to coordinate security information. Keeping it secure is essential.
Where's The Bug?
The vulnerability is in the logic of a single conditional statement. The file at issue is data.js (direct link may be unavailable if code changes; see issue 1925 for discussion).
The problem? A production secret is accidentally written to disk.
The code that generates a randomKey should keep it secret, but due to a conditional, it can wind up stored on disk in plain text—making it accessible to anyone who can read the files, such as other users on the server or an attacker who manages to breach the filesystem.
Let’s examine a snippet inspired by the vulnerable code (simplified)
// data.js
const fs = require('fs');
const path = require('path');
function writeSecretKey(randomKey) {
const env = process.env.NODE_ENV;
if (env !== 'development') {
// This will write the randomKey in plaintext!
fs.writeFileSync(path.join(__dirname, 'randomKey.txt'), randomKey);
}
}
If the environment is anything OTHER than development, the randomKey is saved to a file.
- This means in production, the secret key will just sit there as randomKey.txt, probably in a known directory.
Attacker Gains Filesystem Access
Suppose a hacker gets access to the production server (maybe via another bug, misconfiguration, or as a malicious insider).
Uses the Key
If this secret key is used for cryptographic operations, user session validation, or as an API credential, the attacker can now impersonate users or escalate their privileges.
Why Is This Serious?
Secrets Should Never Be Written Down in Production.
If a key must be generated and referenced at runtime, it should live only in memory or in secure storage (like environment variables or a secrets vault), never on disk in plaintext—especially without file permissions restricting access.
Who Is Affected?
- Any deployments running CVEProject/cve-services
No Patch Is Available Yet!
As of this writing, there’s no official patch. According to the CVEProject/cve-services GitHub issue #1925:
> A hot fix is anticipated for version 1.1.1 and for the 2.x branch.
function writeSecretKey(randomKey) {
// Don't write to disk at all!
fs.writeFileSync(path.join(__dirname, 'randomKey.txt'), randomKey);
}
// Else, do nothing.
}
`
Or ideally, do not write the secret anywhere outside of memory.
---
## References and Further Reading
- CVE-2022-31004 @ CVE.org
- GitHub Security Advisory
- Issue in GitHub for Hotfix tracking
- Project homepage
---
## In Summary
CVE-2022-31004 is a classic case of a simple conditional error leading to a big problem: leaking secrets. If you’re running CVEProject/cve-services, keep an eye out for the upcoming patch. In the meantime, audit your code and access controls. One misplaced file can lead to serious compromises, especially for projects dealing with sensitive security data.
Stay safe & patch fast!
Timeline
Published on: 06/02/2022 14:15:00 UTC
Last modified on: 06/10/2022 15:58:00 UTC