Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

A single open port behind nginx, and the usual pattern for this platform: the default response is a redirect that names the vhost you’re supposed to be using. Once that’s in the hosts file you get a station homepage with a schedule, show pages and a “submit your demo” form.

The demo form has a preview step that fetches a user-supplied artwork or feed URL server-side. That’s the attack surface, and the client bundle tells you how to use it: the request body carries a developer flag, and the embedded comment explains that the full response body is only returned when that flag is set.

Flipping it converts a blind fetcher into a full-read SSRF — you get the status, the content type and the complete body back. That single toggle is the difference between port guessing and actually reading internal applications.

From SSRF to an internal API

Pointing the fetcher at loopback and sweeping ports surfaced an undocumented internal API alongside the public app. Its spec document was served over the same interface, which handed over the whole surface: a user listing endpoint, a password-change endpoint (POST-only), and a diagnostics “stream probe” whose entire job is to shell out to a network client and report reachability.

The password change was the goal but it required POST, and the SSRF only issues GET. The diagnostics endpoint was the pivot — and it was vulnerable.

Command injection

The stream probe concatenated the caller-supplied URL straight into a shell command string and ran it. A trailing ; sleep confirmed injection by shifting the response time; because the endpoint returns the raw stdout of the whole pipeline, any injected command’s output comes back in the JSON response. That’s a comfortable RCE — you get results, not just a shell.

The source even carried a comment explaining that the parameter was considered trusted because the API only listens on loopback. Loopback is not authentication.

The /proc scrubbing trap

This is the best lesson on the box. The API reads its database credentials from environment variables and then deliberately removes them from its own environment, specifically so that a shell spawned by the diagnostics endpoint can’t recover them. Sensible instinct, wrong assumption.

On Linux, /proc/<pid>/environ is a static snapshot written by the kernel at execve(). Removing a variable from the running process updates the live environment — it does not update that snapshot. The original values stay readable for the lifetime of the process, so reading the service’s own /proc entry handed back the database password intact.

Then the trap reverses direction: with command execution on the host, I no longer needed the SSRF to reach the internal API — I could make the POST to the password-change endpoint directly over loopback and reset the administrator’s password.

The hidden console

The container’s /etc/hosts listed a second vhost that the public site never links to — a staff playout console. Logging in with the freshly reset administrator password worked, which is the payoff for chaining the previous two steps: the SSRF found the service, the injection reset the account.

Its playlist import endpoint deserialised the uploaded bundle with the language’s native object-serialisation format and — critically — rendered the deserialised object back into the response. That combination turns insecure deserialization from a blind exploit into one where the command’s output is printed on the page. Upload, read the flag inline.

Note the format detail: the bundle was base64-wrapped before deserialization, matching the export format the app itself produced. Reading the export endpoint first told me exactly what the import endpoint expected.

Takeaways

• /proc/<pid>/environ is a snapshot, not a view. Scrubbing secrets from the live environment does nothing to it. Never rely on it as a mitigation — and read it when you have code execution.
• A “developer” or “debug” flag in a request body can upgrade a blind primitive into a full-read one. Grep client bundles for them.
• Loopback binding is not authentication, and a service that shells out with caller input is command execution regardless of where it listens.
• Chaining beats depth: the SSRF found the endpoint, but the injection was what actually reset the password. Keep both primitives alive.
• Insecure deserialization is much easier to exploit when the app echoes the deserialised object back to you — check whether the result is rendered.
• Five partial mitigations still add up to a full compromise. Each step here was “mostly handled”, and the chain walked straight through.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

One nginx reverse proxy routing purely on the Host header, and behind it two separate applications: a public shop with a booking form, and a staff console with its own login. Both are invisible until the vhost names are in your hosts file.

Two details paid off immediately, and neither came from a scanner:

• The staff console’s CSS carried a comment labelling one section as the vulnerable surface — the author leaving breadcrumbs. I followed it, and it was a red herring (see below), but it told me the shape of the challenge.
• The console’s JavaScript pointed at a second API host that the UI never mentions directly. Always read the client bundle once you’re authenticated; the interesting backend is rarely the one you logged in to.

The decoy: stored XSS

Everything pointed at stored XSS through the booking form, and it was real: the console rendered client notes as raw HTML, an automated browser was visiting submissions, and the CSS comment named the section.

