feat: enhance JWT algorithm confusion skill with ES256, sig2n, nonce reuse, deserialization RCE

[YVORYU]

Enhancement: JWT Algorithm Confusion Attack Skill

This PR significantly enhances the existing exploiting-jwt-algorithm-confusion-attack skill from v1.0.0 to v2.0.0, adding 5 new attack vectors, a full reconnaissance phase, executable helper scripts, and deep-dive reference files.

What's New

Category	Original (v1.0.0)	Enhanced (v2.0.0)
Attack vectors	5 steps	10 steps (Steps 0-9)
ES256 confusion	Not covered	Full coverage (4 EC key formats)
ECDSA nonce reuse	Not covered	Detection + private key recovery
sig2n (public key derivation)	Not covered	Docker tool + automated testing
JWT deserialization RCE	Not covered	Jackson enableDefaultTyping exploitation
KID path traversal (known files)	Only /dev/null	hostname, /proc/version, uploaded files
JKU attack closure	Payload only	Full: diagnostics, keypair, JWKS hosting, forge
HS256 brute-force	Not covered	hashcat/john/python + wordlist
KID SQLi	Listed payloads only	Two-stage attack (detect, exploit)
Reconnaissance phase	None	Step 0: endpoint discovery, credential hints, decision tree
Reference files	0	5 deep-dive reference files
Helper scripts	0	agent.py (500+ lines, 15 CLI commands)
Library/CVE mapping	None	14 libraries mapped to CVEs

Files Changed

• SKILL.md — Rewritten with 10-step workflow, decision tree, CVE mapping table
• scripts/agent.py — New: executable agent for all attack vectors
• references/recon.md — New: target reconnaissance and token acquisition
• references/header-injection.md — New: JKU/JWK/X5U/X5C/KID injection details
• references/bruteforce-sqli.md — New: HS256 brute-force and KID SQLi chains
• references/advanced-attacks.md — New: ES256, nonce reuse, sig2n, deserialization RCE, path traversal
• references/api-reference.md — New: quick-reference tables for all vectors

Compliance

• Follows CONTRIBUTING.md skill quality checklist
• Frontmatter: name (kebab-case), description with discovery keywords, domain/subdomain, tags, version, author (mahipal), contributors (YVORYU), license, nist_csf, mitre_attack
• Markdown sections: When to Use, Prerequisites, Workflow, Key Concepts, Tools & Systems, Common Scenarios, Output Format
• Original author preserved, enhancement contributor added

[mukul975]

Genuinely useful expansion — the recon phase and the sig2n routing are additions I want. Blocking on the CVE citations and one function that cannot execute.

CVE-2022-23529 is Rejected at NVD. The record reads "DO NOT USE THIS CANDIDATE NUMBER ... The issue is not a vulnerability." SKILL.md:332 cites it as live guidance and describes it as "alg:none, key confusion, jku", where the underlying GHSA is RCE via a caller-controlled secretOrPublicKey. Please remove or re-cite it.

Two more mislabelled:

• CVE-2015-9235 — NVD: jsonwebtoken < 4.2.2, RS/ES to HS key confusion. This PR calls it "node-jws alg:none bypass" at :328, heads a section "KID Empty File / Empty Key Bypass (CVE-2015-9235 family)" at :222, and attaches it to a PyJWT empty-key behaviour at :315. Three different claims, none matching the record.
• CVE-2017-11424 — NVD: PyJWT <= 1.5.0 PEM-detection bypass enabling key confusion. Called "alg:none + empty-key fallback" at :329. Version range is right, description is not.

In a skill whose whole job is teaching people which JWT flaws are real, a rejected CVE presented as live undermines the rest of the content. Worth a pass over every CVE in the PR.

scripts/agent.py:356 cannot run. forge_es256_confusion() calls public_key.public_bytes(Encoding.Raw, PublicFormat.UncompressedPoint), which raises ValueError — verified against cryptography 45.0.3, where Raw + UncompressedPoint raises and X962 + UncompressedPoint returns the expected 65 bytes. The formats list is an eager literal, so the entire ES256-confusion path raises on every call.

Smaller items:

• The rewritten description drops the "use when" clause, which fails the description linter. The version on main passes.
• This is CONFLICTING and reverts the 2026-08-02 description rewrite. Please rebase and keep main's description.
• recover_ecdsa_private_key() hardcodes hashlib.sha256 while the section advertises ES384/ES512, and never truncates z to the leftmost bitlen(n) bits.
• default_backend() is called in the second code fence while its import sits only in the first, so copy-pasting that block raises NameError.
• The rewrite deletes CVE-2024-54150 (cjwt). Worth restoring, and CVE-2024-33663 (python-jose algorithm confusion) is a good addition while you are in there.

[YVORYU]

Thanks for the thorough review — all items are addressed in a1e1f76, and the branch is now rebased onto current main (mergeable, no conflict).

CVE citations — every CVE now matches its NVD record:

• Dropped rejected CVE-2022-23529 entirely.
• CVE-2015-9235: fixed all three mislabels. It now appears once, correctly, as jsonwebtoken (node) < 4.2.2 | RS/ES → HS key confusion. Removed from the Step 6 heading, the Key Concepts row, and the old node-jws alg:none row.
• CVE-2017-11424: corrected to PyJWT < 1.5.1 | PKCS#1 PEM public key accepted as HMAC secret (key confusion), step mapping moved from 4,6 to 3.
• Restored CVE-2024-54150 (cjwt < 2.3.0, HMAC vs RS/EC/PS signature confusion) and added CVE-2024-33663 (python-jose <= 3.3.0, algorithm confusion with OpenSSH ECDSA keys), both per their NVD descriptions.

forge_es256_confusion() — Encoding.Raw → Encoding.X962. Verified on cryptography 46: Raw + UncompressedPoint raises ValueError, X962 + UncompressedPoint returns the expected 65-byte point. The --forge-es256 CLI path now produces all 4 format variants end-to-end. The same fix is applied in advanced-attacks.md §9a and the api-reference.md table.

recover_ecdsa_private_key() — now selects hash and curve order from the tokens' alg header (ES256/ES384/ES512 → SHA-256/384/512 + P-256/384/521), and truncates z to the leftmost bitlen(n) bits per FIPS 186-4 instead of % n. Round-trip tested with fixed-nonce signatures on all three curves: each recovered key matches the original private key exactly (and re-verifies against the library).

Smaller items:

• Description restored to main's 2026-08-02 activation-rubric text — byte-identical to upstream/main, passes tools/validate-skill.py.
• default_backend import added to the §9b recovery snippet so it runs standalone; the z-truncation rule is now documented in the formula section too.
• SKILL.md Step 9b wording updated to ES256/ES384/ES512.

Note on CI: the check on the new head shows action_required — that's the fork-PR workflow approval gate rather than a failure; the frontmatter validator passes locally with the same script. Happy to iterate further if anything else comes up.

[mukul975]

Thanks for a thorough revision — I checked every item against the file at a1e1f76d rather than the summary, and all nine things I raised last round are genuinely fixed.

