extract() — Dangerous Variable Injection
debt(d5/e3/b3/t9)
Closest to 'specialist tool catches it' (d5). The detection_hints list phpstan, rector, and phpcs — all specialist static analysis tools. The misuse won't cause a syntax error or be caught by a default linter pass; it requires running a dedicated SAST/static analysis tool configured to flag extract() usage.
Closest to 'simple parameterised fix' (e3). The quick_fix metadata is mismatched (it describes extract-method refactoring, not extract()), but the common_mistakes indicate the fix is to remove extract() calls and replace them with explicit variable assignment or use EXTR_PREFIX_ALL — a localised change within the affected function/file, not a cross-cutting refactor.
Closest to 'localised tax' (b3). While extract() applies across web, cli, and queue-worker contexts, the problematic call sites are individual functions or scripts. Misuse is contained to the scope where extract() is called rather than imposing a system-wide structural constraint. Each instance is a localised problem, not an architectural gravitational pull.
Closest to 'catastrophic trap — the obvious way is always wrong' (t9). The misconception field states exactly this: developers believe extract() is a 'convenient way to unpack arrays' — the natural, obvious usage (extract($_POST), extract($_GET)) is precisely the critical security vulnerability. The 'helpful' default behavior (EXTR_OVERWRITE) means the intuitive approach is always the dangerous one, matching the t9 anchor perfectly.
Also Known As
TL;DR
Explanation
PHP's extract() imports array keys as variable names into the current scope. When called on user-supplied data ($_GET, $_POST), an attacker can inject keys that overwrite existing variables — including security-sensitive ones like $isAdmin or $userId. This is a classic variable injection vulnerability that has caused many historical exploits. Avoid extract() entirely; destructure arrays explicitly or use named keys.
How It's Exploited
Common Misconception
Why It Matters
Common Mistakes
- Using extract($_POST) or extract($_GET) — attacker controls every variable in scope.
- Using extract() with EXTR_OVERWRITE (the default) on any array that could contain attacker-influenced keys.
- Not using extract()'s EXTR_PREFIX_ALL flag when extraction is genuinely needed — prefixed variables avoid collision.
- Trusting 'safe' keys because the array was built internally — over time array contents grow and the assumption breaks.
Code Examples
extract($_POST); // user can inject arbitrary variables$username = $_POST['username'] ?? ''; $email = $_POST['email'] ?? '';