It was still the wrong path — the bot’s network couldn’t reach my callback address. Thirty payloads, zero callbacks. If you can’t receive the callback, the bug is untestable, not unexploitable. I noted it, stopped, and moved on, which in retrospect was the right call.

Password-reset poisoning with a helpful mail daemon

The staff login had a “forgot password” link, and the reset URL was built from the request’s host header rather than a configured base URL. Injecting an alternate host into that header made the app generate a reset link pointing at my listener.

That alone is a known technique, but the interesting part was what happened next: the studio’s internal mail daemon pre-fetches URLs in outgoing messages (link previews). It requested the poisoned link within seconds of the reset request being submitted — so the reset token arrived at my listener without the user ever opening the email.

That’s what makes this pattern worth remembering: it isn’t just developer oversight on the web side. It works because an internal service follows links, which turns a low-key bug into an instant, no-interaction token theft.

With the token, resetting the staff account’s password and logging into the console was mechanical.

The real bug: server-side template rendering

Authenticated, the booking notes were rendered server-side through a templating engine before being returned as HTML fragments. A trivial arithmetic expression in the note field came back evaluated — text-book server-side template injection.

The puzzle was getting output out, not execution. The API wraps rendering in output buffering, so functions that print to stdout have their output discarded — the template receives nothing. Only a callable that returns its output as a string survives.

That turns into an argument-count problem. Each template filter invokes its callback with a fixed number of arguments — one filter passes one, another passes two, another passes three — and you need a function whose signature matches that count and whose return value is the data you want. One of PHP’s process-execution builtins has exactly the right shape, and one filter passes exactly that many arguments, so the command’s output flows straight back into the template output.

Standard payloads fail for exactly this reason: the well-known “register an undefined callback” macro trick is gone in newer builds, and arrow functions can reference template functions but not arbitrary language callables. Arg-count alignment is the whole technique — enumerate the filters, count their arguments, and find a callable that fits.

Dead ends worth recording

• JWT alg:none — the server validates the signature even when the header claims no algorithm. Always test it, but don’t assume it works.
• SQL injection in the style field — an automated agent reported a time-based confirmation; careful re-timing showed the delay was network jitter. A textbook reason to re-verify anything time-based by hand.
• Password brute force — a hundred common passwords, no lockout, no hit. The real password simply wasn’t in the wordlist, which is itself a useful signal: stop guessing and find the intended path.

Takeaways

• Read the application’s own artefacts before scanning: response headers, source comments, and client-side JS files pointed at every step of this chain.
• Password-reset host-header poisoning is underrated — especially when an internal mail service follows links. No user interaction required.
• In template injection, getting output is a separate problem from getting execution. Output buffering kills every stdout-based payload; look for a callable whose return value is the data.
• Match the callback’s argument count to the filter that invokes it. That’s the difference between a payload that errors and one that prints.
• Chasing a signposted decoy costs time — but confirm it quickly, note it, and leave.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

A single web port behind a reverse proxy, reachable only by its virtual hostname. Enumeration turns up two files worth more than everything else combined:

• A publicly readable developer notes file. It’s a to-do list, and it names three deferred security items in plain language — a reflective endpoint that isn’t validated, a review feature that renders raw markup, and an admin cookie deliberately left without HttpOnly. That file maps the entire attack chain before a single request is crafted.
• A front-end search implementation that reveals the app uses a callback-style JSON API — the kind that wraps its response in a client-supplied function name.

The notes file is also candid about why each item was deferred. The reflective endpoint was low priority “since the CSP should prevent abuse”. It’s worth pausing on that sentence, because it’s the entire box.

The CSP, and the misconception in it

The site ships a strict, well-written policy: scripts limited to the same origin, no inline scripts, object-src 'none', base-uri 'none', frame-ancestors 'none', and connections limited to the same origin.

That policy is genuinely good. What it does not do is stop the page from loading a script from its own origin — including from an endpoint whose response body is shaped by an attacker-supplied parameter.

script-src 'self' bans other origins and inline scripts. It has nothing to say about loading a script from your own origin — that’s the origin it explicitly permits. So if any same-origin endpoint reflects attacker-controlled text in a script-shaped response, that endpoint is your script loader, and the policy is fully satisfied while arbitrary JavaScript executes.