CVE-2022-23529 is gone. Zero occurrences across all seven files, and I did a second loose pass for a bare 23529, for GHSA/PYSEC/Snyk ids, and for vuln-DB URLs in case it had been re-cited in another form. Nothing. That was the one I cared about most — NVD has it as Rejected ("The issue is not a vulnerability"), and presenting it as live guidance is the worst failure mode for a skill whose job is telling people which JWT flaws are real. CVE-2015-9235 and CVE-2017-11424 are now correct, single-occurrence, and their bounds match NVD and OSV exactly. CVE-2024-54150 is back and accurate — its NVD status reads Deferred, which is an enrichment-backlog state and not a rejection, and GHSA-9h24-7qp5-gp82 is not withdrawn. CVE-2024-33663 is a good addition and checks out.

The ES256 path is alive again. agent.py:356-357 uses Encoding.X962 with PublicFormat.UncompressedPoint, and Encoding.Raw appears nowhere in the skill any more. I confirmed against cryptography 45.0.3 that all four entries in the formats literal are legal for an EC key, so the eager list evaluates cleanly and the function actually runs.

The ECDSA recovery is correct, and you fixed it the right way. agent.py:386-393 selects the hash from the token's own alg header instead of swapping in one more constant, and :450-455 implements the FIPS 186-4 truncation properly — excess = len(digest)*8 - n.bit_length(), shift only when positive, so SHA-512/P-521 correctly keeps the whole digest. I checked the three curve orders against an independent implementation rather than eyeballing them; they match. Generalising the dispatch is the version that stays correct, and having the identical fix land in advanced-attacks.md is exactly what I was hoping for after last time. The r1 != r2 guard is there and the half-split signature parse is right for RFC 7515 fixed-width R‖S.

The description is byte-identical to main's, "Use when" clause intact, and the 2026-08-02 rubric rewrite survives verbatim. That fix mattered more than it looks: this slug is grandfathered only under desc-has-negative-trigger, not under desc-has-use-when, so had the clause stayed dropped it would have been a hard new failure rather than an inherited one. No mass revert — zero overlap between your seven files and main's changed files since your base.

I rebuilt the merge locally and ran the full workflow: validate-skill.py 818/818, validate-agentskills.py 818/818, generate-index.py --check OK, lint-descriptions.py new failures 0, detect-collisions.py --max-unreviewed 55 exit 0 with this skill in no colliding pair, plus the two inline steps. Every number matches a main-only run, so nothing moves a baseline. No index.json needed — the description is unchanged.

---

Now the part nobody had looked at. Four of these files are new and I read them on their own terms, then went back through api-reference.md and scripts/agent.py because the same content lives there too. Before the list, two things I want to be fair about: I ran a per-fence undefined-name scan and my first read was that several fences were broken, then I ran the same scan against main's SKILL.md and all four of its fences have the identical shape. Fences continuing from the Step 0 preamble is this skill's existing convention, not something you introduced, and I'm not holding new files to a standard the file they were split from doesn't meet. Likewise attacker.com — main already ships it in SKILL.md and api-reference.md, so that's inherited.

Four things I'd like before merge:

1. A cracked binary secret silently forges a token that fails. bruteforce-sqli.md:40 returns secret.decode(errors='replace') and :61 re-encodes with found.encode(). Any non-UTF-8 secret becomes U+FFFD and re-encodes to different bytes, so a key you genuinely cracked yields a token that doesn't verify. Line 65 already warns "Secret may be binary." Return the bytes at 40, sign with found at 61, decode only for the print at 57. This turns a real finding into a false negative, which is the worst way for a pentest helper to fail.

2. to_bytes(256) on a caller-supplied key — in two files. header-injection.md:142 and agent.py:247, both inside forge_jwk_embedded_token(payload_dict, private_key, ...) where the key comes from the caller. A 4096-bit key raises OverflowError; a 1024-bit key gets 128 leading zero bytes, breaking RFC 7518's minimal-octet requirement for n and producing a JWK the server rejects. It's benign at header-injection.md:60 and agent.py:168 only because key_size=2048 is pinned two lines above each. (pn.n.bit_length() + 7) // 8 at both sites.

3. Two helper dependencies with no upstream definition anywhere. bruteforce-sqli.md uses ej() and b64url() at lines 60, 62, 86, 88, 103, 105; they're defined only in header-injection.md:16-17 and nowhere else in the skill. SKILL.md:100-101 routes HS256 targets straight to Step 7/8 without ever passing through header-injection.md, so that reader has genuinely never seen them. And header-injection.md itself uses json at :17, base64 at :16, requests at :29 and serialization at :178 while importing none of them — its first fence is already broken, so every later fence inherits it. This is the only place the fence convention actually fails; a complete preamble in the first fence of each fixes it.

4. api-reference.md:142-146 uses a live company's domain as the victim. The JKU/X5U bypass catalog hardcodes target.com — https://target.com@attacker.com/jwks.json, https://TARGET.COM/jwks.json, three more. That's Target Corporation's real domain, in the victim slot of payloads someone will copy verbatim. Your own parallel catalog at header-injection.md:188-200 gets this right by deriving target_host from BASE_URL; please mirror it here. This is new in the PR — main's api-reference.md doesn't have it.

Should fix, but I won't hold the merge on them alone:

• Third-party paste services as attack infrastructure, in three places: header-injection.md:70-89, api-reference.md:104, 118-119, and agent.py:182-201, which carries the identical host_jwks(). The API calls are accurate — the objection is that this makes two unrelated operators' servers the infrastructure for someone else's engagement, puts client-adjacent material on an unauthenticated public blob store with no deletion step, and leaves engagement evidence somewhere the tester can't reach. Only the public half goes up, so nothing is compromised. Option C in your own table at line 101 — ngrok plus a local server — is the better default.
• /api/flag as the general success oracle. Gone from SKILL.md, still in bruteforce-sqli.md:89, 107, header-injection.md:30, 124, recon.md:27, api-reference.md:31 — and, most importantly, as the default parameter value of jku_diagnostic at agent.py:208, so it's what runs unless the operator overrides it. SKILL.md already uses /users/me throughout.
• The JKU status-code heuristic is stated as a conclusion, in header-injection.md:36-48, api-reference.md:111-112 and SKILL.md:314. No general JWT stack guarantees 500→fetched / 502→connection failed / 401→ignored; an ignoring server, a fetch-and-fail server and one that 400s on a malformed header can all answer 401. Your line 40 has the signal that generalises, and you already have the right shape in agent.py:208-234, which returns raw {status, time, body} with no interpretation layer. Demote the codes to "compare against a control request."
• Two mapping-table rows. PyJWT < 2.0.0 | RS256→HS256 key confusion | — understates the range — and I nearly let it through on the reasoning that 2.0.0 is where algorithms became required. That's true and beside the point: CVE-2022-29217 runs 1.5.0→2.4.0 and its precondition is an app passing get_default_algorithms(), which a required argument does nothing to prevent. Suggested: | PyJWT >= 1.5.0, < 2.4.0 | Key confusion via non-blocklisted public key formats | CVE-2022-29217 | 3 | — same bound at advanced-attacks.md:77, so both files. And express-jwt (node) < 6.0.0 | alg:none bypass | — is mislabelled: there's exactly one advisory in existence for that package, CVE-2020-15084 with range [0, 6.0.0), so the bound can only have come from it, and it's the algorithms allowlist going unenforced with jwks-rsa, not alg:none. Suggested: | express-jwt (node) <= 5.3.3 | algorithms not enforced with jwks-rsa secret → algorithm confusion / auth bypass | CVE-2020-15084 | 3 |.
• recon.md:70-83. r.json() at 74 is unguarded, line 76 returns the whole response dict from a function documented as "obtain a valid token," and the retry at 81 is unbounded recursion around a blocking 600-second sleep.
• No authorisation line in any of the five reference files, though SKILL.md has one at 60-69 and — the reason this is nearly free — agent.py already carries it three times, at 9, 503 and 530. Since SKILL.md:72 has the agent read references on their own, one line each pointing back to the Legal Notice.

