In Intigriti Challenge 0926, participant write-ups report that the Critter Gallery decoded the pic query parameter and then concatenated the result into a single-quoted SQL query. Base64 obscured the input on its way to the server; it did not make that input safe. The challenge ran September 21–28, 2026, and is now closed.
What was Intigriti Challenge 0926?
Intigriti’s official challenge page describes Challenge 0926 as a monthly CTF and lists challenge-0926.challenges.intigriti.io as in scope. It ran from September 21, 2026 at 10:00 AM through September 28, 2026 at 11:59 PM UTC. Submissions had to include a flag in INTIGRITI{.*} format, the payloads used, and short solution steps.
As an Amazon Associate I earn from qualifying purchases.
The official page identifies the program as responsible disclosure without bounties; it separately lists challenge swag-voucher awards. When accessed October 4, 2026, the page displayed 325 submissions and 293 accepted submissions. Those are challenge-page activity counts, not SQL injection statistics or permanent totals.
How did the reported flaw work?
A participant account describes a small animal gallery with a ?pic= parameter carrying a base64-encoded animal name and a description rendered below the image. The participant also reports an official clue, “the gallery speaks different languages”; that wording is reported by the write-up, rather than shown on the official listing available here.
#1 Best Overall
The fox comparison pointed to two different behaviors
According to the participant’s write-up, comparing FOX with Fox produced a mismatch: PHP’s image or art matching behaved case-sensitively, while the description lookup followed MySQL case-insensitive comparison and fullwidth folding. The author used that cross-layer difference to investigate the description query. It was a clue in this challenge, not proof by itself that an application has SQL injection.
A decoded quote reportedly broke the query
The participant says a base64-wrapped single quote produced a blank response; a backslash did too, while a double quote did not. They interpreted the responses as evidence that decoded input reached a single-quoted SQL string without escaping. A boolean breakout reportedly caused all eight animal descriptions to appear, indicating that injected logic could affect the result set.
The same account says UNION probing indicated a one-column original query, with union output appearing in the description element. It reports a MySQL 8.0.46 fingerprint, a critter_gallery database, and animals and secret_vault tables. The vault reportedly contained id and note columns, and the author says it yielded INTIGRITI{01a09f56-74a2-700b-a849-ffe6742327b2}. A second participant write-up independently characterizes the issue as unauthenticated UNION-based SQL injection and reports the same flag. These mechanics and results are accounts from participants, not independently verified here.
Why didn’t base64 prevent SQL injection?
Base64 is a reversible encoding, not a security boundary. If an application decodes attacker-controlled content and inserts the decoded value into SQL text, the database can still interpret SQL syntax within that value. The reported failure was unsafe query construction after decoding, not a weakness in base64 itself.
SQL injection occurs when untrusted input changes the structure or meaning of a SQL statement. OWASP identifies dynamically building queries by concatenating user input as a common cause. Its SQL Injection Prevention Cheat Sheet recommends parameterized queries: define the SQL code separately and pass user values as parameters.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should a gallery like this be fixed?
Bind the decoded value as a parameter
If base64 is needed for transport, decode it, then bind the resulting animal name as a value in a prepared statement. Do not append it to the SQL string. Conceptually:
Rank #4
decoded_pic = base64_decode(request.query["pic"])
statement = prepare(
"SELECT description FROM animals WHERE name = ?"
)
result = statement.execute(decoded_pic)The placeholder syntax varies by database library. The key property is that the database receives SQL code and the value separately, so the value cannot redefine the query’s intent.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsUse an allow-list as an additional check
A gallery with a finite set of animal names can reject values outside that set before lookup. That limits accepted input, but it does not replace parameter binding: unexpected values can still be handled safely by a parameterized query.
Do not rely on escaping or another encoding
Escaping is fragile and database-specific, so OWASP discourages using it as the primary defense. Double-encoding the value or swapping base64 for another reversible encoding would not fix concatenation; the decoded input would remain untrusted.
Quick Recap
What to take away from this challenge
- Encoding changes representation, not trust: decoded user input remains user input.
- Behavior differences across application layers can suggest where to investigate, but they do not establish a vulnerability on their own.
- When SQL needs a user-supplied value, parameter binding is the core defense; input allow-lists are a useful additional constraint.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