The developer spotted that the callback-style endpoint was dangerous, then treated the CSP as a compensating control. It never was one.

The three bugs

1. The callback parameter is reflected verbatim. The JSON API wraps its response in whatever function name you supply, with no validation or allowlist. Supplying a value that ends in a line comment neatly discards the JSON that follows, leaving a clean block of executable JavaScript.
2. Reviews render as raw markup. Any authenticated user can post a review, and the body is inserted into the page unescaped — the comment in the template even says it’s “to support rich text formatting”.
3. The admin’s session cookie isn’t HttpOnly — and the flag lives in that cookie. The notes file admits it was left readable so the admin dashboard’s own JavaScript could read it.

Any one of those alone is a bug. Together they’re a chain, and each one removes the obstacle the previous one creates.

The chain

1. Authenticate. The app ships default credentials, and the notes file helpfully confirms passwords are stored in plaintext. No cracking needed.
2. Store the payload as a review. The review body is a script tag whose source is the same-origin JSON API, with the callback parameter carrying the JavaScript we want to run. Because the source is same-origin, the CSP allows it.
3. Have the callback do the exfiltration. The injected JavaScript reads document.cookie (which contains the admin’s flag cookie) and posts it as a review on a different product — using credentials-included so the request is authenticated, and a form-encoded body so no preflight is involved. Writing the stolen value into another product’s review gives us a second-order read channel: the exfiltrated secret comes back out through the normal application UI.
4. Trigger the admin bot. The storefront has a “report this page” feature that sends an admin bot to review a URL. Reporting our poisoned product page is the delivery mechanism.
5. Collect and replay. The bot loads the page, the same-origin script loads and executes, and the admin’s cookie is written into the other product’s reviews where we can read it. Replay that cookie against the admin panel and the flag is displayed.

Notice what the exfiltration doesn’t need: no outbound connection to an attacker host, no DNS, no server of our own. Everything happens within the permitted origin. That’s precisely why the CSP didn’t help.

Dead ends

• Sending the cookie to an external collector — blocked, as the policy intends: connect-src is same-origin only, which also rules out sendBeacon to an outside host.
• Image-based exfiltration — the policy allows HTTPS images but a plaintext cookie in a URL needs plain HTTP, which would be a downgrade the browser won’t make.
• Hunting a JSON API that returns the flag — the non-admin routes simply fail; the secret is only ever rendered in the admin HTML panel.
• Injection at the login — malformed bodies crash or reset the worker rather than returning anything useful.

Each of these pushes you back toward the same conclusion: exfiltrate through the application, over the channel you’re already allowed to use.

Why it worked

All three failures share one root cause: the developer evaluated each risk in isolation and assumed a different control would catch it later. The reflective endpoint was “fine because CSP”. The raw review rendering was “fine because you must be logged in”. The cookie was non-HttpOnly “for convenience”. Individually, each mitigation sounds reasonable. Stacked, they cancel out — the raw rendering gives you script execution, the reflective endpoint gives you a way to run code the CSP permits, and the readable cookie gives you the prize.

Takeaways

• script-src 'self' does not stop same-origin script injection. Any endpoint that reflects input into a script-shaped response is a script loader. JSONP is the classic case, and CSP cannot compensate for it — validate or remove the reflective parameter.
• Never ship a developer notes or to-do file in the web root. It collapsed hours of enumeration into a two-minute read, and it told us which mitigations the developer believed were protecting them.
• Encode on output, in every view — internal-looking pages are exactly the ones with privileged readers.
• HttpOnly on every session cookie. Don’t leave secrets readable from JavaScript for convenience.
• Second-order channels work. Writing a stolen value back into the application’s own data (a review, a comment, a profile field) is a reliable read-back when outbound traffic is blocked.
• Hash passwords. Plaintext storage turned a default-credentials issue into total account compromise.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

One web port, one vhost handed to you by a redirect, and a Node application behind it.

The landing page is a report generator with a few template choices and one field that stands out: an “external data endpoint”. The marketing copy next to it says, in as many words, that the URL is fetched from the server, that this “works with internal staging APIs, authenticated endpoints behind your firewall, or any URL not publicly accessible”, and that the response is embedded directly into the generated PDF.

