| Event Name | [CTF Event Name] |
|---|---|
| GitHub URL | [Challenge Repo/Code URL] |
| Challenge Name | [Specific Challenge Name] |
The vulnerability stems from how YAML aliasing interacts with delayed data mutation.
Initially, the validation loop checks conf["blogs"][0]["name"]. Later in the execution, the code applies a transformation:
conf["user"]["name"] = display_name(conf["user"].get("name", ...))
If conf["user"] and conf["blogs"][0] are the same dictionary object (created via a YAML alias), writing to conf["user"]["name"] silently overwrites conf["blogs"][0]["name"] after the validation checks have already passed.
Here is the malicious YAML payload used to exploit this:
blogs:
- &ref
title: "flag"
name: "._._/._._/flag"
user: *ref
The yaml.safe_load function creates a single dictionary in memory: {"title": "flag", "name": "._._/._._/flag"}. Because of the &ref anchor and *ref alias, both blogs[0] and user point to this exact same dictionary.
The code validates blogs[0]["name"], which is currently "._._/._._/flag". This successfully bypasses all three security checks:
"../" in "._._/._._/flag" → False (no ../ substring present)