CVE-2026-103752: Unauthenticated Admin Takeover in the WordPress Authorizer Plugin

Overview

A critical unauthenticated privilege escalation vulnerability, tracked as CVE-2026-103752, affects Authorizer, a WordPress plugin (by developer Paul Ryan) that restricts site access and replaces WordPress's default login with external identity providers such as Google, CAS, LDAP, and OAuth2/Azure AD (Microsoft Entra ID). The flaw carries a CVSS 3.1 score of 9.8 (Critical) and was published October 1, 2026, with coordinated disclosure handled by Patchstack (credit: researcher Raphael P. Cigana). It affects Authorizer versions 3.15.3 and earlier; a fix has shipped in 3.16.0.

Important naming note: "Authorizer" is a generic name shared by multiple unrelated open-source projects — notably the Go-based self-hosted auth server authorizerdev/authorizer, which has its own separate, unrelated CVE history (e.g. CVE-2026-54072, an open-redirect/token-theft issue). This advisory concerns only the WordPress plugin, maintained by Paul Ryan and distributed via wordpress.org/plugins/authorizer. Site operators should confirm which "Authorizer" they run before acting on this advisory.

The vulnerability is scoped to sites that have Authorizer's Azure AD / Microsoft Entra ID OAuth2 external-service option configured; sites using only local accounts, Google, CAS, or LDAP are not exposed to this specific vector.

Technical Details

Exploitation status: NVD and Patchstack-sourced listings record this as newly published (October 1, 2026) with no confirmed in-the-wild exploitation and no CISA KEV listing as of publication. A third-party GitHub repository publishing defensive analysis and a passive detection scanner for this CVE is already public, which typically shortens the window before opportunistic scanning begins — sites meeting the affected-configuration criteria below should treat this as actively scannable, not purely theoretical.

How It Works

NVD's description is terse ("Unauthenticated Privilege Escalation in Authorizer ≤ 3.15.3 versions"), so the mechanism below draws on consistent, independently-published technical summaries (Patchstack-sourced vulnerability trackers) rather than an official vendor advisory or patch diff — treat the specific implementation details as analyst reconstruction, not confirmed vendor text.

The "nOAuth" trust pattern

The reported root cause fits a known class of OAuth misconfiguration sometimes called "nOAuth": when a WordPress site configures Authorizer's Azure AD/Entra ID OAuth2 integration as multi-tenant — meaning the plugin's Tenant ID setting is left blank or set to the literal value common — Azure will accept and validate sign-in tokens from any Azure AD tenant or personal Microsoft account, not just the organization's own directory. Authorizer is then reported to resolve the authenticated Microsoft account to a local WordPress account by matching the email address claim in the OAuth token, without an additional step confirming the token actually originated from a trusted, organization-controlled tenant.

That combination is the problem: Azure AD tenants are self-service. An attacker can provision their own Azure AD tenant for free, create a user inside it whose email address is set to match a target WordPress administrator's email (e.g. admin@victim-org.com), and complete a normal, successful Azure OAuth2 login flow against the victim's WordPress site. If Authorizer grants access based on the email claim alone — without verifying the issuing tenant is the organization's own — the attacker is logged in with the matched account's privileges, which can include Administrator.

Why this is unauthenticated

This differs from a typical "authenticated" privilege-escalation bug: the attacker never needs valid credentials for the target WordPress site. They only need the ability to create or control an Azure AD identity bearing the target's email address, which is attacker-controlled infrastructure, not the victim's. From the WordPress site's perspective, the OAuth2 handshake completes normally and the plugin treats the result as a legitimate login.

Reported patch behavior (3.15.3 → 3.16.0)

Per the WordPress.org changelog, 3.15.3 had already introduced tenant-restriction guidance and an optional "require verified email" setting, surfacing an admin notice when the Tenant ID is blank or common — but left that protection off by default, which is consistent with it still being listed as vulnerable. 3.16.0 is described as making that email-verification step mandatory whenever the Tenant ID is unset or common: after a successful Azure sign-in under those conditions, the user must additionally click a one-time verification link emailed to the claimed address before the session is granted, closing the gap where email-claim matching alone was sufficient.

Impact Assessment

Who Is At Risk