An application describing its own SSRF vector is not a subtle bug hunt — but “the app fetches URLs” is the start of a process, not the answer. What you do with that primitive is the box.

Building the primitive

file:// and other schemes are rejected — only HTTP and HTTPS are accepted. That’s a real limit, and it removes the easiest escalations, so the useful question becomes: what is reachable over HTTP from inside this host?

The generator renders the fetched content into a PDF and hands you the file. That’s the detail that makes this box pleasant to work: the SSRF is full-read, not blind. A blind SSRF only lets you infer (“something answered”); here the fetched page is rendered and returned to you, so anything the internal service will render to a browser comes back as document text. The renderer is acting as your exfiltration channel, and it works even against services that would never let you talk to them directly.

The PDF is also the reason file:// matters less than it looks. A blocked file scheme costs you direct filesystem reads, but every HTTP-accessible service inside the host remains in scope — and those are where credentials and internal dashboards actually live.

That rendered file also gives a side channel: the size of the response body differs depending on what answered. Sweeping common localhost ports and comparing output sizes turns a blind fetch into a port oracle — a port that isn’t listening produces an error or a timeout, and a port that is listening produces a PDF whose size grows with how much content it rendered. One port came back markedly larger than the rest, which is enough to know something substantive lives there.

Reading a PDF that won’t give up its text

The PDFs were not extractable with the usual command-line tool — it returned nothing at all, which reads like an empty document but isn’t. The renderer embeds CID-mapped fonts: glyphs are referenced by font-internal identifiers rather than Unicode codepoints, so a naive extractor cannot map them back to characters without the font’s ToUnicode tables.

A more thorough PDF parser reads those CMap streams and reassembles the text correctly. The lesson is not to trust a blank extraction result: “no text found” and “text I can’t decode” look identical from the outside, and the difference matters enormously when the entire objective is text sitting inside the PDF.

What was behind the port

The internal service is a metrics dashboard bound to loopback — and it has no authentication at all. Its own text explains why: “Authentication is disabled — network isolation is assumed.” That is the entire bug in one sentence. The developers substituted the network boundary for an authorisation check, and the SSRF removed the network boundary.

The dashboard hands over the internal service topology (including which services have auth and which don’t) alongside the credential the box is asking for. That topology leak is worth more than the flag: it’s a map of what else is reachable, which listeners are bound where, and — crucially — which ones have no authentication. An SSRF that returns that map is an SSRF you can chain, and the “beyond the flag” question (is there a cache, a database, another app on this network?) is answered for you.

Worth noting what the write-up didn’t need: nothing was brute-forced, no credential was cracked, and no code was executed. Two design decisions — fetch any URL server-side, and protect an internal service with network isolation instead of authentication — were sufficient on their own.

Takeaways

• Server-side fetch features are SSRF by construction — especially in PDF/screenshot/render pipelines, where the response is returned to you as a file.
• Response size is a usable oracle. When you can’t read the content back, differential sizes still enumerate ports and identify interesting services.
• A blank text extraction is not an empty document. If a PDF resists extraction, suspect CID-mapped fonts and reach for a parser that honours ToUnicode maps.
• “Network isolation is assumed” is not authentication. Any SSRF, misrouted proxy or request-smuggling bug converts an assumed boundary into an actual exposure.
• Enumerate every scheme the fetcher allows — a blocked file:// narrows the attack, it doesn’t close it.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

The target is a small REST API behind a single web port. Three routes matter: a login, an MFA verification step, and the privileged action the whole box is built around.

That’s a deliberately narrow surface, and it tells you what the box is about before you send a single request. A login route, a second factor, and one action gated behind a “clearance” claim is an authentication and authorisation puzzle — not a hunt for a forgotten endpoint. When the surface is this small, the attack is almost always against the logic of the flow: who decides what you are, and how much of that decision the server actually re-checks.

The first useful find isn’t technical — it’s a comment left in the login page source, telling users that login errors with valid credentials are a known issue that “will be fixed within 365 days”. A note like that is an invitation to attack the authentication path specifically, and it’s the kind of thing that ships to production constantly.

Bug one — the injectable field is not the obvious one

