This vulnerability exposes a design gap in how WordPress AJAX security patterns are implemented in practice. The plugin registered a public AJAX endpoint (wp_ajax_nopriv_gfmu_delete_file) that accepts arbitrary attachment IDs and deletes them without any ownership verification or capability check. This isn't a subtle implementation mistake — it's the logical endpoint of following WordPress's documented AJAX security pattern: register a nopriv handler, localize a nonce into public JavaScript via wp_localize_script, and verify it with wp_verify_nonce().
The critical misunderstanding is that this combination provides zero access control. The nonce in public JavaScript is visible to every visitor — it prevents cross-site request forgery, not unauthorized access when the attacker already possesses the token. The real authorization mechanism in WordPress is capability verification via current_user_can(), but the standard security recipe for AJAX endpoints doesn't include it, creating a class where developers following 'best practices' still produce critical flaws.
What makes this severe: attachment IDs are sequential integers, making them trivially enumerable. An attacker doesn't need reconnaissance — they can script deletion of the entire media library in sequential requests. The blast radius is total infrastructure destruction, not just account compromise.
For defenders: audit all wp_ajax_nopriv_* handlers that accept ID parameters. Verify two things: first, that capability checks exist (current_user_can('upload_files') or stricter); second, that the API enforces ownership — the requesting user must have a legitimate relationship to the resource being modified. A capability check alone is insufficient if users can delete each other's attachments. The fix must scope deletion to attachments created by or associated with the requesting context, not accept arbitrary IDs unconditionally.
The deeper lesson is that WordPress's AJAX architecture places security burden on plugin authors in ways the framework's own documentation obscures. When evaluating third-party plugins, treat any wp_ajax_nopriv handler accepting ID parameters as a high-risk pattern until proven otherwise.