• WordPress sites running Authorizer ≤ 3.15.3 with the Azure AD / Microsoft Entra ID OAuth2 external-service option enabled.
• Sites where the Azure AD app registration's Tenant ID is blank or set to common (multi-tenant / "any organizational or personal Microsoft account" mode) are the specifically affected configuration — this is also a common default/convenience setting, so exposure may be broader than operators expect.
• Any site in this configuration is at risk of full Administrator takeover, not just low-privilege account access, since the attacker chooses which existing account's email to impersonate.

Potential Attack Chains

1. Attacker identifies a target WordPress site using Authorizer with Azure AD OAuth2 login enabled (visible login-page branding or OAuth redirect URLs are common fingerprints).
2. Attacker determines or guesses the email address of a privileged account on the target site (e.g. the site's published admin or support contact).
3. Attacker registers a free Azure AD tenant and creates a user whose email/UPN matches that target address.
4. Attacker completes the Azure OAuth2 login flow against the target WordPress site using the attacker-controlled Azure account.
5. Authorizer matches the returned email claim to the existing WordPress account and grants a session with that account's privileges — up to and including Administrator.
6. With admin access, the attacker can install plugins/themes (code execution), create additional admin accounts, exfiltrate data, or deface the site.

Mitigation

Immediate Actions

• Update Authorizer to version 3.16.0 or later as soon as possible.
• If you cannot update immediately: in WordPress Admin → Authorizer → External Service (OAuth2) → Azure, set an explicit, organization-specific Tenant ID (the Directory/Tenant GUID) rather than leaving it blank or set to common. This alone removes the cross-tenant trust gap even on an unpatched version.
• If Azure AD OAuth2 is not actively needed, disable the Azure external-service option in Authorizer until you've confirmed the patched version and correct tenant configuration are in place.
• After updating, confirm your WordPress server can actually send outbound email — the 3.16.0 fix relies on a verification-link email, and a broken mail configuration could lock out legitimate multi-tenant users (though it would not reopen the vulnerability).

Detection Opportunities

• Review web server and WordPress authentication logs for unexpected successful logins via the Azure OAuth2 callback (commonly a authorizer_oauth2=azure or similar query parameter), especially sign-ins correlating with privileged accounts from IP ranges or user agents inconsistent with your organization's normal usage.
• Audit the WordPress Administrator and Editor role lists for any accounts you don't recognize or that were created/modified around unexplained login events.
• If your mail server logs outbound delivery, watch for verification-link emails you didn't expect to legitimate admin addresses after upgrading — repeated unexpected triggers suggest active probing.

Defence-in-Depth

• Apply the principle that any plugin brokering third-party identity into WordPress roles should fail closed on ambiguous trust configuration — treat a blank/common Tenant ID as a misconfiguration to alert on, not a convenience default, for any OAuth2-based WordPress login plugin, not just Authorizer.
• Where possible, pair SSO/OAuth2 logins with WordPress application passwords or 2FA on administrator accounts as a second control that an email-claim mismatch alone cannot bypass.
• Keep WordPress core, themes, and all plugins on a regular patch cadence and subscribe to a vulnerability feed (e.g. Patchstack, WPScan) for plugins handling authentication — these are high-value targets precisely because a single flaw can yield full site control.

Background

Authorizer has been a long-running WordPress plugin (originally developed for University of Hawaii's single-sign-on needs) used to restrict public access to WordPress sites and delegate login to external identity providers — Google, CAS, LDAP, or a generic OAuth2 provider including Microsoft Entra ID. Because it sits directly in the authentication path and is explicitly designed to map external identities onto local WordPress roles, flaws in its trust logic have outsized impact: the plugin's own changelog shows a related but distinct issue fixed in 3.15.1 (an authenticated user impersonating others via OAuth2 attribute spoofing), underscoring that identity-mapping logic in this plugin has been an active area of security hardening across recent releases. The "nOAuth" pattern this CVE reportedly follows — trusting an email claim from a multi-tenant identity provider without verifying the issuing tenant — has affected other SaaS and plugin integrations in past years and is a recurring class of bug wherever "log in with a work or school account" is offered without tenant pinning.

References

• NVD — CVE-2026-103752
• Patchstack — WordPress Authorizer plugin ≤ 3.15.3 privilege escalation
• WordPress.org — Authorizer plugin page and changelog
• GitHub — defensive analysis and detection scanner for CVE-2026-103752

This advisory is based on the NVD record and independently-published, Patchstack-sourced technical summaries; no official vendor security advisory with a line-level patch diff was located at the time of writing. CosmicBytez Labs will update this entry if Patchstack or the plugin maintainer publish additional detail.