The login takes a username and a password. The username is sanitised or uses a different query path; the password is interpolated straight into the query. Testing only the username would have produced a clean “not vulnerable” verdict on an endpoint that is trivially bypassable.

That’s the per-parameter lesson this box exists to teach: a negative result on one input is not a negative result for the endpoint. Fuzz every field, every parameter, every header — they frequently reach different queries.

A classic tautology in the password field authenticates you as an existing low-privilege user and returns a session plus a clearance level.

Bug two — the debug field that shouldn’t exist

The login response says MFA is required, and then — inside the same JSON — a _debug object carries the live one-time code in plaintext. Not a hash, not a masked value: the code you are supposed to receive by email, handed to anyone who asks.

Debug scaffolding is one of the highest-yield things to look for on any response. Grep every response you get for debug, trace, internal, test, otp, token — verbose fields leak the next step of the chain far more often than they leak anything else.

Feeding that code back to the verification route returns a signed session token carrying the low clearance level.

Bug three — the token that verifies itself

The privileged endpoint accepts a bearer token and checks the signature — but it lets the token choose its own algorithm. Switching the header to the “no signature” algorithm means the verification step is skipped entirely, and the payload is whatever you say it is.

So: take the structure of the valid token you were legitimately issued, rewrite the clearance claim to the highest level, and set the algorithm to none. No secret was recovered, guessed or needed.

This is the same failure as “the client decides how it will be authenticated” in any other form, and it appears in real applications often enough that it’s worth testing on every token-based endpoint you meet: flip the algorithm, strip the signature, watch whether the server cares.

It’s worth being precise about why it works, because the mechanism is what generalises. A signed token is three dot-separated parts: a header declaring how it’s signed, a payload of claims, and a signature over the first two. Verification normally means “recompute the signature using the algorithm in the header and compare”. If the header may name the no-signature algorithm, there is nothing to compute and nothing to compare — the server accepts a token whose third segment is empty. The defender’s own verification code is doing exactly what it was told; the flaw is that the attacker was allowed to give the instruction.

The other half of the lesson is where the claim lived. “Clearance level” was an ordinary field inside the payload, trusted after verification. Anything the client can put in a token and the server reads back as fact is, by definition, client-controlled — unless it is checked against a store the client cannot write to.

Takeaways

• Test every input independently. The injectable parameter is often not the one named after the thing you’re attacking.
• Debug fields in production responses are a direct roadmap — search for them deliberately.
• Never let the token select its own verification algorithm; pin it server-side and reject everything else.
• A chain of three “minor” issues is still a full compromise. Severity is a property of the chain, not of the individual bug.
• Source comments and error messages are documentation written by the defender — read them as hints.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

One port, a reverse proxy in front of an application server. Registering an account exposes the actual workflow, and the workflow is the target:

• Submit a report with a short identifier and a body of text.
• A reviewer bot visits each submitted report and reads it.
• The bot then fills in an endorsement field with its response — that response contains the flag — and clicks the endorse button.

That last point is the whole challenge. The flag is never written to anything we can read. It appears as text in the bot’s browser at the instant it populates that form, and then the bot navigates away. Meanwhile the bot’s session cookie is HttpOnly, so the classic steal-the-cookie move is off the table from the start.

The injection point

That identifier is reflected server-side inside a script block — the page interpolates it directly into an object literal in its own inline JavaScript, rather than into markup or into a quoted string.

The page ships a strict Content Security Policy, and the inline script block carries a nonce. It’s natural to assume that makes injection safe. It doesn’t, and understanding why is most of the lesson.

A CSP nonce protects the script block from being injected. It cannot protect code that is injected within a block the page already trusts. Because the input lands inside an object literal rather than in a string context, you can close the literal, run arbitrary statements, and then reopen a dummy literal so the rest of the original line still parses. The payload executes with the block’s trust — inline, nonce-blessed, and completely CSP-compliant.

Confirming it is easy: inject something that calls home and watch the reviewer’s request arrive.

Why the obvious approaches all fail

This is the interesting half of the box. Once you have script execution in the bot, the naive exfiltration options all die:

