That is the durable lesson of the closing four (can-it-fizz, does-it-buzz, make-it-fizzbuzz, latent-leak-hard):

A mitigation is only a defense while the value behind it is unknown. Every byte you leak is a mitigation you remove.

The workhorse: a one-byte partial overwrite is a leak primitive

Three of the four levels share a FizzBuzz skeleton: a loop that reads input, then strcpy(dst, src) and prints the result. Because src lives in the input window, you can repoint it one byte at a time.

The trick is that a single low-byte overwrite never crosses a page boundary, so it can only redirect a pointer to a neighbor in the same page. So you hunt for a useful neighbor:

• In can-it-fizz, the GOT sits on one page but a stdout copy variable (R_X86_64_COPY, holding &_IO_2_1_stdout_) sits on the globals page next to fuzzbuzz. One byte (0x18 -> 0x30) repoints src at it, and the next print leaks a libc address.
• In does-it-buzz, the same one-byte pivots reach puts@got (libc) and a self-referential RELATIVE entry (PIE).
• In make-it-fizzbuzz, the same idea leaks libc, PIE, the stack base, and the canary in four loop iterations.

The point is not the specific offsets. The point is that partial overwrite + same-page pivot is the cheapest leak primitive available, and it works precisely because PIE only randomizes the high bits you never touch.

Turn the leak interface into an arbitrary write

does-it-buzz shows the next move. If you can control both src and dst of the strcpy in the same iteration, the “print a leak” interface is also an “arbitrary byte-wise write” interface. Read becomes write for free.

From there the canary is irrelevant — the overflow never reaches it — and the solve is pure GOT surgery: stage the address of win, then a single strcpy(strcpy@got, scratch) redirects the next call into it. The family name BabyFizzGOT is the hint; the read primitive and the write primitive are the same code path used twice.

Keep the loop alive long enough to finish the chain

Leak chaining only works if the program stays in the loop while you collect values. make-it-fizzbuzz adds a subtlety: the loop counter i sits inside the readable window, and a %s print stops at the first NUL.

Writing i = 0xfefefefe solves both problems at once. As a signed integer it is negative, so the loop never reaches its exit condition; and because all four bytes are non-NULL, the %s print walks straight past the counter into the pointer you actually want to leak. A counter is not just control flow; under a string-printing leak it is also a NUL barrier you can dissolve.

SUID separation is its own mitigation — handle it explicitly

can-it-fizz has a quiet trap. A clean ret2libc into system("/bin/sh") runs a shell, but the shell has dropped privileges, so /flag stays unreadable.

The binary is SUID root, which means euid = 0 but ruid != 0, and system runs /bin/sh which drops to the real uid. The fix is to treat privilege separation as a mitigation to undo before the payoff:

setuid(0)            // collapse ruid to 0 while euid is still 0
system("/bin/sh")    // now the shell keeps root

One extra gadget in the ROP chain, but skipping it is the difference between a shell and a useless shell. (Watch stack alignment too: with A = rbp+8, the chain is already 16-byte aligned and needs no extra ret.)

NX is a placement problem, not a wall

make-it-fizzbuzz ships a never-called mprotect_stack() that flips its own stack page to RWX. NX says “no code on the stack”; this gadget says “unless I ask nicely.” The chain becomes leak everything, pre-copy shellcode via strcpy to a high stack slot, then ret -> mprotect_stack -> shellcode.

The non-obvious failure mode — the same one the constrained-shellcode levels teach — is staging. mprotect_stack’s own frame executes below rbp and clears the low part of the buffer, so shellcode placed at buffer[0] is destroyed by the very call that makes the stack executable. The fix is to place the payload at B+0x80: past the region the setup code zeroes, but still inside the page that becomes RWX. Code execution is not enough; the code has to survive the transition into executability.

The residual canary, and a verification lesson worth keeping

latent-leak-hard is the cleanest leak-chaining puzzle, and it almost beat me with a bad measurement.

