The vulnerability in phpList stems from a framework-level design decision that treats missing CSRF tokens as an implicit permission to skip validation, rather than as a missing security requirement. The verifyCsrfGetToken() function accepts an enforce=false parameter, and in lists/admin/admins.php, that escape hatch was exercised: when the token is absent from a GET request, the function returns early and the delete action proceeds without verification.
This is not merely a local coding error — it is a systemic incentive toward insecurity built into the toolchain. The framework provides two paths: one that validates and one that does not. Neither path produces warnings or errors. Developers under time pressure will take the path of least resistance. The specific consequence here is severe — a GET-based deletion endpoint for super-administrator accounts, reachable via image tag injection in emails — but the pattern is the real story.
The fix (changing enforce=false to enforce=true at this call site) confirms the diagnosis rather than refuting it. The enforce parameter still exists. The escape hatch remains. This is the third generation of the same failure: first-generation frameworks had no CSRF protection; second-generation made it opt-in; third-generation (like phpList) provides protection that can be defeated by a caller's choice of parameter value. Each generation was supposed to fix the previous, and each inherited the core weakness — security as a call-site decision rather than a route-level constraint.
For defenders: audit your codebase for other state-changing GET endpoints that use enforce=false. The discovery of one such endpoint via image-tag injection implies others likely exist with the same pattern. The prevalence of GET-based admin actions in phpList reflects inherited assumptions about trusted administrative contexts that modern security standards would flag. This is technical debt — code that outlived its threat model and was never audited because it never produced an incident until now.