• Reading document.cookie — empty. The session cookie is HttpOnly.
• A timer — the bot navigates away before it fires.
• Hooking the form’s submit — the endorsement form is rendered below the injected block, so at the moment our code runs, that form isn’t in the DOM yet.
• A fetch() to a same-origin route — the flag isn’t served by any route; it only exists in the form the bot is about to fill.
• An iframe — blocked outright by the frame-ancestors directive.

So the flag isn’t stored, isn’t in a cookie we can read, and isn’t behind a URL. The only place it exists is the outgoing form submission the bot is about to make.

The solution

Two observations unlock it:

1. The form isn’t in the DOM now, but it will be parsed a moment later when the browser finishes rendering the rest of the page. So don’t look for it — listen for it.
2. When the bot clicks the button, a submit event fires. Attach a listener on document in the capture phase (third argument true). Capture runs before the form’s own handler, so we read the form’s data at the moment it is fully populated and before navigation begins.

At that instant the form data contains the flag the bot just typed. Then it has to get off the machine — and the bot is about to navigate, which kills ordinary requests. The one API built for exactly this is navigator.sendBeacon(): it queues an asynchronous POST that the browser delivers even as the page unloads. It was designed for analytics on page exit; here it’s the only reliable channel.

So the payload does three things: register the capture-phase submit listener, serialise the form data, and beacon it out. Start a listener, submit the poisoned report, and wait for the bot to review it. The flag arrives in the beacon body.

Insights worth keeping

• CSP + HttpOnly does not equal “XSS mitigated”. The nonce stopped us injecting a new script block and HttpOnly stopped cookie theft — but the bot’s actions (what it types, what it submits) remained fully readable from JavaScript. Exfiltration moved from exfiltrating secrets-at-rest to exfiltrating secrets-in-transit.
• sendBeacon is the answer whenever the target navigates immediately. Any timer or fetch-based exfil loses the race; a beacon doesn’t.
• Capture-phase listeners beat “the element doesn’t exist yet”. You rarely need the element to exist to observe an event that will bubble through an ancestor.

Takeaways

• A CSP nonce secures the script tag, not the data inside it — never interpolate user input into a trusted script block, even “safely” inside a JS object.
• HttpOnly blocks cookie theft, not script execution. Assume anything reachable from the DOM can be exfiltrated.
• When the target is transient (a value typed into a form, a page that immediately navigates), observe events rather than polling state.
• navigator.sendBeacon() survives unload — it’s the right tool for exfiltration against navigation.
• Capture-phase event listeners let you observe a submit before the application’s own handler sees it.
• If a secret is only ever in a browser’s memory, the exploit is to catch it in flight.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

Single web port, one vhost, and a small CSV upload / spreadsheet-viewer application. The navigation contains an item that reads “Admin — internal only (blocked at the edge)”.

That wording is the box handing you the answer’s shape. “Blocked at the edge” tells you three things at once: there is a privileged interface, it exists on this same origin, and the thing stopping you is a network-layer rule rather than the application’s own authorisation.

Reading the 403 correctly

Requesting the admin path returns a 403 — but the Server header on that 403 is the edge proxy, not the application.

That single header is the entire diagnosis. If the application itself were refusing, the response would come from the app’s own server. A response produced by the thing in front of the app means the request never reached the app — so the app has never had an opinion about whether you’re allowed. The access control has been pushed up a tier, and the tier below is still serving the content.

Where the two tiers disagree

The edge matches the protected path as a literal string. The application’s router, like almost every modern web framework’s, canonicalises the request path before routing — it collapses duplicate separators, decodes percent-encoded characters, and normalises trailing slashes. Every one of those normalisations turns a path that the edge does not recognise into the exact path the app does.

So a handful of equivalent spellings of the same path render the admin console, while the one spelling the edge was told to block is the only one that gets stopped. The bypass doesn’t require any encoding cleverness beyond knowing that the two tiers normalise differently — the hard part is recognising that they do.

Why this generalises

The bug isn’t “the regex was incomplete”. It’s authorisation enforced at the wrong tier. Any time a rule is applied in front of the application rather than inside it, the application is still happy to serve the same content through any other path that reaches it:

• a different spelling of the same path,
• a different hostname that routes to the same backend,
• an alternate port or direct-to-origin connection,
• a method the proxy’s rule never considered.