Smaller notes, take or leave: advanced-attacks.md:188 hardcodes SECP256R1() six lines below the function you just generalised to ES384/ES512 (the alg→curve map is already at line 66). The EC format table at 20-26 lists five and line 43 says "all 5" while the list at 44-53 has four — the missing x‖y form is a distinct HMAC key, so it's a missed vector, and api-reference.md:262-267 lists four, so the two references disagree. SKILL.md:161's "base64 body only" slice keeps the END line and should be [1:-2] — that off-by-one is inherited from main's line 198 and your version is an improvement, since main left it as a list of str that raises TypeError at hmac.new, but as it stands no variant tests the true body-only format. advanced-attacks.md:385 lists /proc/self/environ in "Predictable File Targets," which fails that table's own criterion — it's NUL-separated and not byte-predictable, and if you can read it you take the secret directly. §9d's two payloads use two different Jackson type-id conventions under one heading: line 295 uses @class while the trigger named above it, enableDefaultTyping(), defaults to WRAPPER_ARRAY — the form your next payload at 309 correctly uses; and I couldn't confirm from a primary source that target is the right setter for SimpleJndiBeanFactory, so please re-derive rather than take my word either way. bruteforce-sqli.md:82 omits the trailing space after -- that your own exploit at 99 includes, so the probe can false-negative on MySQL. Lines 51-53 load all of rockyou under a heading that says "small wordlists." "RS256-PSS" (advanced-attacks.md:268, api-reference.md:304) should be PS256. advanced-attacks.md:209-212 is right about the GCD but should mention that e has to be known or guessed. And 13 tags makes this the most-tagged skill in the repo — nothing enforces a maximum, but trimming would keep it in line.

Two of my own, not yours. api-reference.md:68 has hmac.new(public_key_bytes, f"{header}.{payload}", hashlib.sha256) — the message is a str, which raises TypeError, and .digest() is missing; and base64url is called at 66, 67, 69, 86 and 87 without being defined. Both are lines 36-39 of the file on main and the diff only moved them. Your agent.py:130 and SKILL.md:154 do the HMAC correctly. Fix them here if convenient or leave them for me; neither is holding this up. The attacker.com usage is the same story — if you clean it up here, note that main needs the same edit or it'll come straight back.

On the rebase, a correction to the record rather than a request. Your base predates the tooling batch, so tools/ on your branch has 4 files where main has 11 — lint-descriptions.py, detect-collisions.py, generate-index.py and the baselines simply aren't there. Three of the seven gate steps reference tools you've never had and couldn't have run locally. Nothing to fix: the workflow checks out refs/pull/111/merge with no explicit ref and picks up main's tooling, and I've verified the gates pass on that merge.

What happens next: fix the four numbered items above and I'll merge. CI has never actually run on this head — check-runs is 0 and the combined status is pending, which is where the UNSTABLE state comes from — so everything above is my local reproduction; I'll approve the workflow run so the real thing executes alongside your next push. Take or leave everything under "smaller notes." I did not run any of the code in this PR; every runtime claim above I checked by running my own equivalent calls.

---

[YVORYU]

All four blocking items are fixed at 41957a7, along with everything under "should fix" and the smaller notes. I also rebased onto 1b3f6b2 so the branch now carries main's tooling batch, and ran the full gate suite locally against this exact head: validate-skill.py --all 818/818, validate-agentskills.py --strict clean, generate-index.py --check OK, lint-descriptions.py new failures 0, detect-collisions.py --max-unreviewed 55 exit 0 with this skill in no colliding pair, no duplicate names. Same numbers you got on the main-only run. The description is untouched and index.json needed no change.

Blocking items

1. brute_force_hs256 returns bytes in both copies — bruteforce-sqli.md and agent.py (the agent's copy had the identical bug: return secret.decode(errors="replace")). Decode now happens only at the print; re-signing uses the raw found. Runtime-verified: a token signed with b"\xff\xfe\x00binary-\x80secret" cracks to the exact bytes and re-signs to the identical token.

2. (pn.n.bit_length() + 7) // 8 at both forge_jwk_embedded_token sites — header-injection.md and agent.py — and the same derivation applied to generate_attacker_keypair_and_jwks in both files for consistency. Runtime-verified with 1024/3072/4096-bit keys: no OverflowError, n decodes to minimal octets with no leading zero byte, and the forged token's signature verifies against the key recovered from the embedded JWK.

3. Complete preamble in the first fence of both files: bruteforce-sqli.md imports hmac/hashlib/base64/json/os/time/requests and defines b64url/ej locally; header-injection.md:16-20 does the same, so every later fence in both files resolves its names.

4. api-reference.md's bypass catalog is now the same BASE_URL-derived block as header-injection.md — target.com is gone. Your two own items are in as well: the Step 3 fence encodes the hmac message, calls .digest(), and defines base64url before first use (the None-algorithm fence below it reuses the helper). attacker.com → attacker.example.com throughout this PR; noted that main still carries it in SKILL.md and api-reference.md, so it would come straight back on any future sync — I can send that as a separate one-line PR against main if you want it from me.

Should-fix items — all done

• Paste services: ngrok + local server is now the default presentation in header-injection.md §5b (restructured around it, with the reasoning), api-reference.md, and agent.py's host_jwks docstring carries the same discouraged-default warning. The services remain documented as options.
• /api/flag → /users/me everywhere, including jku_diagnostic's default parameter.
• JKU status-code heuristic demoted to control-request comparison in SKILL.md, api-reference.md and header-injection.md — the codes now appear only as "often 500/502" examples of how a probe may differ from the control.
• Both CVE rows replaced with your suggested bounds. I re-verified each against NVD before citing rather than taking either of our word for it: CVE-2022-29217 is >= 1.5.0, < 2.4.0 with the get_default_algorithms() precondition; CVE-2020-15084 is <= 5.3.3, algorithms unenforced with a jwks-rsa secret.
• recon.md: r.json() guarded, login returns the token rather than the response dict, and the rate-limit retry is bounded at 3 attempts.
• Authorization line at the top of all five reference files, pointing back to the Legal Notice.

Smaller notes — all done

• Curve selection generalised (from the alg header, six lines below the generalised function); x‖y added as format 4 in api-reference.md — and since the disagreement you flagged was between references, also as the 5th entry in agent.py's forge_es256_confusion; [1:-2] slice in SKILL.md and api-reference.md; /proc/self/environ dropped from the file-targets table (cmdline kept — same NUL-separator caveat applies but it doesn't fail the second half of your criterion the way environ does, since reading it doesn't hand you the secret); trailing space after -- in both SQLi probes; rockyou load annotated (~14M entries, hashcat preferred); PS256 not "RS256-PSS"; tags trimmed 13 → 9.

• §9d: rather than re-deriving whether target is the right setter for SimpleJndiBeanFactory, I traced it through Spring's source. SimpleJndiBeanFactory's concrete setter is shareableResources (String[]); the JNDI lookup fires when PropertyPathFactoryBean resolves targetBeanName through the factory's getBean(). The payload set is now built on that: JdbcRowSetImpl WRAPPER_ARRAY as the primary (JDK built-in, verified against marshalsec's Jackson harness), the Spring chain as the documented alternative with the correct setter, and a note that As.PROPERTY configs use the @class envelope. api-reference.md's copy of the payload is the JdbcRowSetImpl form.