The output format is %.318s, which caps at buffer offset 0x13e, while the canary is at 0x148 — so the live frame’s canary is never printable. It is not a fork service either, so each connection is a fresh canary and byte-by-byte brute force is out. The canary must be leaked within one connection.

The recursion provides it. The child frame’s buffer overlaps the deep stack the parent’s libc calls (scanf, printf) used, and those functions leave a canary copy in their own frames. On the remote libc-2.31, a copy lands at child buffer offset 0x38. Fill 0x39 to overwrite its leading NUL and %s prints canary[1..7].

The lesson is in how I confirmed it. My first verifier brute-forced the offset and judged success by “no smash message + SIGSEGV = wrong canary.” That criterion is unfalsifiable: __stack_chk_fail’s abort path itself crashes with a SIGSEGV, so a correct canary that fails later looks identical to a wrong one. Sixty-four parallel attempts, zero hits, and I nearly concluded 0x38 was not the canary.

The fix was a positive criterion: send 'A'*0x148 + candidate — an overflow that touches only the canary and never the return address. If the candidate is right, the frame returns cleanly (Goodbye!, no crash). That test isolates the one variable and immediately confirmed 0x38. (My local newer libc had no such residual, which is why local GDB never found it — a leak can be libc-version-specific, so scan the target’s environment, not your own.)

PIE then needs no full leak: at recursion depth >= 1 the saved RIP is a fixed challenge return site, so a two-byte partial overwrite to 0x?dc9 brute-forces a single nibble (1/16) to hit win_authed+0x1c.

Defender notes

The closing four map to recurring real-world mistakes:

• copy-relocation and GOT entries adjacent to attacker-influenced pointers, where a one-byte nudge becomes an infoleak;
• the same code path serving as both a disclosure and a write primitive (strcpy with attacker-controlled src and dst);
• SUID binaries that call system/exec without reasoning about ruid/euid;
• self-modifying permission gadgets (mprotect to RWX) reachable from a corrupted return address;
• secrets left in reused stack regions by library calls, with leak behavior that varies across libc builds.

For detection, the high-value signals are: a SUID-root process spawning an interactive shell after setuid(0); mprotect(..., PROT_EXEC) on stack/anon pages followed immediately by execution there; and crash clustering on __stack_chk_fail consistent with canary brute forcing.

The capstone takeaway for the whole Program Security module:

Mitigations defend unknowns. Exploitation is the work of making each unknown known — one partial-overwrite leak at a time — until the protected control transfer is just arithmetic.

It is an interface-design problem.

The real question is not:

How do I fit open/read/write("/flag") into this payload?

It is:

What is the smallest interaction with the environment that still causes the flag to become readable?

Reduce the objective before reducing the bytes

The cleanest example is the pair of short-budget levels.

If the challenge is launched from a shell you control, you do not need shellcode that opens /flag, allocates buffers, and writes output. You can prepare the environment first:

ln -sf /flag f

Now the payload only needs to make f readable:

chmod("f", 4)

That reframing collapses the problem into a 12-byte syscall stub. The shell outside the binary does the rest with cat f.

The payload is small because the interface contract is small.

Filters do not remove primitives; they change where construction happens

Two common shellcode filters look stronger than they are:

• forbidden bytes like 0x48;
• forbidden syscall encodings like 0f 05.

These are not semantic defenses. They are serialization constraints.

If 0x48 is banned, the fix is to stop encoding mov rdi, rsp in the obvious way and use a stack transfer sequence such as:

push rsp
pop rdi

If 0f 05 is banned, the syscall primitive still exists. You just move the construction to runtime: place 0e 05 in memory, increment one byte, and jump into the repaired opcode.

This pattern generalizes beyond shellcode. A filter that bans a literal representation often leaves the underlying primitive intact.

Memory permissions create placement problems, not just execution problems

The harder levels stop being about a single payload buffer.

Once a challenge maps one page RX and another RWX, or mutates the original input page before control reaches it, “where should the code live?” becomes the main design question.

The right mental model is:

stage location
-> writable before launch?
-> executable at handoff?
-> preserved after setup code runs?

