GHSA-gxhx-2686-5h9g

What it actually does

The Go SecretsVerifier constructs HMAC-SHA256 over an unvalidated raw secret and does not enforce preconditions such as a non-empty key, minimum key length, or the presence of a request signature header. Forged or unsigned requests can therefore be treated as authentic, bypassing intended request authentication.

Why it matters to the business

A high-severity authentication bypass (CVSS 8.2) can let untrusted callers impersonate trusted senders, inject malicious payloads into downstream workflows, or invoke privileged actions. The issue is not listed in CISA KEV, has no reported ransomware use, and published exploit maturity is none, but it has been public for 137 days, so unpatched services remain an avoidable residual risk.

How an attack unfolds

An attacker locates an HTTP endpoint that authenticates callers with NewSecretsVerifier. Because the HMAC is keyed with the raw secret and no preconditions are applied, the attacker submits a request that omits a signature, uses an empty or weak secret, or otherwise fails closed-path checks the verifier never performs. The library accepts the request as authentic, and the attacker proceeds as a trusted party. No named threat actors or in-the-wild campaigns are associated with this advisory.

How to fix it

No affected products or fixed versions were supplied with this advisory. Treat verification as fail-closed: reject empty, missing, or undersized secrets; require a well-formed signature header before computing HMAC; compare digests in constant time; and rotate any secret that may have been used with the vulnerable verifier. Apply the vendor patch as soon as a fixed release is published, and pin to that version.

How to confirm the fix worked

Inventory call sites of NewSecretsVerifier and confirm secrets are non-empty and meet a documented minimum length. Negative tests should show rejection of missing signature headers, empty secrets, and invalid HMAC values. After upgrade, confirm the dependency no longer matches the vulnerable revision and that those negative tests still fail closed.

Typical attack path

1. Identify an HTTP or webhook endpoint that verifies inbound secrets with the affected SecretsVerifier
2. Send a crafted request that omits, empties, or otherwise fails the missing secret and signature preconditions
3. Have the verifier accept the request as authentic
4. Abuse the trusted context to inject data, trigger workflows, or call protected functionality

How to detect it

There are no public exploit artifacts or named campaigns. Hunt application and access logs for authenticated or webhook requests that succeeded without a signature header, with an empty secret configured, or with HMAC verification errors followed by a 2xx response. Review deploy and config history for empty or placeholder secret values around the verifier. Absence of these signals does not prove the issue was unused.

What your security team should do

• Prioritize review of any service that verifies inbound HMAC or webhook secrets in Go, despite the lack of KEV listing or known exploits
• Fail closed on empty secrets and missing signature headers until a patched release can be applied
• Rotate secrets that were used with the vulnerable verifier
• Add regression tests for missing-header and empty-secret cases
• Monitor for unsigned or unexpectedly accepted authenticated requests until patches are confirmed