On the rebase record: correct, and now moot in one direction — I fetched and rebased onto 1b3f6b2, so the branch has the full 11-file tools/ and I ran the three gates I'd never had locally. My four commits touch only the seven skill files, zero overlap with main's changes since either base.

As before I ran none of this against a live target — every runtime claim above is my own local equivalent call. This push should trigger the workflow; looking forward to seeing the real CI run alongside your approval.

[mukul975]

Thanks for another careful round — most of this landed, and it landed cleanly. Head reviewed: 41957a7e.

Fixed, checked against the files rather than the description:

• HS256 brute force preserves raw secret bytes end to end, in both references/bruteforce-sqli.md and scripts/agent.py. The function returns bytes, decoding happens only for display, and re-signing consumes the raw value. I traced every consumer of the return value in agent.py, not just the re-signing one.
• The RSA JWK length bug is gone everywhere. All eight conversion sites use (bit_length()+7)//8. Worth noting main's SKILL.md:297 carried the same to_bytes(256,'big') and the block is simply gone at head rather than left behind as a stale copy — that is the drift problem we have hit twice, handled correctly this time.
• No real company domain anywhere. target.com and attacker.com both return zero hits across all eight files. api-reference.md derives the victim host from BASE_URL with an explicit guard comment; attacker slots are attacker.example.com. I swept for any real-looking host and found only the LICENSE's apache.org and the JWKS-hosting services, which header-injection.md already steers away from.
• The ES256 fifth key format in the tip commit is correct, and I want to call it out since nothing in my last review asked for it. X9.62 uncompressed is 0x04||x||y, so x962[1:] is a genuinely distinct HMAC key — and you changed it in agent.py, advanced-attacks.md:28, api-reference.md:289 and SKILL.md:276, so no stale "4 formats" survives. That is the script/reference drift closed in the other direction, unprompted.
• /api/flag and .get('flag') are gone, jku_diagnostic now defaults to /users/me, the JKU status-code heuristic is properly demoted to a control-request comparison in all three files, and recon.md has the JSON guard, the token return and the bounded retry.

I also checked the ECDSA nonce-reuse math rather than taking the revision on trust: k = (z1-z2)/(s1-s2) mod n and d = (s1*k - z1)/r mod n are right, the P-256/P-384/P-521 orders are the real values, and the FIPS 186-4 truncation guard correctly leaves the digest unshifted for ES512, where SHA-512 is shorter than the 521-bit order. Both copies agree.

CVE table — all six rows against NVD directly. jsonwebtoken < 4.2.2, PyJWT < 1.5.1 (NVD says "1.5.0 and below" — equivalent), PyJWT >= 1.5.0, < 2.4.0, python-jose <= 3.3.0, express-jwt <= 5.3.3 (and the revised class — unenforced algorithms allowlist with jwks-rsa rather than alg:none — matches the NVD description). The one I cannot confirm independently is cjwt < 2.3.0 (CVE-2024-54150): NVD carries no version range for it at all. If you have the upstream advisory link, add it beside the row and I will take it.

Three things before merge, and the first is the same defect class as last round in the file that round did not touch.

1. Four Python blocks in references/advanced-attacks.md are short an import. I mapped every fence and every use site:

• fence 34–79 declares its own imports at 35–38 but omits requests, used at 68 and 76. The only import ... requests in the file is line 246, 178 lines later.
• fence 135–199 imports only hashlib, then uses json.loads and base64.urlsafe_b64decode at 152–153.
• fence 359–376 imports base64, json and uses requests at 372.
• fence 414–452 uses time.time() at 444 and requests at 448. time is imported nowhere in the file — the word appears exactly once, at the use site.

Each is a NameError on copy-paste. Extending each block's own import line closes it:

:35   import hmac, hashlib, base64, json, requests
:136  import hashlib, json, base64
:360  import base64, json, requests
:415  import hmac, hashlib, base64, json, time, requests

I ran the same fence-by-fence check over the other five markdown files and they are clean — only operator-supplied runtime values remain unbound there, which is fine.

2. host_jwks still posts to a third party on the default path, in two files. The docstring is exactly right ("Discouraged default… Prefer ngrok + a local server you control") and the prose in header-injection.md §5b is the shape I wanted. But the code underneath is unchanged: agent.py:189 unconditionally POSTs to jsonblob.com, falling back to npoint.io at :204 — no parameter, no branch, no gate — and --host-jwks (help text at :531) still reads "Generate keypair and host JWKS, print URL."

The same function, same docstring, same unconditional POST, is also live at references/header-injection.md:112-134, directly beneath the "Why local-first" block that tells the reader not to do it. That is the copy most people will paste. Both need the same change: host_jwks(jwks, local_dir=None, allow_third_party=False) with a local branch that writes jwks.json and prints the python -m http.server / ngrok http lines, raising unless allow_third_party=True, plus a separate --host-jwks-third-party on the CLI. Only the public half of a throwaway keypair goes up, so nothing is compromised — the objection is putting an unrelated operator's infrastructure into an engagement with no deletion step, and right now that is still the default in both places.

3. '"success":true' survives at references/header-injection.md:160. Every other success check in the PR keys off the status code alone. This one still reads:

if r.status_code == 200 and '"success":true' in r.text:

Why it matters more than its size suggests: the fix commit did edit this block — the request two lines above is now /users/me and the print below lost its .get('flag') — and left the conjunct standing on the untouched line between them. Against a target returning {"username":"admin","role":"admin"} with a 200, a successful JKU forgery reports as a failure, and line 165 sends the reader on to 5d. That is a false negative on the highest-severity finding the skill produces. Drop the conjunct and print r.text[:200] for the operator to judge.

