CVE-2026-16977 is a second-order SQL injection in the Form Maker plugin (versions before 1.15.45) that executes when administrator-accessed choice fields pull from database records originally submitted by low-privilege users. The attack path: a subscriber submits a payload through a form with dynamic choice fields; the value is stored without immediate execution (the developer likely used wpdb::prepare on the insert, believing the job was done); later, when an administrator views form results and the plugin retrieves those stored values to populate dropdowns or radio options, the payload executes in the admin query context. This is not a direct injection at submission time — it's a delayed execution that crosses the subscriber-to-admin privilege boundary.
The critical failure is temporal: the protection was applied to the wrong query. Prepared statement parameterization protects the query being executed right now, not queries that will eventually consume that data. WordPress's wpdb::prepare() creates a false belief of comprehensive security when it's actually a per-query guard. The plugin architecture makes this trap nearly inevitable — dynamic choice fields exist specifically to decouple "what the user submitted" from "what appears in choices," which is exactly the design pattern that enables second-order injection.
What makes this severe: no admin credentials required. Subscriber accounts — often used for newsletters, abandoned registrations, or beta testing — are treated as harmless throwaway accounts by the WordPress ecosystem. This vulnerability collapses that assumption. The attacker doesn't need sustained access or complex chaining; just a valid subscriber account and knowledge that their submitted value will execute in a different code context.
But patching the retrieval query doesn't fix the problem. Contaminated records from the vulnerable period remain in your database, carrying payloads that will execute every time any future query consumes them. Old form submissions from 2024 are still sitting in your database, waiting. This is the sediment problem: patches fix code, not data. Each downstream query that reads those contaminated values can spawn new contaminated records in adjacent tables — exports, dashboards, API feeds, backups. The exposure compounds forward.
Action items: First, identify whether Form Maker versions before 1.15.45 ran on this site and upgrade immediately. Second, audit the database for malicious payloads in form submission tables — don't assume the upgrade cleaned them. Third, trace every downstream path those records traveled: export tables, related plugins, backup files. Fourth, treat all stored user input as potentially privileged regardless of the submitting role, because retrieval context is unknowable at submission time. This isn't a code review problem — it's a data lifecycle problem the WordPress plugin ecosystem has no protocol for addressing.