That is why two-page layouts and mprotect-based return chains matter. A payload can fail even after obtaining code execution if it is stored in the same region that setup code later clears or re-protects.

Uniqueness constraints turn shellcode into staging

diverse-delivery shows another kind of interface problem: every byte must be unique.

At that point, direct “final payload” thinking is usually wrong. The realistic path is:

1. spend the unique bytes on a tiny decoder, copier, or branch gadget;
2. let that stage build the real code elsewhere;
3. execute the generated second stage under looser conditions.

The same idea appears in six-byte limits like micro-menace. When the budget is too small for useful work, the only credible design is a control-transfer seed, not a full solution.

Earlier memory-corruption levels teach the same lesson

The memory-corruption half of the module prepares this mindset.

Those earlier levels are also about interface boundaries:

• %s is not just output; it is a memory disclosure interface if NUL termination is broken.
• a stack canary is not a blocker if you can preserve the contract and write it back unchanged.
• a fork server is not just concurrency; it is a stable oracle interface because children inherit the same secrets.
• a return-address overwrite is useless if the function exits early; the real interface is the guard that decides whether ret is even reachable.

The shellcode levels are the same game with stricter constraints. The byte stream is only one boundary among many.

Defender notes

These challenge patterns map cleanly to real engineering mistakes:

• brittle byte filters that treat syntax as security control;
• RWX or permission-flipping code paths with unsafe staging assumptions;
• helper routines that expose secrets because buffers are reused or unterminated;
• “one dangerous primitive but heavily constrained” designs that remain exploitable because the attacker can reshape the surrounding environment.

The durable lesson is simple:

Exploit design starts by minimizing the contract with the target, not by maximizing gadget complexity.

When the contract becomes small enough, even a heavily constrained input surface can be enough.

The same question keeps repeating:

What model does this program use to decide that my input is correct?

Sometimes the model is a byte transform. Sometimes it is a branch. Sometimes it is a virtual machine. Sometimes it is a file format plus a constraint solver.

Start with the verifier

The early crackmes are small enough to solve by reading constants, but that is not the habit worth keeping.

The useful habit is to write the verifier as:

input -> transform -> comparison -> decision

If the transform is reversible, invert it. If it includes a sort, stop looking for a unique original order. A sort validates a multiset, not a string.

This matters because many wrong reverse-engineering attempts are over-specific. They try to recover the intended input when the binary only checks an equivalence class.

Patch the decision, not the program

The patching levels look like a license to change code freely. They are really a lesson in minimality.

When the check is:

call memcmp
test eax, eax
jne fail

one byte can invert the decision. But the integrity-check variants punish that move. A better patch changes the comparison length:

memcmp(a, b, 0) == 0

That is a smaller semantic change. It preserves the surrounding control flow and passes both the integrity comparison and the final license comparison.

A VM is just another model

Yan85 turns the verifier into a custom machine. The trap is thinking that VM reversing is a new category of magic.

It is still model recovery:

3-byte instruction -> register state -> memory state -> syscall state

The easy variants print traces. Use them to build the semantic table: opcodes, registers, flag bits, and syscall masks. The hard variants remove the trace, but the bytecode still has structure.

The workflow that held up:

• extract the yancode section;
• disassemble in 3-byte chunks;
• implement IMM, ADD, STK, STM, LDM, CMP, JMP, and SYS;
• print every compare and syscall;
• solve constraints or assemble VM shellcode.

The later levels flip the task. Instead of understanding their yancode, you write yours:

write "/flag\0" into VM memory
open(path)
read(fd, buf, size)
write(1, buf, n)
exit()

Yansanity adds randomized VM mappings. That kills hardcoded practice-mode bytecode, but not the method. Recover the current mapping, then assemble for that mapping.

File formats beat guessing

The Cows and Bulls levels look interactive. They are not.

gamefile.bin starts with a CBGF magic and contains the round data. The right interface is not the program prompt. The right interface is the file parser.

The progression is:

• parse the header and records;
• solve Bulls/Cows constraints offline;
• reproduce the migration or ordering state;
• for hash variants, enumerate fixed-length guesses and compare SHA256;
• for salted variants, recover the salt placement before hashing.