Testing these is cheap and almost always decisive, and it belongs before reaching for anything heavier. The proxy is not the application, and “the edge blocks it” is not the same sentence as “it is protected”.

A practical checklist for any path a front-end tier claims to protect — all of these are things the edge commonly fails to recognise while the origin happily serves them:

• a doubled separator, an omitted separator, or a trailing separator that the rule didn’t anticipate;
• percent-encoded characters anywhere in a path segment, including the segment separators themselves;
• case changes, where the app routes case-insensitively and the rule does not;
• the path reached under a different hostname, a different port, or a direct-to-origin address that bypasses the front tier entirely;
• the same resource addressed by an ID rather than by name.

Each is a one-line change to the request, and each either works or rules out the whole approach in seconds. Working through them is far cheaper than concluding the endpoint is protected and moving on.

Takeaways

• A 403 whose Server header belongs to the proxy means the app never saw the request — and therefore never applied its own authorisation.
• Enforce authorisation in the application. Edge rules are a second line, never the only one.
• Whenever a path is “blocked”, enumerate equivalent encodings and normalisations before assuming the block holds: double separators, percent-encoding, encoded trailing separators.
• The same backend is often reachable by more than one name, port or route. Try them.
• Hints in the UI (“internal only”, “blocked at the edge”) describe the architecture — take them literally.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

Two vhosts on one host: a supplier-facing portal and a separate reviewer console. The supplier signup is open, so the first job is just to register and start poking at the invoice workflow — which begins with a spreadsheet upload.

Bug one: filter bypass by encoding

Invoice uploads are parsed server-side: the application pulls an XML part out of the submitted spreadsheet and parses it with a parser configured to load a DTD and resolve external entities. That’s a classic XML external entity injection, and the only thing standing in front of it was a byte-level filter looking for the ASCII spellings of the DOCTYPE and ENTITY keywords.

That filter is trivially defeated by encoding. Declaring the document as UTF-16 and writing it out with a byte-order mark meant the parser auto-detected the encoding and processed the inline DTD as normal — while the filter, scanning bytes, saw none of the ASCII sequences it was looking for.

The general lesson outranks the specific payload: a filter that inspects raw bytes is not a check on what the parser will actually see. Any time a defensive control operates at a different layer from the component doing the work, look for an encoding, normalisation or representation gap between them.

The result was arbitrary local file read as the web user. Swapping the entity’s URL scheme for an encoding filter let me pull the application’s own configuration and source without triggering parse errors — which is the important escalation here. XXE is an information disclosure bug, but the information is the source code, and that changes the next step entirely.

Bug two: an allow-list that includes the wrong field

Reading the profile-update handler from source showed the classic mass-assignment pattern: the code loops over every submitted field and writes the ones that appear in an allow-list. The allow-list is the fix — except this one contains role.

So a supplier could update their own role. One request, and the same credentials now authenticated against the reviewer console, with access to the whole invoice review queue.

This is worth calling out as a pattern rather than a one-off: allow-lists fail in exactly one way — they contain one field too many. When you read an update handler, the allow-list is the first thing to check, and any field that maps to authorisation is an instant finding.

The blocker: a gadget that the runtime killed

The intended finish was remote code execution via a deserialization gadget chain, using an object-destruction method found in the codebase that performed an arbitrary file write. The delivery mechanism was a URL wrapper that the upload parser would resolve, which would trigger the destructor.

It does not work on the installed version. The current major release of the runtime has removed that wrapper-triggered deserialization path entirely, so the destructor never fires. I confirmed every delivery route I could think of was dead — no persistent upload path, the progress-tracking upload feature disabled, log output properly escaped — and the gadget would only fire on a version several majors older.

So the box ends here: two confirmed bugs, complete source read, reviewer-level access, and a documented blocker on the final hop. No flag.

Dead ends (worth recording)

Also ruled out and confirmed negative: SQL injection in the console’s sort/filter parameters (properly whitelisted), XSS in the queue rows (correctly HTML-escaped), environment recovery from the web worker’s /proc entry (the server strips worker environments), gopher and dict schemes through the entity resolver (not supported by the XML library), and a classic reverse-proxy path-normalisation trick (not vulnerable here).

Takeaways

