Listen to this Post
The vulnerability in Hono’s JWT middleware stemmed from its failure to validate the “aud” (Audience) claim by default. According to RFC 7519, if an `aud` claim is present in a JWT, the recipient must identify itself with a value in that claim; if it does not, the token must be rejected. Hono’s default verification only checked the `iss` (Issuer), `nbf` (Not Before), `iat` (Issued At), and `exp` (Expiration) claims. This omission meant that an application using the middleware without explicit, additional audience validation could inadvertently accept a JWT that was validly signed and issued but intended for a completely different service or audience. In a multi-service environment sharing a common JWT issuer or signing keys, this could lead to a token mix-up attack, allowing a token minted for “Service B” to be wrongly accepted by “Service A,” potentially granting unauthorized cross-service access.
Platform: Hono
Version: < v4.2.6
Vulnerability: Improper Authorization
Severity: Medium
date: 2024-08-28
Prediction: 2024-09-11
What Undercode Say:
Simulating a JWT with an incorrect audience
echo "Header: {alg:HS256, typ:JWT}"
echo "Payload: {iss:trusted-issuer, aud:service-b, sub:user123}"
echo "This token for 'service-b' is incorrectly accepted by 'service-a'."
// Vulnerable code (no audience check)
app.use('/api/', jwt({ secret: 'my-secret' }))
// Secure code with audience validation
app.use('/api/', jwt({
secret: 'my-secret',
verification: { aud: 'service-a' }
}))
How Exploit:
Obtain valid JWT for Service B. Present token to Service A. Gain unauthorized access if Service A lacks audience check.
Protection from this CVE
Update Hono to v4.2.6+. Configure the `verification.aud` option in the JWT middleware.
Impact:
Cross-service access. Token mix-up attacks. Unauthorized endpoint invocation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