Once the file format is the model, the terminal prompt is only an output adapter.

Defender notes

Reverse engineering writeups often end at “here is the key.” That misses the durable part.

For defenders and analysts, the useful artifacts are:

• the transform model;
• the decision point;
• the VM instruction semantics;
• the syscall surface exposed by an interpreter;
• the file format schema;
• the observable failure and success channels.

Those artifacts survive challenge-specific flags. They are also the parts that transfer to malware loaders, protected installers, game anti-cheat components, custom protocol parsers, and fragile validation code.

Reverse engineering is model recovery. Once the model is explicit, the rest of the work becomes ordinary engineering: invert it, patch it, emulate it, generate code for it, or solve constraints against it.

The PortSwigger API Testing labs cover the usual drift points: documentation, methods, hidden fields, query strings, and REST paths.

Start from the real traffic

A visible request such as:

PATCH /api/user/wiener

is a map. Walk upward to /api/user, then /api. Try documentation paths. If interactive docs are exposed to ordinary users, the hidden contract may include administrative operations.

Methods are part of authorization

A product page may only issue:

GET /api/products/1/price

but OPTIONS can reveal:

GET, PATCH

If PATCH accepts:

{"price":0}

then the frontend hid an update method that the backend failed to authorize.

Response fields are not write fields

Mass assignment starts with a diff. If GET returns:

"chosen_discount": {"percentage": 0}

and POST does not normally send it, test whether POST accepts it anyway. A 100% discount should be server-controlled, not a client-supplied field.

Internal URL building is a parser boundary

Server-side parameter pollution appears when input is concatenated into an internal request:

username=administrator%26field=reset_token%23

For REST paths, the same issue becomes path pollution:

username=../../v1/users/administrator/field/passwordResetToken%23

The bug is not the encoded character itself. The bug is building internal URLs by string concatenation and letting user input become query or path syntax.

Defender notes

Hardening:

• authenticate documentation and OpenAPI endpoints;
• authorize every HTTP method independently;
• use structured URL builders for internal requests;
• normalize and allowlist path segments;
• use write DTOs instead of binding request JSON to domain objects;
• keep price, discount, role, and token fields server-owned;
• make error messages useful for operators, not endpoint discovery.

Detection:

• user traffic to docs and API definition files;
• encoded separators in username or id parameters;
• unexpected OPTIONS, PATCH, PUT, or DELETE;
• clients submitting response-only fields;
• reset flows probing arbitrary field names;
• traversal sequences inside API path parameters.

API testing is contract drift hunting: find what the backend really accepts, then decide whether the current user should ever have been allowed to send it.

In the PortSwigger NoSQL labs, a string becomes JavaScript, a scalar becomes a MongoDB operator, and hidden document fields become enumerable through $where.

Strings become expressions

A category filter should treat input as data. If it is interpolated into a JavaScript-style condition, syntax and boolean probes reveal the boundary:

Gifts' && 0 && 'x
Gifts' && 1 && 'x

An always-true expression widens the result set:

Gifts'||1||'

That is not a category value anymore. It is query logic.

Scalars become operators

JSON APIs make operator injection easy to miss. The client is expected to send:

{"username":"wiener","password":"peter"}

but the server accepts:

{"username":{"$regex":"admin.*"},"password":{"$ne":""}}

The field that should be a string becomes a query object. Schema validation should reject that before the database driver sees it.

$where turns documents into an oracle

If $where is accepted, JavaScript can inspect the current document:

{"$where":"this.password[0]=='a'"}

Response differences become a boolean oracle for passwords, reset tokens, and even unknown field names:

{"$where":"Object.keys(this)[1].match('^.{0}u.*')"}

The database is no longer just filtering rows. It is evaluating attacker-controlled code over user objects.

Defender notes

Hardening:

• enforce JSON schemas at the API boundary;
• reject objects where scalar strings are expected;
• deny operator keys in user-controlled input;
• construct query objects from allowlisted fields;
• disable $where and server-side JavaScript;
• keep reset tokens and credential fields out of user-facing query surfaces;
• normalize login and reset error messages.

