Hello, On Thu, Nov 05, 2026 at 11:57:37PM -0500, [email protected] wrote: > Hello list, > > jwt_verify's key argument is documented as holding "a secret or a > public key path." The code never separates the two uses. The > verification algorithm comes solely from the converter's algorithm > argument; on the HMAC branch, the key argument is passed verbatim to > HMAC() as the secret. The one guard -- ctx->is_x509, src/jwt.c:271 -- > refuses HMAC only when the key string names a certificate. A bare > public-key path has no such protection. > > The third component is the documentation's own example, which > extracts the algorithm from the token being verified and passes a > public-key path as the key. A deployment following the vendor's > example has arranged the RS256->HS256 confusion itself -- and the > resulting HMAC secret is the key's filesystem path, a string that > appears in configurations and error messages and is secret from > no one. > > Proven live on the official haproxy:3.4.7 image, configured with > the documented pattern: > > legitimate RS256 token -> accepted > forged HS256, key = "/usr/local/etc/haproxy/rsa-pub.pem" (literal) > -> accepted (bypass) > forged HS256, wrong key -> rejected > no token -> rejected > > 3.4.7 is the current stable release, and master HEAD carries the > identical construction. Credit where due: 3.4.7 hardened this same > converter against the "none" algorithm, per RFC 8725. The other > door of the same class stayed open. No CVE, vendor advisory, or > public writeup covers this construction; the search behind that > statement is documented in ยง5 of the paper.
Thanks for your report. This is indeed an interesting case. > The fix has the shape of the guard that already exists: bind the > algorithm family to the key type, and refuse HMAC verification for > material loaded as an asymmetric key. Since you've done the analaysis, could you please propose a patch as per CONTRIBUTING ? > Paper: https://archive.org/details/knell-the-path-is-the-key > Mirror: https://github.com/the-knell/The-Path-Is-the-Key > Key: 133883AB9F6EDE5B9BA6B82E27BEDAF0CE152F25 (knell) > > Verify: gpg --import knell-public.asc, then > gpg --verify paper-haproxy-FINAL-2026-11-05.md.asc > > Any response from the HAProxy developers will be appended to the > paper unedited. Well, I don't know if this sentence was meant to be a threat or an invitation, but that's definitely the best way to scare away developers from responding. Please just propose a tested patch that will be reviewed and applied if found valid. That's the fastest way to get a fix in, and the best way for you be credited for your work. thanks, Willy
