Why is calling str.format on a user-supplied template string dangerous?

### The scenario A payroll system imports timesheet CSVs, and someone adds a convenience: administrators can configure the one-line summary that each imported row produces, stored as a template string in the database and rendered with `row_template.format(row=row, batch=batch)`. It ships on a three-week release train and nobody flags it, because the people who can edit templates are trusted staff. Two problems arrive with it, and only one of them needs a malicious insider. ### Failure mode one: attribute traversal A `str.format` replacement field is more than a name. Its grammar allows a positional index or a keyword, followed by any number of `.attr` accesses and `[key]` lookups. That is a read-only walk, but it starts at whatever objects you handed to `format`, and Python objects are richly connected. From any instance you can reach its class, from a class you can reach a function it defines, and every Python function carries `__globals__` — the module namespace it was defined in, complete with whatever the module holds at import time: signing keys, API tokens, database URLs. So: ```python "{row.__init__.__globals__[SIGNING_KEY]}".format(row=some_row) ``` prints the key. No calls happen, which is why this is disclosure rather than direct code execution — the field grammar has no call syntax at all — but a template that can read arbitrary module globals is usually the end of the story anyway. Passing only plain scalars narrows it considerably: a `str` argument exposes little of interest, because the builtin types' methods are C-level slot wrappers with no `__globals__` dict. It does **not** close the hole, and it is fragile — the next change that passes a rich domain object, a settings object, or `self` reopens it silently. Never render an untrusted template with `**locals()` or `**vars(config)`. ### Failure mode two: unbounded memory growth The second problem needs no attacker at all, only a typo. Width and precision in the format spec are unbounded integers, so a fifteen-character template can demand an enormous allocation: ```python len("{v:>100000000}".format(v="x")) # 100_000_000 ``` That is a hundred megabytes of padding per rendered row. Run it once per line of a large import and the worker's resident memory climbs until the process is killed — a template-driven allocation, so it looks nothing like a normal leak in the metrics. Precision does the same on floats: an absurd `.precision` on a fixed-point conversion produces a similarly enormous string. The `%` operator shares this weakness even though it cannot traverse attributes. ### The mitigation ladder **1. Do not accept a template.** Most "configurable message" features are really a choice of which fields to include and in what order. A checklist of column names plus a separator gives users what they wanted and leaves you with a template you generated yourself. This is the fix; everything below it is damage control. **2. Use `string.Template`.** Its grammar is `$name` and `${name}` and nothing else: no attribute access, no indexing, no format specs, so both failure modes vanish by construction. `Template.substitute` raises `KeyError` for an unknown placeholder and `ValueError` for malformed syntax; `Template.safe_substitute` leaves unresolved placeholders in the output instead, which is what you want when a half-valid template must not take down the import. **3. Restrict `str.format` with a `string.Formatter` subclass.** Override `get_field` to reject any field name that is not a plain identifier from an allow-list — `str.isidentifier` plus a set membership test is enough — and override `format_field` to reject a non-empty spec, or to parse and bound the width. This keeps the familiar `{name}` syntax for users who already have templates. **4. Validate at the boundary as well as at render time.** Templates are stored data; check them when they are saved, so a bad one is rejected by the person who wrote it rather than by the batch job at 3 a.m. ### What about f-strings? An f-string cannot be the vulnerability here, because it cannot be the feature: it is a literal compiled into your source, and there is no way to supply one at runtime. The only way to make user text behave like an f-string is `eval`, and that is not a smaller version of this problem — it is arbitrary code execution, strictly worse than reading globals. If you see `eval` used to render a template, that is the finding. Separately, 3.14 added t-strings as a different mechanism for the inverse problem — safely rendering *values* into a structured target — but they too are literals, so they do not make a user-supplied template safe either.