Detection:

• $ne, $regex, $where, Object.keys(this), or this.password;
• quote-plus-boolean probes in query strings;
• login parameters changing type from string to object;
• character-position enumeration patterns;
• reset endpoints probed with unusual token field names.

The boundary is the query shape. Once the attacker controls that shape, the database becomes an execution and enumeration engine.

The bug is a non-atomic state transition. The application checks one state, acts later, and leaves a window where another request can change what the first request thought it had validated.

Find the transition first

The PortSwigger race-condition labs cover the usual targets:

• coupon use;
• login failure counters;
• checkout validation;
• pending email changes;
• password-reset tokens;
• registration confirmation.

Each one has a state transition. The useful test is to split it into check, write, confirmation, and side effect. The race window usually lives between two of those steps.

Same endpoint, different endpoint, or side effect

Some races repeat one request:

POST /cart/coupon

Others line up different requests:

POST /cart
POST /cart/checkout

The email-change lab shows a third form: the bug is not the endpoint itself, but an asynchronous side effect. The database says one pending email while the mail-rendering task reads another.

That distinction matters for testing. Replaying one request is not enough; you have to understand the workflow.

Precision beats volume

Volume helps only if requests actually hit the window. HTTP/2 single-packet attacks and gate-based release make timing sharper:

for payload in payloads:
    engine.queue(target.req, payload, gate='1')
engine.openGate('1')

The goal is not just “many requests.” It is “the server observes the same stale state many times.”

Partial construction is the dangerous edge

The expert lab is a partial-construction bug. A user is partly created before its confirmation token is fully initialized. A confirmation request using an empty-array token shape can land in that temporary state:

POST /confirm?token[]=

This class appears whenever systems expose half-built rows, files, sessions, or jobs to other endpoints.

Defender notes

Hardening:

• put check-and-act logic in transactions or atomic operations;
• use row locks, unique constraints, and compare-and-set for shared state;
• make coupons, balances, counters, and pending-email records single-owner transitions;
• bind async jobs to immutable snapshots;
• generate reset tokens with CSPRNGs, not timestamps;
• keep partial objects invisible until fully initialized;
• serialize critical actions per user or resource.

Detection:

• bursts of identical state-changing requests;
• impossible counts, such as multiple coupon successes;
• lockout counters lower than the observed attempts;
• order success after insufficient-funds responses;
• mismatched email recipient and confirmation body;
• duplicated reset tokens;
• empty-array or malformed confirmation tokens.

Good race-condition defense is not “hope requests arrive slowly.” It is making the state transition indivisible.

The PortSwigger GraphQL labs are a compact reminder: the dangerous question is not only “where is the endpoint?” It is “what can this principal ask for, how many times, and through which browser mechanics?”

Schema is reconnaissance

Introspection turns the API into a map:

{ __schema { types { name fields { name } } } }

If private fields such as passwords, tokens, or hidden post metadata appear in the schema and resolvers do not enforce authorization, the client can simply ask for them.

Hiding the field in the UI is not a control. Resolver authorization is the control.

Hidden endpoints still answer universal queries

A useful endpoint probe is:

query { __typename }

If /api?query=query{__typename} returns a type name, you found a GraphQL endpoint even if navigation never referenced it.

