Security Digest · Vulnerability record
CVE-2026-58399: @acastellon/auth: Authentication bypass via spoofable headers in validateToken()
@acastellon/auth is an authentication control system for microservices.
CVSS 8.7 High EPSS 1.0% · p62
Should you act?
Normal patch cycle
No exploitation signal; fix it in your next routine update if you are affected. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.
- No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
- EPSS 1.0%, percentile 62: FIRST’s model estimates a 1.0% chance of exploitation activity in the next 30 days, higher than 62% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
- Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
- Only applies if your dependency tree includes
@acastellon/auth(npm) < 2.3.0, fixed in 2.3.0. Check your lockfile, including transitive dependencies.
What it is
@acastellon/auth is an authentication control system for microservices. Versions prior to 2.3.0 appear to allow an unauthenticated authentication bypass in validateToken() through spoofable auth-user and Host request headers. The validateToken middleware contains a service-to-service bypass for auth-user: service-brother when req.get('host').startsWith(getHostName()). Both values involved in the check can be influenced by an unauthenticated HTTP client: auth-user is a request header, and Host is also client-controlled. As a result, a remote unauthenticated attacker can send a request with crafted headers and bypass token validation before the normal legacy/JWT/OIDC validation logic runs. A fix has been implemented in v2.3.0.
From the GitHub advisory
@acastellon/auth v2.2.0 appears to allow an unauthenticated authentication bypass in validateToken() through spoofable auth-user and Host request headers.
The validateToken middleware contains a service-to-service bypass for auth-user: service-brother when req.get('host').startsWith(getHostName()). Both values involved in the check can be influenced by an unauthenticated HTTP client: auth-user is a request header, and Host is also client-controlled. As a result, a remote unauthenticated attacker can send a request with crafted headers and bypass token validation before the normal legacy/JWT/OIDC validation logic runs.
Impact: An attacker may be able to access routes protected by validateToken() without a valid token. In deployments where downstream services trust auth-user or is- headers, this may also lead to privilege escalation.
Affected package: @acastellon/auth v2.2.0
Affected code: auth.js, validateToken() The issue is related to the service-brother bypass and getHostName() check.
Weakness type: CWE-287, CWE-290.
Product: @acastellon/auth (npm) · Assigned by: GitHub_M · Published: 2026-07-01
Affected and fixed versions
| Ecosystem | Package | Vulnerable | First fixed |
|---|---|---|---|
| npm | @acastellon/auth | < 2.3.0 | 2.3.0 |
| Vendor | Product | Affected versions (per CVE record) |
|---|---|---|
| antonio-castellon | module-auth | < 2.3.0 |
Severity scores
| Scored by | CVSS | Score | Vector |
|---|---|---|---|
| GitHub_M | 4.0 | 8.7 High | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N |
| GitHub | 4.0 | 9.3 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N |
- Attack vector: network (remotely reachable)
- Attack complexity: low
- Attack requirements: none
- Privileges required: none (no login)
- User interaction: none
CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.
Exploitation and urgency
- CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
- CISA SSVC assessment: exploitation none, automatable yes, technical impact total.
- FIRST EPSS (model of 2026-10-21): 0.97% probability of exploitation activity in the next 30 days; percentile 62.
Timeline
- — GitHub-reviewed advisory GHSA-gfj5-979r-92pw published (critical)
- — CVE record published by GitHub_M
- — CVE record last updated
Sources and references
Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.
Vulnerability records
- GitHub Advisory GHSA-gfj5-979r-92pw github.com
- CVE.org record CVE-2026-58399 cve.org
- NVD entry CVE-2026-58399 nvd.nist.gov
Other references from the CVE record and advisory
- github.com github.com
- github.com github.com
- npmjs.com npmjs.com