The CVSS 6.5 on this IDOR is misleading. Yes, it's constrained to attachments where author_id = 0—but that constraint is exactly what makes it dangerous rather than benign.
These authorless attachments aren't random media library files. They include guest submission uploads in progress and plugin-generated placeholders that themes and workflows depend on. Deleting them mid-submission breaks the workflow outright. Removing placeholder images that front-end elements reference cascades into broken visuals across potentially thousands of pages with no graceful degradation. The blast radius doesn't scale with how many deletable files exist—it scales with how deeply those specific files are woven into operational dependencies.
The deeper problem is the access control logic itself. The developer implemented an ownership check that skips entirely when author=0, treating 'no author' as a proxy for 'no authorization needed.' This is a common WordPress assumption error: author=0 is a valid, intentional state for system-generated and anonymous uploads, not an ownerless condition. The correct fix is capability-based authorization—checking edit_post and delete_post capabilities regardless of the author field—rather than gating on metadata existence.
This pattern almost certainly exists elsewhere in the plugin. The 'skip check if no author' logic likely propagates across move, reassign, and metadata modification operations. A patch addressing only the deletion endpoint leaves surgical impact vectors open. Treat this as an access control audit trigger, not a single-endpoint fix. The author=0 convention is abandoned knowledge in many codebases—assumptions inherited from people who inherited them from people who stopped questioning years ago. That's the real exposure: not this CVE, but the cluster that follows if you only patch the deletion path.