• Byte-level filters do not describe what the parser sees. Encoding, BOMs and normalisation are the gap between the two — and that gap is the bug.
• XXE’s real prize is usually source code, not /etc/passwd. Read it, then let the code tell you what the next bug is.
• In any update handler, the allow-list is the finding. A privileged field on the list is mass assignment.
• Encoding a payload isn’t just for WAFs — it’s how you slip past a control written at the wrong layer.
• Document the blocker. A writeup that ends “and here’s the thing that is genuinely patched in this version, with everything I tried” is more useful than a fabricated ending.
• Version matters. Gadget chains and deserialization vectors die when runtimes change — check the installed version before investing hours in a payload.

Spoiler-light notes — no flags, credentials or copy-paste exploits. Solve it yourself first.

Recon

A single port is open. ICMP is filtered, so the scan needs to skip host discovery. The web root answers with a redirect to a virtual hostname, which means the interesting content is name-based, not path-based — add the vhost locally and the site resolves properly.

Fingerprinting gives a reverse proxy in front of an application server, and a session cookie that is the obvious prize. Enumerating the pages finds the usual small-business set — a home page, a staff directory, a FAQ, a contact form, and a staff portal that redirects to a login.

The FAQ is the actual finding. One line says a clerk reviews new enquiries from the contact form every morning. That single sentence reframes everything: user-submitted input is going to be rendered in front of an authenticated browser, automatically, on a schedule. If that rendering is unsafe, we don’t need to attack the login at all — we can attack the reviewer.

What didn’t work

Worth recording, because it’s where most of the time went:

• Common credentials on the staff login — all rejected identically.
• NoSQL-style operator injection in the login body — the application refused the JSON shape outright, and the bracket-notation form failed too. The body parser clearly isn’t configured for nested objects.
• Classic SQL injection — no change in response size or content.
• Reflected template injection through the contact form — several template syntaxes were tried, and none appeared in the response. That’s the clue: the input isn’t reflected back to us, it’s stored for someone else. Re-testing for reflected output was the wrong test.

The bug

The contact form’s message field is stored and later rendered as raw markup on the internal review page, with no output encoding. That makes it stored cross-site scripting, and because the reviewer is an automated browser rather than a person, it needs no social engineering or user interaction to fire.

Two design decisions turn a scripting bug into a full account takeover:

1. The reviewer’s session cookie isn’t HttpOnly, so the page’s own JavaScript can read it.
2. The reviewer’s session is a normal, long-lived authenticated session with access to the staff area — not a scoped, short-lived service identity.

Exploitation

The whole chain is four steps:

1. Stand up an HTTP listener on the attack host.
2. Submit a contact message whose body is a script tag that ships the reader’s document cookie (and current URL) to that listener.
3. Wait for the reviewer to process the queue. The script executes in the reviewer’s browser context, so the cookie that arrives is its cookie, not ours. It also reveals the internal address of the staff area, which is only reachable from inside the host.
4. Replay the captured cookie against the staff portal through the proxy. The session is accepted and the protected page renders — including the flag.

No password was guessed and no vulnerability in the login itself was needed. We borrowed a session by making the application render our input for someone else.

Why it worked

• Stored, not reflected. Blind XSS is easy to conclude “not vulnerable” on if you’re only looking at your own response. The signal here was a form with no visible output at all — that’s exactly when to reach for the stored class.
• Unencoded output in an internal view. The review page was treated as trusted because “only the clerk sees it”. That’s backwards: the clerk is the highest-privileged reader.
• Cookie scope. Missing HttpOnly is what converted “I can run script as an admin” into “I have the admin’s session”.
• Automation improves reliability. A human might not click the link. A bot runs every morning, on every submission, forever.

Takeaways

• A FAQ or marketing line describing an internal process is reconnaissance gold — “a clerk reviews this daily” is a statement about an automated consumer of your input.
• When a form produces no visible output, test for stored injection, not reflected.
• Stored XSS against a bot is a session-theft primitive, not a popup.
• HttpOnly on session cookies is the control that breaks the exfiltration step even when the XSS exists.
• Automated reviewers should run sandboxed with minimal, short-lived credentials — never with a long-lived authenticated session.
• A restrictive Content Security Policy is worth having, but the exfiltration here happened through a plain image/URL request, so treat CSP as one layer, not the answer.