GHSA-m4w9-hjfw-vwj4
http4k: `HmacSha256.hash` (despite the `Hmac` naming) computed a plain unkeyed digest; clarified by deprecation in favour of `Sha256.hash` / `Sha256.hmac`
Blast Radius
org.http4k:http4k-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The HmacSha256 class contained two functions:
hash(payload)— a plain unkeyed SHA-256 digest. TheHmacprefix in the class name was misleading; this function has no key parameter, so it could never have been an HMAC.hmacSHA256(key, data)— a properly keyed HMAC-SHA256.
A reader who didn't engage with the function signature could in principle have assumed HmacSha256.hash(payload) was somehow keyed, but the absence of any key parameter made that misuse unlikely in practice.
Who is affected: any downstream caller who read the class name and used HmacSha256.hash as a message authentication code without noticing it takes no key. Verified at v6.47.2.0: zero internal misuse in http4k itself. Both production usages of HmacSha256.hash (AWS SigV4 canonical-request hashing in AwsSignatureV4Signer.kt and x-amz-content-sha256 in awsExtensions.kt) are AWS-spec-correct uses of plain SHA-256; every keyed hmacSHA256(key, data) call passes a real key. The advisory exists so any downstream caller relying on the misleadingly-named API knows to migrate.
Patches
Upgrade to 6.49.0.0 or later. The fix introduces:
Sha256.hash(input)— unkeyed digest (the actual behaviourHmacSha256.hashprovided).Sha256.hmac(key, input)— keyed HMAC-SHA256 (the behaviour the name implied).
HmacSha256 is deprecated. Existing callers continue to work via deprecation shims; migrate to Sha256.hash or Sha256.hmac per intent.
Workarounds
If you cannot upgrade and you need a real HMAC-SHA256, use javax.crypto.Mac.getInstance("HmacSHA256") with a SecretKeySpec. For an unkeyed SHA-256 digest, use java.security.MessageDigest.getInstance("SHA-256"). The keyed hmacSHA256(key, data) was always correctly implemented and is safe to use as-is.
References
- Fix release: v6.49.0.0
- Background: RFC 2104 — HMAC: Keyed-Hashing for Message Authentication
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.http4k:http4k-core | all versions | 6.49.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.http4k:http4k-core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.http4k:http4k-core to 6.49.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m4w9-hjfw-vwj4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-m4w9-hjfw-vwj4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-m4w9-hjfw-vwj4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-m4w9-hjfw-vwj4 in your dependencies?
O3 detects GHSA-m4w9-hjfw-vwj4 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.