List-vs-String Type Confusion to Bypass Filename Validation

Validation code often assumes JSON fields are strings and applies substring checks directly. Non-string JSON values skip or break the check, yet later coercion (str(...), f-strings, path joins) turns them into usable paths. The bug is inconsistent typing between validation and use.

Why It Works

• if ".." in filename or any(tok in filename ...) raises or short-circuits on a list/dict, so the blacklist never sees the dangerous content as a string.

Vulnerable Pattern

• Python APIs receiving JSON and checking if ".." in filename before a later str(filename) or path join.
• Code mixing list/tuple/dict inputs with f-strings or implicit coercion.

Exploit Flow

1. Send arrays, objects, booleans, and nulls where a string is expected; compare validation behavior vs. stored result.
2. Once the check is bypassed, aim for a write primitive to a static JS path, template file, or Python module.

Variations

• List values, nested containers, duplicated JSON keys, or framework-specific form arrays.

Common Blockers

• Strict request schemas, type annotations actually enforced by validation libraries, or path normalization after coercion.

PoC Sketch

{"filename":["../../static/js/poc.js"],"content":"alert(1)"}

Good Situations To Use It

• A JSON API blacklists path characters in a filename string.
• The same value is later coerced to a string and used as a path.
• Non-string inputs aren't rejected by a schema.

Sources

• breizhctf2026/web/no_thanks_i_use_ai