CVE-2026-65561

This vulnerability lets a contributor inject JavaScript through their OAuth display name that executes when an administrator reviews their pending post. The CVSS 6.5 rating is misleading because it scores only the initial placement constraint—the contributor's ability to inject—while ignoring that the WordPress review queue architecture deterministically escalates that to admin compromise. Every pending post is a guaranteed admin-execution vector with no additional attacker interaction required. That's not a 6.5 severity issue; that's a near-certain admin takeover. The root cause is a mental model error specific to social login plugins. Developers categorically treat data arriving from OAuth providers as authentication data rather than user input. A display name returned by Google's OAuth endpoint has no obligation to be HTML-safe—it can contain anything a user put into their Google profile—but the developer assumes "this came from a trusted provider" means "this is safe to render." That assumption is the vulnerability. To assess your exposure: examine any WordPress plugin that renders OAuth provider data—display names, email addresses, profile metadata—in an HTML context. The fix is simple: apply standard output escaping (esc_html() or wp_kses()) to any data originating from an external identity provider. But verify the patch actually does this consistently across all rendering paths, not just the one that triggered this CVE. If the fix is a one-off escape on this specific output point, the same mental model error likely exists elsewhere in the plugin. The recurrence risk is high. This exact pattern—OAuth display name flowing into HTML without escaping—has appeared in multiple WordPress social login CVEs over the past decade. The ecosystem keeps propagating the same flawed assumption rather than learning from each instance. Treat any social login plugin you maintain or audit as suspect until proven otherwise.

Reviewed through automated stages and approved by a human before publication.