Worth folding in while you are there, none blocking:

• agent.py:608 writes the cracked secret into the JSON report as found.decode(errors="replace") — lossy for precisely the non-UTF-8 case we just fixed. The faithful value only reaches stdout via {found!r}. A secret_hex or secret_b64 field alongside it closes that.
• agent.py:601 and bruteforce-sqli.md:74 load wordlists in text mode with errors ignored. rockyou.txt is largely latin-1, so non-UTF-8 candidates are mangled before they are ever tested — meaning the binary secret the fix now handles still cannot be found from a file. Read the wordlist in binary and split on newlines; the function already accepts bytes.
• agent.py:662-663: safe = {k: v for k, v in report.items()} under the comment "Don't print full report if it contains private keys" is an identity copy that filters nothing. Worse, :644 prints the target's recovered ECDSA private key unconditionally, --output or not, and :573's "Private key saved (in report)" implies it went somewhere safer than stdout. Either actually drop the key material from the printed copy, or delete the comment and say plainly that the report carries it.
• jku_diagnostic sends three jku probes but never the no-jku control, so the script gives no baseline for the comparison the three docs now mandate. Add it as a fourth entry returned as results["control"].
• recover_ecdsa_private_key guards r1 != r2 but not s1 != s2 in both copies (agent.py:460, advanced-attacks.md:171), so --token t1,t1 reaches pow(0, -1, n) and surfaces "base is not invertible" instead of "these tokens are identical." (Also worth stating a Python 3.8+ floor somewhere — pow(x, -1, m) needs it.)
• RS256 format counts now disagree three ways: SKILL.md:154 says four, api-reference.md:80-89 tables six, and forge_hs256_with_public_key tries one. Pick the api-reference six and make the other two agree, the way the ES256 five now do. (SKILL.md:186 also says "4 signature variants" above a list of three.)
• The GitHub Gist row needs the same annotation the other two got (header-injection.md:104, api-reference.md:135) — on your own stated grounds it is the worst of the three: permanent, and tied to a named account.
• advanced-attacks.md:383, "JNDI lookups are blocked by default in modern JDK (>= 8u191)", is too broad and contradicts this file's own blind-detection test at 359–376, which depends on the lookup firing. 8u191 set com.sun.jndi.ldap.object.trustURLCodebase=false, disabling remote codebase class loading; the lookup still happens. The TemplatesImpl advice that follows is right — just fix the premise.
• recon.md:80 hardcodes data.get("success") and data.get("token") in the one file whose argument is that real targets do not match hardcoded shapes; data.get("token") or data.get("access_token") is safer. And §0c/§0d still carry Chinese-CTF credential-hint regexes at :60 and :65-68 — either drop them or label the section lab-specific.

On process, one correction to something I said last round: we have no CI running on PR branches here, so "all checks green" was never the right phrasing. What I actually ran, locally on the merged tree: validate-skill.py --all 818/818, validate-agentskills.py --strict clean, generate-index.py --check current, lint-descriptions.py zero new failures, detect-collisions.py unchanged from main's baseline. The branch is current — main's tip is the merge base, 4 ahead and 0 behind — and all seven changed files are inside the skill directory. Worth saying plainly that none of those validators lint Python inside markdown fences, so they would not have caught the four import blocks either way. That is on review, not on you.

Fix those three and I will merge.

[YVORYU]

All three blockers and every non-blocking item are fixed at 08f867b0 (clean fast-forward from 41957a7e, 7 files, all inside the skill directory).

The three blockers:

1. All four advanced-attacks.md fences now declare their own imports at the exact lines given — requests at :35, json, base64 at :136, requests at :360, time, requests at :415. Re-ran the fence-by-fence audit over all six files: clean, only operator-supplied names remain unbound.
2. host_jwks in both copies (agent.py, header-injection.md §5b) now defaults to writing jwks.json locally and printing the python -m http.server / ngrok http serving lines; third-party paste hosting requires allow_third_party=True, and the CLI gained a separate --host-jwks-third-party flag with updated --host-jwks help text.
3. The '"success":true' conjunct is dropped — the JKU closure keys off the status code alone and prints r.text[:200] for the operator to judge.

