Why is str.format with an attacker-supplied template string a data-leak risk?

### Two strings, and only one of them is yours Every `str.format` call has two inputs: the **template** — the string carrying the braces — and the **arguments**. Most Python code treats the template as inert text with holes punched in it. It is not. The text between the braces is a small expression language, the *format mini-language*, and the interpreter evaluates it against whatever you passed. So the template decides *what is read*; the arguments only decide *what is reachable*. The moment the template comes from a request body, a database row a customer edited, or a config file a tenant uploads, an attacker is writing that expression for you. ### What the mini-language actually permits A replacement field is `{field_name!conversion:format_spec}`. The field name starts with a positional index (`{0}`) or a keyword (`{customer}`) and may then chain, without limit: * **attribute access** — `.name`, which performs the same lookup as `getattr`; * **item access** — `[key]`, where the key is taken literally, as a string unless it is all digits, in which case it becomes an integer index. `{0.a.b[c].d}` is a legal field name. What is *absent* matters as much: there is no call syntax, no arithmetic, no assignment. The primitive an attacker gets is **read**, not **execute**. ### The escalation into module globals Reads are enough. Every Python-level function object carries `__globals__`, the dict of the module namespace it was defined in — and a bound method exposes the same attribute. So if any argument is an instance of a class whose `__init__` is written in Python, the template `{0.__init__.__globals__[API_KEY]}` walks from your object to its method, from the method to the module namespace, and from there to any module-level name: an API token, a signing key, a database URL, a settings object it can keep walking through. ```python API_KEY = "sk-live-not-a-real-key" class Order: def __init__(self, ref): self.ref = ref "{0.__init__.__globals__[API_KEY]}".format(Order("A-1")) # -> 'sk-live-not-a-real-key' ``` Note the chain needs a *Python-defined* function somewhere. `object.__init__` is a C slot wrapper and has no `__globals__`, which is why the payload is usually aimed at your own classes rather than at a builtin — and why "we only pass strings" narrows the blast radius without being a control you should rely on. ### `str.format_map` is not the hardened version `str.format_map` differs from `str.format(**mapping)` in exactly one way: it passes the mapping through instead of copying it into keyword arguments, so a mapping subclass with `__missing__` can answer for absent names. The field-name grammar is identical, and attribute access still applies to the mapped values: ```python "{customer.__class__.__mro__}".format_map({"customer": "ada"}) # (<class 'str'>, <class 'object'>) ``` Reaching for `format_map` because it "only substitutes values" is a very common wrong answer. ### Disclosure, side effects, and amplification Because there is no call syntax, this is primarily an **information-disclosure** primitive rather than remote code execution. Two caveats keep it from being merely theoretical: * **Attribute access runs code.** A `property` getter or a `__getattr__` hook fires during the walk, so anything with side effects behind a property is reachable — including lazily loaded credentials. * **The format spec allocates.** `"{0:>100000000}".format("x")` builds a 100-million-character string from a fifteen-character template. A stored template is a compact memory-amplification bug. ### How this gets into a codebase Nobody writes `request.json["template"].format(...)` on purpose. The pattern arrives sideways: user-configurable notification or webhook bodies; localisation strings pulled from a table that translators can edit; alert templates in a rules engine; "subject line" fields in an admin UI. In all of them the template became **data** at some point, and data crossed a trust boundary while the code still treated it as source. ### The shape of the fix The control is structural, not lexical: **untrusted text must never be the template.** Blocklisting `__globals__`, stripping underscores, or escaping braces in the *values* all miss the point — the values were never the problem. Either pick a placeholder syntax with no attribute or item grammar to abuse, or interpose your own `string.Formatter` subclass that rejects any field name outside an allowlist, and pass it only pre-stringified primitives. ### Version note None of this has moved between Python 3.10 and 3.14; the mini-language grammar is stable. Template strings (t-strings, PEP 750) arrived in 3.14 and are sometimes offered as the answer here — they are not. A t-string is a literal in *your* source, so it addresses how values reach a sink, not who wrote the template.