The vulnerability in this plugin is not a developer mistake — it is a tooling failure. The function sanitize_text_field() is named to imply context-neutral sanitization, but it performs only HTML output encoding. It strips tags and slashes while deliberately preserving single quotes because they're valid in text display. A developer who reasonably concludes "I sanitized this input" has no way to know the value remains unsafe for SQL interpolation. The function's name and behavior are in direct conflict with its actual purpose.
This creates a specific cognitive trap: the developer used the WordPress-sanctioned sanitization function, followed WordPress patterns, and produced SQL injection. The tool chain validated their approach. There was no warning from linting, IDE plugins, or framework behavior that interpolating this value into SQL was dangerous. Compare this to database APIs that make prepared statements syntactically easy and direct interpolation difficult — WordPress's $wpdb->prepare() is opt-in rather than the default.
The capability gate compounds this. Requiring CRM Agent role creates institutional pressure to treat authenticated users as low-risk, but CRM Agents legitimately access the database through application logic. The permission model cannot distinguish between an agent accessing contacts they should access and an agent injecting SQL through field names. The authorization layer doesn't compensate for input validation failures.
For defenders: this vulnerability is not an isolated flaw. It is the natural consequence of an API design that will produce identical vulnerabilities in other plugins using the same pattern. Check every parameter that flows through sanitize_text_field() into $wpdb->get_results(), $wpdb->insert(), or any raw SQL construction. The fix requires $wpdb->prepare() or esc_sql() — not a different sanitization function. If your plugin uses sanitize_text_field() for database input anywhere, treat that code as vulnerable regardless of what the linting tools say.
The broader concern: WordPress holds approximately 43% market share, sanitize_text_field() appears across millions of installations, and the pattern of sanitizing-for-HTML and interpolating-into-SQL is baked into the default development experience. This is not a problem a single plugin patch can solve.