TL;DR

The challenge hid a classic UNION-based SQL injection behind a base64-encoded parameter. The app decoded pic and interpolated it straight into a MySQL WHERE name = '<INPUT>' clause. No WAF on quotes, no parameterization, one column, MySQL 8.0.46. Flag extracted with a single UNION query against a secret_vault table found via information_schema.

Winning payload:

GET /challenge.php?pic=eCcgVU5JT04gU0VMRUNUIGdyb3VwX2NvbmNhdChub3RlKSBGUk9NIHNlY3JldF92YXVsdC0tIA==

where pic decodes to:

x' UNION SELECT group_concat(note) FROM secret_vault-- 

(The trailing space after -- matters. More on that later.)

The target

"Critter Gallery" — a cute animal gallery on PHP 8.2 behind istio-envoy. The landing page offers eight critters; each detail link looks like ?pic=Zm94 (base64 for fox). Selecting one renders a detail view with the critter's name and a one-line description.

First recon notes:

• No CSP header. Anything goes, output-wise — but that's a hint, not the bug.
• Unknown values echo their base64-decoded bytes (HTML-escaped) into the page's <h2> tag. So the server decodes the parameter before using it.
• The app is tiny. One parameter, one lookup. When the attack surface is this small, the parameter is the app.

Step 1: Building an error oracle out of nothing

I fired a handful of decoded-garbage inputs at the parameter to map its behavior, and hit something odd immediately: some inputs returned a completely empty 200 response. Not a 500. Not an error page. HTTP 200 with zero bytes, fast (6ms vs ~20ms for normal responses).

Mapping which inputs lived and died produced a weird pattern:

That last row is where I sat up. Let me walk through the wrong theories first, because the wrong theories are the interesting part.

Step 2: Three wrong theories

Theory 1: SQLite. The quote behavior — '' surviving as an escaped quote, isolated quotes dying — smells exactly like SQLite's ''-inside-a-literal escaping. I burned several probes down this path before checking it.

Theory 2: a quote-filter with odd/even pairing. '''' survived, ''' died, 'a' died but a''b survived. I spent a while trying to derive a pairing rule that fit the data. There wasn't one — because the rule wasn't about quotes at all.

Theory 3: output-encoding bugs. All the h2 output was properly htmlspecialchars'd. <script> was fully escaped. The bug was never going to be in the rendering.

The mistake in all three: I was treating the death cases as the signal. The live cases were the signal.

Step 3: 1'||'2 leaking the whole table

The row that broke my theories: 1'||'2 rendered a normal page, but the description block contained all eight critter descriptions concatenated. That's not an echo. That's a query returning every row.

Under "the app wraps input in WHERE name = '<INPUT>'":

WHERE name = '1'||'2'

That parses as name = '1' OR '2'. In MySQL, the || operator is logical OR with numeric casting — and '2' casts to a truthy constant. So the WHERE clause is always true, and every row comes back.

That single observation answered three questions at once:

1. It's SQL injection (results flow into the response)
2. The engine treats || as boolean-OR on numerics → MySQL, not SQLite (SQLite's || is string concatenation and would have returned '12'-style output)
3. The query template has wrapping quotes, and my input must leave the final SQL balanced

The earlier "mystery" quote rule dissolved: every 0-byte death was just MySQL parse error on unbalanced quotes. ''' dies because three quotes don't balance inside the template. 'a' dies because it produces ''a'' — which looks balanced to a human counting quote characters, but the lexer sees ' 'a ' ' — an escaped-quote at the start of a string that then terminates badly. The template's own quotes are part of the count.

The 0-byte 200 response is the error oracle. With display_errors off and output buffering, a MySQL parse error and a normal page differ only in byte count and timing (6ms vs 20ms). Once I treated silence as "syntax error", everything after was fast.

Step 4: Fingerprinting — version(), and the comment trap

x' UNION SELECT 'a rendered a in the description block. UNION confirmed. Column count came from ORDER BY: x' ORDER BY 1-- lived; ORDER BY 2-- died. One column.

Then the gotcha that ate twenty minutes: -- without a trailing space does nothing in MySQL.

Every -- comment payload died with the 0-byte response. I briefly concluded comments were blocked by a WAF. The real story: in MySQL, -- must be followed by whitespace to count as a comment — otherwise it lexes as two minus signs. With the template's trailing quote after my comment, an un-commented ' means unbalanced SQL → death. x' ORDER BY 1-- (with the space) worked instantly.

Fingerprint: x' UNION SELECT version()-- → 8.0.46. MySQL 8.0.46, as suspected.

(Side quest that confirmed it independently: 'abc'||'x' rendered 0 — MySQL casting both strings to 0 for the OR. A second engine fingerprint from a throwaway probe.)

Step 5: information_schema → flag

x' UNION SELECT group_concat(table_name) FROM information_schema.tables-- 

→ animals, secret_vault (plus the information_schema self-noise)

x' UNION SELECT group_concat(column_name) FROM information_schema.columns WHERE table_name='secret_vault'-- 

→ id, note

One more:

x' UNION SELECT group_concat(note) FROM secret_vault-- 

→ INTIGRITI{01a09f56-74a2-700b-a849-ffe6742327b2}

One last quirk: numbers kill the page

x' UNION SELECT 123 — a perfectly valid UNION with the right arity — died. So did SELECT NULL, SELECT 1+1, hex(1), and every function call I tried without the trailing-space comment. Meanwhile SELECT 'a' rendered fine.

The renderer apparently stringifies rows in a way that fatals on non-string values (PHP type coercion on a NULL/int row, most likely). Practical consequence for anyone hitting this: wrap extracted values in string context ('' || value won't work in MySQL for concat — use CAST(x AS CHAR) or group_concat, which returns strings) or just extract with group_concat, which sidesteps the issue entirely.

What I'd tell past-me

1. A 0-byte 200 is data, not a failure. Silent parse errors are an oracle. Treat response shape differences as signal even when the status code doesn't change.
2. Fingerprint the engine before theorizing. One version() with a properly-spaced comment would have saved the entire SQLite detour. Test || semantics early — OR-of-strings vs concat is a two-second discriminator between MySQL and SQLite.
3. MySQL comments need the space. -- not --. This single lexing detail masqueraded as WAF behavior.
4. Base64-wrapped parameters are not sanitized parameters. Decode-then-interpolate is still interpolate.
5. Balance the template's quotes, not just your own. Every payload has to leave the entire statement parseable, including the quote the app appends after your input.

Disclosure: solved during the live challenge window (Sept 21–28, 2026); published after close per challenge rules. This is Intigriti's monthly CTF — no real systems were affected. Thanks to @khanhdlq and the Intigriti team for the challenge.

Find me on Intigriti/HackerOne as sangiihacks.