Non-blocking items, all in: secret_hex beside the lossy decode; binary wordlist reads in agent.py and bruteforce-sqli.md; the no-op safe copy removed with plain language about what the report carries, and the recovered ECDSA key prints to stdout only when there is no --output; jku_diagnostic now sends the no-jku control as results["control"]; the s1 == s2 guard in both copies plus the Python 3.8+ floor; RS256 format counts aligned on the api-reference six (SKILL.md Step 3 derives DER/PKCS#1 from the loaded key; agent.py tries all six); "4 signature variants" → 3; the Gist row annotated in api-reference.md; the JNDI premise corrected (8u191 blocks remote-codebase loading, not the lookup itself); recon.md reads token or access_token and 0c/0d are labeled CTF/lab-only; and the cjwt row now carries the upstream advisory: GHSA-9h24-7qp5-gp82 — xmidt-org/cjwt, affected v2.2.0, patched v2.3.0, matching the < 2.3.0 row.

Two things worth flagging honestly:

• The six-format change in forge_hs256_with_public_key had left the --forge-hs256 consumer doing forged[:60] on a list — a guaranteed TypeError on every run. Fixed, and caught by executing the code rather than reading it.
• Tests: run locally only — a smoke test covering all six HS256 format tokens (each re-verified against its HMAC key), the identical-token guard, binary-secret brute force, and CLI end-to-end where --host-jwks makes zero network calls on the default path; validators on the merged tree: validate-skill 818/818, agentskills --strict clean, index current, zero new lint failures, collisions unchanged at 55. Nothing is committed — the skill has no test infrastructure and I did not want to add files beyond this round's scope.

[mukul975]

Third round checked, and I ran things rather than reading the diff.

Blocker 2 is done. I patched requests.{post,get,put,request,head,patch,delete}, Session.request, socket.socket, create_connection and getaddrinfo with raising counters and ran --host-jwks end to end: zero network attempts, jwks.json written locally, and exactly two POSTs (jsonblob, npoint) only under --host-jwks-third-party. That holds because import requests at agent.py:224 sits after the early return at agent.py:221-222, so the default branch never loads the HTTP client at all. Blocker 3 is done too — the '"success":true' conjunct is gone from the tree, header-injection.md:173-175 keys off the status code alone and prints r.text[:200], and all eight forged-token oracles are now consistent (SKILL.md:168, :200, :252; advanced-attacks.md:77, :272, :457; bruteforce-sqli.md:129; header-injection.md:173).

Blocker 1 I have to take back, and it is mine, not yours. Your four import lines are there — advanced-attacks.md:35, :136, :365 and :422, note :365 and :422 rather than the :360 and :415 in your comment — and nothing was deleted to fake them; the only removals in that file are the four superseded imports and the two JNDI prose lines. But I should not have asked for it. These files are written as one continuous session and they say so: header-injection.md:18, bruteforce-sqli.md:35, api-reference.md:68, plus the provenance comments at header-injection.md:22 and bruteforce-sqli.md:42. I wrote a module-level simulator that runs each file's fences in document order and SKILL.md comes back completely clean — all fifteen of its flagged fences resolve. My checker measures per-fence self-containment, which is not the standard these documents set. So nothing more is owed there. If you want the tidy-up: advanced-attacks.md:116 uses base64 in the one fence of that file with no import while five of its siblings now declare theirs, so one line at :113 makes it uniform. That is the whole ask.

That checker also has a blind spot that cost me something real. It binds def parameters fence-wide, so it never saw header-injection.md:170, token = forge_jku_token(ap, jwks_url, attacker_priv) — jwks_url is bound nowhere in the skill, only as a parameter at :156. Section 5c raises NameError on its first iteration for anyone reading top to bottom, and it has now survived three rounds. Do not bind it to host_jwks()'s return: on the default branch that is a filesystem path (agent.py:214, :221-222). Bind it to the URL you actually serve the file from, the way agent.py takes it from --forge-jku at agent.py:637.

The thing that worries me most is not an import. recover_ecdsa_private_key returns a wrong key, silently, with status RECOVERED and a [CRITICAL] banner, whenever exactly one of the two r-colliding signatures is low-s normalised. I built a P-256 rig with a known d and a shared nonce and called the shipped function: baseline recovers exactly, flipping s2 to n - s2 returns garbage that passes every guard including the new s1 == s2 check, and over forty random pairs from a normalising signer 22 came back wrong. agent.py:528-529, mirrored at advanced-attacks.md:189-191, never validates the candidate, and advanced-attacks.md:200 hands the integer straight to ec.derive_private_key, which accepts any in-range value. Verify d*G == Q against the target public key before reporting RECOVERED, retry the sign combinations if it fails, and report the pair unusable if none verifies. SKILL.md:278 and :286 also need a word change — they call r the nonce, and k and -k produce the same r, which is precisely the case that fails.

Then the library and tool claims. I checked these against source rather than memory. bruteforce-sqli.md:15 says hashcat 16500 auto-detects from the alg header; module_16500.c picks the kernel from signature length, and line 99 carries a comment saying it deliberately does not read the header. An ES256 signature is 86 base64 characters, the same as HS512, so an ES256 token is accepted, cracked as HS512, and exhausts the wordlist reporting nothing — worth saying at :15 and adding to the warning at :10, which currently mentions only RS256. api-reference.md:256 labels -X i as jku injection, but jwt_tool.py:1762 routes it to jwksEmbed, which sets newHead["jwk"] at :794; jku spoofing is -X s -ju. SKILL.md:337's "Java JJWT (all)" is false in every version — MacSigner.java:37-41 rejects a non-SecretKey outright and DefaultJwtParser.java:338-348 rethrows with a message describing this exact attack. SKILL.md:338's go-jose row has no advisory, no fix anywhere in v2.3.1...v2.4.0 (33 commits, all plumbing), and signing.go:133-160 cannot route an asymmetric key to the HMAC verifier. And no version of PyJWT has ever read a jwk, jku or x5u header — I grepped api_jws.py at 1.4.2, 1.5.0, 1.7.1, 2.3.0 and 2.10.1, and PyJWKClient fixes its URI at construction and takes only kid — so drop it from header-injection.md:183, :272 and :273; node-jose belongs on those lines, PyJWT does not. Last one: api-reference.md:88's key.export_key() is a PyCryptodome method that emits SPKI, making it a duplicate of row 0, and on a cryptography key it is an AttributeError. Use public_bytes(PEM, PKCS1), which is exactly what your own agent.py:143-144 already does.

Smaller things worth fixing while you are in there. header-injection.md:5-6 prescribes running 5d first, but 5d needs attacker_priv from 5b:83 and the helpers from 5a's opening fence, so a note naming both sections closes it. header-injection.md:40 asks for a no-jku control that nothing sends and that test_jku_diagnostic at :28 cannot send, since jku_url is a required positional and the key is always present — agent.py:277 does it correctly, so the two copies diverged in this commit. Every forging vector except --forge-none writes token[:60] + "..." to the report (agent.py:623, :637, :643, :649, :655, :683, :720); with the CLI's default payload all six HS256 tokens come out byte-identical and the signature is cut off entirely, so store the full token and truncate only the stdout line. SKILL.md:372 still advertises the --host-jwks output as a hosted URL when it is now a local path, and --forge-jku accepts it unvalidated as jku=".\jwks.json". agent.py:150's split("\n")[1:-2] silently drops the last base64 line for a PEM with no trailing newline, and api-reference.md:86 documents that same idiom. And three branches can raise out of main() before the report write at agent.py:723 — --check-nonce-reuse --token "aaa,bbb" throws IndexError and loses the whole report; a try/finally around the write covers all three.

On gates: I ran all five locally at 08f867b plus the two CI-only steps — 818/818 validate-skill, 818/818 agentskills-strict, index up to date, zero new lint failures, collisions unchanged at 56 pairs against a cap of 55 unreviewed. What they do not cover is almost everything above: they read the SKILL.md frontmatter and its line count, which is seven of the 2,204 lines this PR adds, and nothing opens scripts/ or references/. Also worth flagging that no CI has ever actually executed here — all three workflow runs are fork-PR action_required with zero jobs — so someone needs to approve workflows before any of it counts as a check.

One non-blocking thing: the frontmatter description at SKILL.md:3-8 is unchanged from v1 and still describes only RS256 to HS256, alg:none and header injection, while the body now covers ES256, secret brute-force, kid SQLi, sig2n and deserialisation. It is the only text an agent sees when deciding whether to load the skill. I tested widening it — it lowers this skill's collision scores rather than raising them and drops it out of the lint baseline, so it is safe; just run python tools/generate-index.py and commit index.json alongside.

Next step: fix the ECDSA verification (agent.py:528 and advanced-attacks.md:189, plus the wording at SKILL.md:278/:286), bind jwks_url at header-injection.md:170, and correct the six sourcing errors (bruteforce-sqli.md:15, api-reference.md:88 and :256, SKILL.md:337 and :338, header-injection.md:183/:272/:273). Push those and I will merge; the truncated tokens, the 5a control, the output-contract line and the rest can follow in a separate pass.

[YVORYU]

Fourth-round items are all in at d4ccf42: the ECDSA verification fix, the jwks_url binding, and the six sourcing corrections — plus the items you said could follow in a separate pass (full tokens in the report, the 5a control, the output-contract line, try/finally, the PEM slice), each small enough to land in the same commit. Gates re-run at this head: validate-skill 818/818, agentskills-strict 818/818, generate-index --check OK, lint 0 new failures, detect-collisions exit 0 under the 55 cap.

ECDSA recovery — the silently-wrong-key bug

recover_ecdsa_private_key (agent.py and advanced-attacks.md §9b, kept in sync) now tries all four low-s sign combinations and returns a candidate only when it verifies: (k·G).x mod n == r, plus d·G == Q when the target public key is supplied. A new --public-key input loads the target's EC key for exactly that check; without it the k·G check still runs, and a pair where no combination verifies raises an unusable-pair error instead of returning a number. I rebuilt your rig against the shipped function:

• P-256, known d, shared nonce: baseline recovers exactly.
• Flipping s2 to n−s2 — the case that previously returned garbage passing every guard including the s1 == s2 check: recovers the true key.
• Flipping s1, flipping both, and a negated nonce (k2 = n−k1, the k/−k same-r case): all recover.
• 40 random pairs from a normalising signer: all 40 correct.
• Wrong public key: pair reported unusable. ES384/ES512 with flips: correct. Identical tokens: unusable-pair error, no zero division.

SKILL.md's 9b table row and prose, and §9b, now describe r as the x-coordinate of the nonce point k·G — with the k/−k caveat — not "the nonce".

jwks_url at header-injection.md §5c

Bound to the URL the JWKS is actually served from (http://<your-ip>:8000/jwks.json or the ngrok URL), with a comment stating the point directly: host_jwks()'s return is a filesystem path on the default branch, and the jku value is the serving URL — the same input agent.py takes via --forge-jku, which now refuses a value without :// with a message pointing at --host-jwks.

The six sourcing corrections

• hashcat 16500 (bruteforce-sqli.md): the prerequisite and the fence comment now say the kernel is picked from signature length (43/64/86 chars → HS256/384/512) and that module_16500.c deliberately ignores the alg header; an ES256 token's r||s is also 86 base64 chars, so it is accepted and silently cracked as HS512, exhausting the wordlist with no result. Check the alg header before spending GPU hours.
• jwt_tool (api-reference.md): -X i is labelled jwk header embed (jwksEmbed sets newHead["jwk"]); jku spoofing is shown as -X s -ju <url>.
• Java JJWT (SKILL.md): row dropped from the confusion table, replaced with a short note that MacSigner rejects a non-SecretKey and DefaultJwtParser rethrows with a message describing this attack — not vulnerable, don't spend Step 3 time on it.
• go-jose (SKILL.md + advanced-attacks.md §9a): row dropped; the note records that no advisory exists across v2.3.1…v2.4.0 and the HMAC verifier cannot be handed an asymmetric key.
• PyJWT (header-injection.md): dropped from the jku/jwk rows and the 5d intro — no version has ever read a jwk, jku or x5u header for key resolution, and PyJWKClient fixes its URI at construction and takes only kid. node-jose with CVE-2018-0114 kept where it is accurate.
• api-reference.md key-format row 5: public_bytes(PEM, PKCS1) — what agent.py already emits — instead of the PyCryptodome export_key().

The separate-pass items, included

• Full tokens stored in the report for every forging vector; stdout lines stay truncated. The six HS256 entries now differ in their signatures instead of being byte-identical.
• test_jku_diagnostic() accepts jku_url=None and sends the control (no jku header) as the baseline, matching agent.py's behaviour — the two copies no longer diverge.
• Read-order note at the top: run 5a's opening fence and 5b first; 5c/5d/5e forge with those helpers and attacker_priv.
• SKILL.md output contract: --host-jwks writes jwks.json locally and carries the private key in the report; the jku value is the URL you serve it from.
• [1:-2] → strip then [1:-1] in agent.py, SKILL.md and api-reference.md, so a PEM without a trailing newline keeps its last base64 line.
• Report write moved into try/finally: --check-nonce-reuse --token "aaa,bbb" now produces the report file with the analysis finding instead of dying on IndexError and losing everything.
• advanced-attacks.md's detection fence carries import base64 for uniformity with its siblings — the one-line ask from your Blocker 1 retraction.

Description

Widened as you tested: ES256 confusion, HMAC brute-force, kid SQLi/traversal, sig2n, nonce reuse, deserialisation, with the negative trigger. The skill's collision scores dropped and it left the lint baseline (980 → 979, a shrink); index.json is regenerated in the same commit.

On CI: understood that nothing has actually executed — the three runs are fork-PR action_required with zero jobs. The numbers above are the same gates the workflow would run, at this head; the workflow approval is still needed for them to count on GitHub.

[mukul975]

Fourth round checked. Every one of your six claims held up when I verified it independently, and I want to say that plainly before anything else, because the last two rounds each contained a self-audit that did not survive checking. This one did.

The ECDSA fix is correct, and I proved my test could see the old bug before trusting the new result. I rebuilt the P-256 rig from scratch rather than re-run yours, pointed it at 08f867b0 first and reproduced the round-3 silent-wrong-key case, then pointed the same rig at d4ccf42f: baseline, s1-flipped, s2-flipped, both-flipped, negated nonce k2 = n-k1, and 40 random pairs from a low-s normalising signer — all correct, d*G == Q true throughout. Wrong public key raises unusable-pair; identical tokens raise cleanly with no zero division. ES384 and ES512 with flips also recover, and the FIPS 186-4 guard is right for ES512 (512 − 521 is negative, so no shift).

Two things I specifically went looking for came back clean. The new verification introduces no false negatives — d=1, d=2, d=n-1, k=1, k=n-1 and extreme-s all still recover, so you have not traded a silent wrong answer for a silent "unusable". And the (k*G).x mod n == r check is sound on its own without --public-key: instrumenting all four sign combinations over 360 pairs, exactly two ever pass and they are the k/−k twin, which is algebraically the same d. The mixed combinations produce k_false = (z1−z2)/(s1+s2), uncorrelated with r, and never survive.

And the two copies are genuinely in sync — the first time in four rounds. I extracted the advanced-attacks.md §9b implementation, executed it side by side with agent.py on identical inputs, and got identical keys and identical error strings. The flip loop and both verification blocks are byte-identical; the only differences are the docstring, the inlined header decode, and [alg1] vs [alg]. grep -rn derive_private_key across the skill returns no third copy.

I am still blocking, on two defects that predate this round and that neither of us has been looking at. Both are silent false negatives in agent.py, and by the standard I have been applying all along — a wrong answer the operator cannot see outranks a loud crash — they outrank everything this round fixed.

1. --brute-force cannot crack HS384 or HS512, and reports them as uncrackable. brute_force_hs256 at agent.py:371 takes no algorithm parameter and hardcodes hashlib.sha256 at :384. The call site at :716 never passes args.alg, which you declare at :626 with the help text "Algorithm for KID/brute-force forging". For an HS384 token the target signature is 48 bytes against a computed 32, so the comparison at :385 can never hold.

I signed three tokens with b"secret" — which is COMMON_SECRETS[0], the first entry in your own wordlist — and ran the shipped function:

HS256: secret is b'secret' and IS in the wordlist -> returned b'secret'
HS384: secret is b'secret' and IS in the wordlist -> returned None
HS512: secret is b'secret' and IS in the wordlist -> returned None

Exit 0, no warning, and the report records {"type":"brute_force","status":"NOT_FOUND"} — indistinguishable from a strong secret. analyze_jwt routes every alg.startswith("HS") token here at :95-96, so the operator is sent down this path by the agent's own triage. The second copy at references/bruteforce-sqli.md:50-58 behaves the same way.

What makes this round the right time to fix it: SKILL.md:7-8, the description you widened this round, now advertises "brute-forces weak HS256/HS384/HS512 secrets". Main's description made no HMAC brute-force claim at all, so this round is where the promise starts. Three other functions in the same file — :341, :360, :589 — already carry the correct {"HS256": sha256, "HS384": sha384, "HS512": sha512} mapping, so the fix is mechanical. Please also update bruteforce-sqli.md:10 and :89, SKILL.md:330 and :359, which all assert tri-algorithm support, and bruteforce-sqli.md:32, which gives john --format=HMAC-SHA256 as the only CPU command under a tri-algorithm heading.

2. --forge-jku signs with a keypair it throws away. agent.py:674 generates a keypair under --host-jwks and writes jwks.json from its public half. agent.py:686 then calls generate_attacker_keypair_and_jwks() a second time and signs with that fresh key, while pointing jku at the URL serving the first one. The token cannot verify against the JWKS it advertises. The finding appended at :688 carries only {type, jku_url, token} — no JWKS, no private_key_pem — so the signing key dies with the process and no matching key set can be reconstructed afterwards.

Running --host-jwks --forge-jku http://127.0.0.1:8000/jwks.json produces a token that fails signature verification against the hosted file, and the private key in the report belongs to the other keypair. Both carry kid: attacker-key-01, which makes it look right. SKILL.md:370 sells this exact chain as a Common Scenario and :385-387 describes the two flags as halves of one workflow, so this is a guaranteed 401 against a fully vulnerable target with zero operator error. header-injection.md:182 does it correctly by threading 5b's attacker_priv through, and --forge-jwk is self-consistent — I checked, its token verifies against its own embedded jwk — so this is specific to these two branches in agent.py, not a shared design assumption.

On the sourcing corrections: all six are confirmed fixed. hashcat 16500 really does branch on signature_len 43/64/86 in module_kern_type_dynamic, with an in-source comment saying header matching would be more accurate; the ES256-only scoping is exact, since ES384 at 128 chars falls outside the bound. -X i → jwksEmbed → newHead["jwk"] at jwt_tool.py:794 and -X s -ju → newHead["jku"] at :762. The go-jose drop is correctly scoped — newVerifier is a type switch, only []byte reaches symmetricMac, and the advisory search covers this attack class rather than being a blanket claim. Row 5 is genuinely no longer a duplicate of row 0.

Two caveats on that, both about scope rather than substance. The JJWT note is unbounded, and the MacSigner guard it cites does not exist in 0.1–0.4, so bound it to ≥ 0.5. And the new sentence at header-injection.md:198 says a PyJWT backend is "a dead end for every vector on this page" — but the page covers §5g kid injection, which the application resolves, not the library; your own table at :290 says kid affects "all", 92 lines later. Scope that to 5a–5f.

While you were in that table, four rows next to the ones you fixed are also wrong. I checked these against source because the go-jose and JJWT drops made me want to know what else was sitting there unsupported:

• SKILL.md:344 — Spring Security OAuth < 2.5 | jku/x5u URL injection. There is no jku/x5u code path in any release; JwkDefinitionSource fixes jwkSetUrls in its constructor, and git diff 2.4.2.RELEASE 2.5.0.RELEASE touches nothing under provider/token/store/jwk/, so the bound implies a fix that never happened.
• SKILL.md:345 — Apache CXF < 3.3.4 | jwk header injection. JwsUtils.java is md5-identical at 3.2.0, 3.3.3 and 3.3.4. Inline-jwk is gated on RSSEC_ACCEPT_PUBLIC_KEY, default false, unchanged from 3.2.0 to 4.0.0 — a deployer opt-in, not a version boundary.
• SKILL.md:346 — ruby-jwt < 2.2.0 | alg:none bypass. The allow-list guard is present on both sides of that bound, and 'none' support was added at 2.2.3, so the change went permissive rather than restrictive.
• advanced-attacks.md:83 — node-jose is still listed as an ES256→HS256 confusion target, in the same sentence you edited to remove go-jose. basekey.js:498-503 rejects any alg the key's kty does not support. It belongs on the jwk vector only, where you already have it correctly at header-injection.md:195. There is a live second copy at SKILL.md:341 carrying both that claim and a jose4j jku claim — I scanned the Maven Central sources jars for 0.4.4 through 0.9.6 and "jku" appears exactly once per release, as a constant nothing reads.

Smaller things. api-reference.md:298 still carries the naive recovery formula with no low-s caveat, no k/−k note and no verification step — the third file with the defect you just fixed in the other two; :296 in the same section scopes detection to ES256 alone and calls a shared r a reused nonce. agent.py:760 passes tokens[0], tokens[1] and ignores the (i,j,r) pairs check_nonce_reuse just computed, so with three tokens where 0 and 2 share a nonce it prints "Nonce reuse detected between token 0 and 2!" immediately followed by "Nonces differ — cannot recover key". analyze_jwt at :89 recommends nothing for ES256/384/512 or PS*, and drops Step 3 for RS256 tokens carrying a kid — the commonest real shape — which sits awkwardly against a description that now leads with ES256 and nonce recovery. --forge-none emits one of the fifteen variants SKILL.md:195-204 tells the reader to test. --forge-kid-traversal without --known-content is a silent no-op with an empty findings list and exit 0; parser.error would fix that class. And the description at SKILL.md:7-8 breaks mid-token across the fold — the consumed text contains HS256/HS384/ HS512, and index.json carries it byte-identically, so it ships.

Two corrections to my own last comment. I wrote "collisions unchanged at 56 pairs against a cap of 55 unreviewed". The gate sits at exactly 55, which is the cap, and it sits there on main too — so this PR is collision-neutral, not collision-improving, and "exit 0 under the 55 cap" reads as more headroom than exists. Worth knowing that editing this one description shifted corpus IDF weights and moved 147 unrelated pairs, with 14 now within 0.02 of the cutoff; whoever next touches this frontmatter needs to re-run detect-collisions rather than assume a wording tweak is inert.

On gates and merge order: I ran all five locally on your branch merged into current main and they pass, but they read the frontmatter and a line count — seven lines of the 2,200 this PR touches — and nothing in them opens scripts/ or references/ or lints Python in a fence, so they would not have caught either blocker. Still no CI has executed here; the runs remain fork-PR action_required with zero jobs. Separately, merge-tree against #139 and #140 conflicts on three files — index.json, this skill's SKILL.md, and tools/lint-baseline.json — and both of those PRs rewrite this description to different text. That is mine to sequence, not yours; just be aware that whoever lands second regenerates index.json rather than hand-resolving it.

Next step: fix the two blockers — pass the algorithm through to the brute forcer, and reuse one keypair across --host-jwks and --forge-jku while carrying its private key and JWKS in the forge_jku finding. Correct the four table rows and scope the PyJWT sentence. Push those and I will merge; the naive formula at api-reference.md:298, the check_nonce_reuse pair threading, the triage gaps and the rest can follow separately.