CVE-2026-5229: Form Notify WordPress Authentication Bypass

What Happened, in Brief

CVE-2026-5229 is a critical Form Notify WordPress vulnerability involving the plugin’s LINE OAuth login flow. When LINE does not provide an email address, the application may use a client-controlled form_notify_line_email cookie. The cookie value is not adequately bound to the authenticated LINE account.

An unauthenticated attacker may complete OAuth using their own LINE account while supplying the email address of another WordPress user. If the targeted account is an administrator, successful exploitation could result in full site compromise.

The practical risk exceeds that of a typical plugin defect because the vulnerable code participates directly in account authentication. Attackers do not need an existing WordPress account or administrative privileges before attempting the attack.

Administrators should treat every site running Form Notify 1.1.10 or earlier as exposed until the exact fixed release is confirmed. If the plugin is not essential, removal or disabling is the safest immediate control.

Analyst’s Take: The first priority is containment, not waiting for a confirmed fixed version. Disable or remove Form Notify where possible, then verify the release contents before re-enabling it. The absence of a confirmed in-the-wild exploit does not offset an unauthenticated path to administrator access.

What’s the Root Cause?

The root cause is improper trust of user-controlled cookie data in an authentication decision. When the LINE identity does not include an email address, the plugin falls back to the form_notify_line_email cookie. That value originates from the client and is not sufficient proof of ownership of the corresponding WordPress account.

The OAuth transaction proves—or is intended to prove—that the user authenticated to a LINE account. It does not prove that the same user controls the WordPress account associated with an arbitrary email address supplied in a cookie. The vulnerable implementation fails to cryptographically or logically bind those two identities.

The attack creates an identity-confusion condition:

1. The attacker authenticates to LINE using an account they control.
2. The attacker modifies or injects form_notify_line_email.
3. The plugin reads the attacker-selected email address.
4. WordPress authentication is performed for the matching local account.

Because the selected account can be an administrator, the vulnerability can lead to privilege escalation and site takeover. This is not merely an account-enumeration or session-integrity issue; it undermines the authentication boundary.

Who Needs to Act

Sites using Form Notify for WordPress version 1.1.10 or earlier need to act. The available vulnerability description identifies those versions as affected. The product may be installed on sites that use its LINE login or related form-notification functionality, so administrators should inventory both active and inactive plugin installations.

The exact first non-vulnerable release could not be confirmed from the available NVD record and referenced project material. Two public project commits are associated with remediation:

• 5eab0ea
• 9780764

Do not assume that any version newer than 1.1.10 is safe without confirming that the release contains the relevant authentication fix. Verify the release notes, compare the installed source with the remediation commits, or obtain confirmation from the project maintainer.

Why This CVSS Score?

The reported CVSS base score is 9.8, placing the vulnerability in the Critical category. The available NVD response did not return the complete CVSS vector, so the exact metric selections should not be reconstructed as fact. The reported score is consistent with a remotely reachable authentication bypass that requires no prior privileges and can affect confidentiality, integrity, and availability.

The attack does not require an attacker to be on the local host or to possess an existing WordPress account. The vulnerable workflow is exposed through the web application’s LINE OAuth integration, making the relevant attack path network-accessible. Successful exploitation may grant access to a victim account, including an administrator account, which explains the potentially complete impact.

The score should not be interpreted as proof that every deployment will be compromised. Exploitability may depend on the plugin being enabled, LINE login being configured, the target account’s identity data, and the application’s surrounding controls. Those conditions do not reduce the need for prompt action because a successful administrator takeover can lead to content modification, credential theft, malware deployment, and further compromise.

Has It Been Exploited?

No verified in-the-wild exploitation was identified in the retrieved NVD or CISA data. CVE-2026-5229 is not listed in the CISA Known Exploited Vulnerabilities catalog, so there is no CISA-confirmed exploitation, KEV due date, or CISA-mandated remediation deadline associated with this CVE.

That status is not evidence that exploitation is impossible or that no incident has occurred. CISA KEV inclusion is selective, and absence from the catalog means only that the available CISA data does not confirm exploitation. Organizations should still prioritize the issue because the attack path is unauthenticated and the impact can include administrator takeover.

No standalone public exploit repository or formal proof-of-concept was identified in the retrieved material. Public source references and remediation commits expose the relevant authentication logic, which may allow researchers to reproduce the issue, but those materials should not be described as a confirmed weaponized PoC.

WordPress Plugin Security Checklist

For organizations managing multiple WordPress sites, remediation should include more than updating one plugin. Maintain an inventory of active and inactive plugins, enforce least privilege for administrators, require multifactor authentication, monitor OAuth login events, and test restoration from clean backups.

Document the affected sites, installed versions, exposure windows, evidence collected, and validation steps. Teams that manage infrastructure through declarative workflows can also record the required plugin state and monitoring controls in a GitOps security checklist.