Blocking introspection with a string match is brittle. A filter looking for __schema{ can miss valid GraphQL with whitespace:

query {
  __schema
  {
    queryType { name }
  }
}

GraphQL should be parsed and authorized, not filtered with raw-string assumptions.

Execution semantics affect rate limits

Aliases let one operation run many sibling fields or mutations:

mutation {
  a: login(input: {username: "carlos", password: "123456"}) { success }
  b: login(input: {username: "carlos", password: "password"}) { success }
}

A limiter that counts one HTTP request misses the fact that many login attempts happened inside that request. API controls have to count semantic actions, not just network envelopes.

Transport can create CSRF

GraphQL is often shown as JSON over POST. Some endpoints also accept form-urlencoded bodies:

query=...&operationName=changeEmail&variables=...

That can turn a mutation into a browser simple request, allowing a cross-site form POST with ambient cookies. State-changing GraphQL operations need CSRF protection and strict content-type policy.

Defender notes

Hardening:

• disable or authenticate introspection;
• enforce authorization inside resolvers for fields and objects;
• treat ids as object references requiring ownership checks;
• reject regex-only introspection filters;
• restrict aliases and batching for sensitive mutations;
• rate-limit by action count, username, account, and IP;
• require JSON and CSRF tokens for state changes;
• reject GET for mutations.

Detection:

• introspection terms with unusual whitespace or encoding;
• many aliases calling the same mutation;
• GraphQL query strings on unexpected paths;
• low-privilege users requesting credential-like fields;
• form-urlencoded traffic to GraphQL endpoints;
• state-changing mutations without CSRF signals.

GraphQL’s power is legitimate. The mistake is letting the schema, resolver layer, and browser transport rules drift out of the threat model.

That is only the primitive. The impact is a read bug. Some later code looks for an own property, does not find one, and silently accepts the inherited value.

The PortSwigger prototype pollution labs are useful because they separate those two halves.

The chain has three parts

A real chain needs:

• a source that writes to the prototype;
• a gadget that reads a missing property;
• a sink that treats the inherited value as code, configuration, or authority.

Client-side examples include dynamic script URLs and eval():

?__proto__[transport_url]=data:,alert(1);

Server-side examples include authorization flags and child process options:

{"__proto__":{"isAdmin":true}}

The same pollution source can be harmless or critical depending on what property the application reads later.

Sanitizers fail when they are not parsers

One lab uses a one-pass key sanitizer. Splitting the forbidden key is enough:

?__pro__proto__to__[transport_url]=data:,alert(1);

Another blocks __proto__ but misses the equivalent object path:

{"constructor":{"prototype":{"isAdmin":true}}}

Prototype pollution filters need recursive structural validation. A blacklist applied once to a raw string is not enough.

Non-reflective detection matters

Server-side pollution may not reflect arbitrary properties. That does not mean it failed.

One safer probe is to pollute a status-code property, then trigger a controlled parse error:

{"__proto__":{"status":555}}

If the error object changes status, the prototype was modified without needing destructive impact. Similar low-impact probes include JSON spacing and charset behavior.

Child process gadgets are configuration bugs

The later labs show why inherited options are dangerous. If a maintenance job spawns a Node child process, inherited execArgv can add runtime flags. If code passes an options object to execSync(), inherited shell and input can control execution behavior.

The fix is not just filtering request keys. Sensitive option objects should be constructed explicitly and should not inherit attacker-controlled prototype state.

Defender notes

Hardening:

• reject __proto__, constructor, and prototype recursively;
• use Object.create(null) for merge targets and option objects;
• check authorization with own properties only;
• avoid string-based JavaScript sinks;
• construct child process options from known fields only;
• test --disable-proto=throw in Node deployments;
• keep parser and merge libraries current.

Detection:

• prototype-key strings in query, fragment, JSON, or cookie data;
• split-key variants that reconstruct dangerous names;
• JSON spacing, error status, or charset changes after profile updates;
• ordinary users seeing admin-only links;
• maintenance jobs failing after account-data writes;
• unexpected --eval, shell, or input options in spawned processes.

The core defensive question is simple: can this object read inherited authority or configuration? If yes, a parser bug can become a system bug.

The PortSwigger Essential Skills labs make that distinction explicit. They are not really about new bug classes. They are about using Burp Scanner as a focused instrument during manual testing.

The human chooses the boundary

In the file-read lab, the time limit changes the workflow. A full-site scan may eventually find the issue, but it burns time on low-value requests.

The better sequence is simple:

• inspect normal traffic;
• find the request most likely to read a server-side resource;
• run a targeted scan on that request;
• take the scanner’s vector back to Repeater;
• reduce it to a proof that reads /etc/passwd.

The scanner accelerates the middle of the process. It does not decide what matters.

Hidden inputs are still inputs

The non-standard data-structure lab is the more important lesson. The authenticated cookie contains a visible structure:

username:session-id

That is not one opaque value. It is two parsed fields sharing one cookie. Selecting only the username portion as an insertion point lets Scanner test the field the application actually trusts.

Once the stored XSS finding appears, the final proof preserves the session-id half and changes only the username half. Without that preservation, the request loses its authentication state.

Scanner output needs interpretation

Scanner findings are not the end of testing. They are leads:

• What exact parser accepted the input?
• Which sub-field became trusted data?
• Which output context rendered it?
• What is the smallest proof?
• What server-side invariant failed?

Those questions turn a scanner result into an engineering fix.

Defender notes

Hardening:

• keep session cookies opaque and random;
• avoid packing user-controlled fields into authentication cookies;
• sign and schema-check structured values when structure is unavoidable;
• treat file access as resource lookup, not path concatenation;
• canonicalize paths before enforcing directory containment;
• encode stored content for the exact browser context.

Detection:

• traversal strings or absolute paths in resource parameters;
• HTML/event-handler payloads in cookie sub-fields;
• one insertion point receiving many scanner payload variants;
• privileged browser sessions causing unexpected outbound DNS or HTTP callbacks.

Targeted scanning works because it keeps automation attached to a manual model of the application. The model is the work; the scanner is the amplifier.

The eight PortSwigger JWT labs move through the usual failure modes: no verification, alg:none, weak HMAC secrets, attacker-controlled keys, kid injection, and algorithm confusion.

This series was re-run and live-verified on 2026-05-30 as 8/8 solved. The no-exposed-key lab is worth calling out: public key recovery from several valid RS256 signatures was enough to trigger HS256 confusion without recovering the private key.

Decode is not verify

The first failure is using a JWT library to parse claims without verifying the signature. If changing:

{"sub":"administrator"}

works without re-signing, the server is authenticating decoded JSON, not a verified token.

The alg:none variant is only slightly different. The token declares:

{"alg":"none","typ":"JWT"}

and leaves the signature empty:

header.payload.

No authentication system should accept this mode.

HMAC secrets are credentials

Weak HMAC secrets turn JWTs into offline password-cracking targets:

hashcat -a 0 -m 16500 <jwt> jwt.secrets.list

Once the secret is recovered, claims can be changed and re-signed. Treat HMAC JWT secrets like passwords with high entropy and rotation requirements.

Key discovery must be trusted

The key-header labs are all versions of the same bug: the attacker influences which key verifies their token.

jwk embeds a public key directly in the header. jku points the server to an attacker-hosted JWKS. kid is supposed to select a known key, but becomes path traversal:

{"kid":"../../../../../../../dev/null"}

Key IDs should be opaque references into a trusted registry. They should not be URLs, files, or queries selected by the token.

Algorithm confusion is type confusion for keys

RS256 uses a private key to sign and a public key to verify. HS256 uses one shared secret for both.

Algorithm confusion appears when the verifier trusts the token’s alg and uses an RSA public key as an HMAC secret:

{"alg":"HS256"}

If the public key is exposed, it can be used to sign a forged HS256 token. If it is not exposed, it may still be derived from multiple valid RS256 tokens. The private key is not broken; the verifier’s key-type policy is.

Defender notes

Hardening:

• pin accepted algorithms server-side;
• reject none;
• use verify APIs for authentication paths;
• use strong managed secrets for HMAC;
• treat jwk, jku, and kid as trusted-registry selectors only;
• allowlist JWKS origins;
• validate kid as an opaque ID;
• keep HS and RS verification code paths separate;
• avoid trusting high-risk authorization claims without server-side checks.

Detection:

• alg:none;
• unexpected jwk or external jku;
• kid containing traversal or /dev/null;
• RS256 tokens suddenly becoming HS256;
• role or subject jumps without a fresh login;
• outbound JWKS fetches to unfamiliar hosts.

JWT failures are usually policy failures. The token says what it wants to be; the server must decide what it is willing to verify.