ZeroPath at Black Hat USA 2026

Brief Summary: WordPress Form Notify Plugin CVE-2026-5229 Authentication Bypass via LINE OAuth Cookie Trust

A short review of CVE-2026-5229, a critical authentication bypass in the WordPress Form Notify plugin that allows unauthenticated attackers to take over any account, including administrators, by injecting a crafted cookie during the LINE OAuth flow.

CVE Analysis

6 min read

ZeroPath CVE Analysis
ZeroPath CVE Analysis

2026-05-15

Brief Summary: WordPress Form Notify Plugin CVE-2026-5229 Authentication Bypass via LINE OAuth Cookie Trust
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A single trusted cookie in a WordPress plugin's OAuth callback is all it takes for an unauthenticated attacker to log in as any user on the site, including administrators. CVE-2026-5229, scored at CVSS 9.8, exposes this exact flaw in the Form Notify plugin's LINE OAuth integration, where a client controlled cookie determines which WordPress account gets authenticated.

Form Notify (full name: "Receive Notifications After Form Submitting – Form Notify for Any Forms") is a WordPress plugin developed by Oberon Lai that handles form submission notifications. It has a small footprint with over 20 active installations on the WordPress plugin repository. Its relevance here stems from its integration with LINE, a messaging platform widely used in East and Southeast Asia, which it leverages for OAuth based login functionality.

Technical Information

The root cause of CVE-2026-5229 is an unverified fallback mechanism in the plugin's LINE OAuth callback handler. When a user authenticates via LINE OAuth, the plugin needs an email address to match the LINE identity to a WordPress account. However, LINE does not always provide an email address; this is common among users in the plugin's target demographic, where LINE accounts are frequently created without binding an email.

To handle this scenario, the developer implemented a fallback: the plugin reads a cookie named form_notify_line_email from the client's browser and uses its value as the email address for account lookup. The vulnerable code in Route.php (lines 116 through 118) performs this fallback:

if ( isset ( $_COOKIE['form_notify_line_email'] ) ) { $line_email = sanitize_text_field( wp_unslash( $_COOKIE['form_notify_line_email'] ) ); } $user_email = ( $user->email ) ? $user->email : $line_email;

The critical flaw is that the plugin applies sanitize_text_field to the cookie value (preventing XSS) but never verifies that the LINE account completing the OAuth flow is actually associated with that email address. The cookie is entirely client controlled, meaning any value can be injected by the attacker.

The vulnerable code paths span multiple files:

  • src/APIs/Line/Login/Route.php (lines 116 through 118): The cookie fallback assignment
  • src/APIs/Line/Login/User.php (line 53): Where the email is used for user lookup
  • src/APIs/Line/Login/User.php (line 72): Where the authenticated session is established

Attack Flow

The exploitation of this vulnerability is straightforward and requires no prior authentication:

  1. Target identification: The attacker determines the email address of a target WordPress user. For administrators, this is often discoverable through author pages, public profiles, or common information disclosure patterns in WordPress.

  2. Cookie injection: The attacker sets a browser cookie named form_notify_line_email with the value of the target's email address. This can be done through browser developer tools, a proxy, or any HTTP client.

  3. OAuth flow completion: The attacker initiates the LINE OAuth login on the target WordPress site using their own valid LINE account. Crucially, the attacker's LINE account should not have an email bound (or LINE should not return one), which triggers the fallback path.

  4. Account takeover: The plugin reads the attacker's injected cookie, resolves it to the victim's WordPress account, and authenticates the attacker as that user. If the target email belongs to an administrator, the attacker now has full administrative access to the WordPress site.

The entire attack requires only two things: knowledge of the target's email address and a valid LINE account. No special tooling or elevated privileges are needed.

Why This Pattern Is Dangerous

This vulnerability is a textbook example of why client controlled data should never be trusted for authentication decisions. The cookie was introduced as a usability feature for users without email addresses on their LINE accounts, but it created a direct path from unauthenticated request to arbitrary account access. The sanitize_text_field call provides input sanitization but not identity verification; these are fundamentally different security concerns.

Affected Systems and Versions

The vulnerability affects the following:

  • Plugin: Receive Notifications After Form Submitting – Form Notify for Any Forms
  • Affected versions: All versions up to and including 1.1.10
  • Vulnerable configuration: Any WordPress site with the Form Notify plugin installed and LINE OAuth login enabled
  • Fixed version: 1.1.11 (comprehensive security hardening with LINE sub based identity binding)

Version 1.1.10 removed the cookie fallback but still used email based identity binding. Version 1.1.11 is the recommended target for updates, as it shifts identity binding to the verified LINE sub identifier stored in WordPress user meta.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Jira
  • Linear
  • Slack
  • Security Compass
Security magnifying glass visualization