This CVE exposes a trust boundary failure in how the plugin normalizes OAuth provider responses. The normalize_common() function consumes the email field from Spotify's API as if it were a verified claim, then passes it directly to WordPress's get_user_by('email') and wp_set_auth_cookie() — creating an authentication shortcut that assumes email uniqueness equals identity verification. OAuth 2.0 explicitly delegates mailbox ownership verification to the client application; the authorization server only confirms the user controls the provider account, not that the email within it belongs to them. Spotify's /v1/me endpoint returns the email as a convenience, not a certification.
The vulnerability is structural, not incidental. normalize_common() is a normalization layer that strips provider-specific verification metadata and produces a flattened profile object downstream code treats as equally trustworthy regardless of source. This abstraction pattern has appeared across multiple OAuth integrations — the verification signal exists in provider specs and OIDC, but client libraries consistently make it ergonomically invisible: no gate, no warning, no builder pattern that forces developers to acknowledge the distinction between a returned email and a verified one.
Two factors amplify this beyond its CVSS 8.1 score. First, WordPress administrative access opens onto plugin injection, theme editing, and database manipulation — this isn't a user account compromise, it's a complete site compromise. Second, the plugin ecosystem's remediation latency runs weeks to months, not hours. The disclosed-but-unfixed state is the actual hazard: every day without the email_verified gate is a day where the exploitation pathway is public knowledge against an installed base with slow patch cycles.
Check whether your OAuth integration preserves and acts on email_verified signals from any provider that supplies them. If you're using a normalization layer, audit whether it strips verification metadata. Consider adding a local ownership assertion — a challenge-response step, email verification link, or at minimum a warning prompt — before treating federated email claims as authenticated identities.