Cycle244 - "The fix addressed a SIDE-EFFECT of the named threat, not the threat itself"

Date: 2026-06-16 Target: PyJWT PyJWKClient 2.13.0 (patched GHSA-fhv5-28vv-h8m8) Verdict: VULNERABLE-CONFIRMED (Medium DoS)

Lesson (new): read what the fix ACTUALLY changed vs what the advisory TITLE claims it fixed.

GHSA-fhv5-28vv-h8m8 is titled "unbounded JWKS requests via attacker-controlled kid (DoS)". The 2.13.0 change only stopped the cache-WIPE-on-error (a related side-effect). The NAMED threat - a fresh JWKS fetch per unknown kid with no rate-limit - was untouched. Empirically: same unknown kid x5 -> 5 fetches. The advisory title and the diff did not match; the gap between them WAS the finding. ALWAYS diff (advisory-claim) minus (actual-code-change); when a fix targets the mechanism's by-product rather than its root, the root persists.

Lesson (reinforced): a multi-fix security RELEASE is a cluster - audit ALL of it.

PyJWT 2.13.0 bundled 5 fixes. cycle242 found #4 (ftp-redirect SSRF) incomplete; cycle244 found #5 (kid DoS) incomplete. Two of five point-fixed narrowly. When ONE fix in a bundled release is incomplete, raise the prior that the others are too (same author, same release, same haste) and check each. (fix #1 HMAC key-format guard also has an edge gap - JWK-Set JSON + raw DER - logged, not staged: low prevalence.)

Lesson (honesty): pre-empt the "by-design" rebuttal with the indefensible sub-case.

Refresh-on-unknown-kid is defensible as key-rotation handling - ONCE. The SAME kid repeated against an unexpired cache can never succeed -> pure amplification, indefensible. Find the sub-case the maintainer cannot wave away as intended behavior, and lead the report with it.

Method note: empirical DoS proof = a hit-COUNTING server, not a timing claim. Count outbound requests

triggered per attacker action; show the ratio (N attacker reqs -> N backend fetches) and the no-decay case (repeat -> still fetches). Cheap, deterministic, cost-sane (docker python + in-proc http.server).