Summary — A recently disclosed vulnerability (CVE-2025-10294) in the OwnID Passwordless Login WordPress plugin (versions ≤ 1.3.4) allows unauthenticated actors to bypass authentication controls. The issue is classified as “Broken Authentication” with a high CVSS score. If you run WordPress and use this plugin (or a passwordless authentication flow that integrates with it), follow the guidance below immediately to assess, mitigate and recover if needed.

Why this matters (short)

Passwordless login flows are attractive because they reduce password fatigue for users. They also concentrate trust in a small set of components: callback endpoints, token validation, nonce/state handling and session creation. When any of those checks are incomplete or bypassable, an unauthenticated actor can gain the same rights as a legitimate user — including administrator access. That is precisely the risk reported for OwnID Passwordless Login ≤ 1.3.4.

This post explains the risk, what to look for, and practical steps to protect your site today. The guidance is written from the perspective of a Hong Kong-based security practitioner and is intended for site owners, developers and hosting teams.

Quick actions — what to do now (actionable checklist)

1. If you have OwnID Passwordless Login installed:
   • Deactivate the plugin immediately until a trusted upstream fix is available.

     wp plugin deactivate ownid-passwordless-login --allow-root

2. If you cannot deactivate immediately, restrict access to wp-admin to trusted IPs and enable strict rate-limits at the webserver or edge layer.
3. Monitor logs for suspicious login activity or unexpected user creations (see Detection section below).
4. Implement short-term virtual patching at the edge: block suspicious endpoints and anomalous parameter combinations associated with the passwordless flow (see the virtual patching section below).
5. Rotate credentials and consider forcing password resets or invalidating all active sessions for administrative users.
6. If you suspect compromise, follow the Incident Response & Cleanup section immediately.

Act now — do not wait for an official plugin update if your site is exposed.

Vulnerability overview

• Affected software: OwnID Passwordless Login plugin for WordPress
• Vulnerable versions: ≤ 1.3.4
• Vulnerability type: Broken Authentication (OWASP A7)
• CVE: CVE-2025-10294
• Reported by: Jonas Benjamin Friedli
• Privilege required: Unauthenticated
• Fixed version: N/A (at time of disclosure)

High-level description: The plugin’s authentication flow contains an implementation flaw that enables an attacker to bypass authentication checks and obtain an authenticated session on a target site without valid credentials or consent. The precise exploit vector depends on how the plugin validates callback data and tokens in the passwordless workflow. Because the attack requires no prior authentication, the attack surface is broad and can be exploited remotely.

Technical analysis (what is likely happening)

Passwordless authentication flows normally involve:

• Initiating a login request (user or client triggers a passwordless challenge).
• Generating a challenge or short-lived token, recording state, and sending an out-of-band verification request to the user (email/SMS/OS authenticator).
• Receiving a callback or verification token from the verification provider or from the client.
• Validating the returned token and the session/state, then establishing a WordPress session for the user.

A reliable passwordless implementation must:

• Use cryptographically signed tokens with strict expiry.
• Tie tokens to a specific user and a stored state (nonce), preventing token replay or token swapping.
• Validate origin/redirect URIs and ensure callback requests are legitimate.
• Prevent direct creation or elevation of sessions via uncontrolled endpoints.

In this case, the vulnerability indicates one or more of those validation steps are absent, incomplete or incorrectly implemented — for example:

• Missing or insufficient verification of the callback token.
• Failure to ensure the token is bound to the expected user or state.
• Lack of nonce/CSRF checks on endpoints that create sessions.

Because an attacker can call the vulnerable endpoint unauthenticated, they can forge a request that results in a session for an arbitrary user, potentially including administrators.

Note: This is a high-level technical description to help defenders. Do not share public exploit PoC details — they will help attackers. Focus on mitigation.

Impact — why this is critical

An authentication bypass vulnerability with unauthenticated access has severe consequences:

• Site takeover: Attackers can gain admin access, modify content, create backdoors, or install malicious plugins/themes.
• Data theft: Access to user data, private pages, and stored content.
• Persistent compromise: Attackers may create hidden admin users or scheduled tasks (cron) to maintain access.
• Reputation damage: Defacement, spam or search-engine blacklisting.
• Lateral movement on hosting: On shared environments, a compromised site can be a foothold to attack other accounts if permissions are misconfigured.

Because this vulnerability allows unauthenticated access, the probability of automated mass exploitation is high. Attackers routinely scan for vulnerable plugin signatures and attempt automated login bypasses.

How to detect exploitation on your site

Immediate signals to check:

1. Unexpected admin users:

   • wp user list --role=administrator

   • Dashboard: Users → All Users → filter by Administrator and look for recent suspicious accounts.
2. Recent successful admin logins from unfamiliar IPs:
   • Inspect webserver access logs (nginx/apache) for POST requests to wp-login.php or REST endpoints with 200/302 responses around suspicious timestamps.
   • If you have audit logging, check for admin logins outside normal hours.
3. File changes and new files:
   • Search plugin/theme directories and wp-content for unexpected files. Look for files containing eval, base64_decode, gzinflate or other obfuscation patterns.
   • Sample command (site root):

     find . -type f -mtime -14 -print

4. Database changes:
   • Check wp_options for suspicious autoload entries, new cron jobs, or unexpected values.
   • Example query to review option sizes:

     SELECT option_name, LENGTH(option_value) FROM wp_options WHERE option_name LIKE '%template%' OR option_name LIKE '%cron%';

5. Unusual outgoing traffic: Check firewall and network logs for connections to unknown IPs/domains originating from your webserver.
6. Login activity patterns for passwordless endpoints: Review access logs for POST/GET requests to plugin endpoints or suspicious parameter combinations matching the passwordless flow.

Preserve logs for forensic analysis where possible.

Immediate mitigation options (site owners & admins)

If you run the vulnerable plugin, choose the fastest safe route below:

1. Deactivate the plugin immediately

   Most reliable short-term mitigation. For many sites, WP-CLI is the quickest method:

   wp plugin deactivate ownid-passwordless-login --allow-root

2. If you cannot deactivate:
   • Restrict access to relevant endpoints via webserver rules (deny all IPs except trusted admin IPs).
   • Add an .htaccess or nginx snippet to deny access to the plugin’s files and endpoints producing the vulnerability.
   • Example (nginx, block by URI pattern):

     location ~* /wp-content/plugins/ownid-passwordless-login/ {
         return 403;
     }

   • Be careful — blocking by path may break legitimate features. Deactivation is preferred.
3. Edge/virtual patching:

   Apply rules at the webserver or edge to block requests with suspicious parameter payloads to the plugin’s endpoints, enforce origin and referer checks, and add strict rate limits.

4. Rotate keys and invalidate sessions:
   • Force password resets for admin users:

     wp user update <admin-id> --user_pass='<new-strong-password>'

   • Invalidate active sessions for administrative users where possible.
   • Reset any site-level shared API keys used by authentication flows.
5. Harden admin access:
   • Temporarily restrict wp-admin to trusted IP addresses.
   • Enable two-factor authentication for admin accounts where possible.
   • Consider HTTP Basic auth or an access layer that requires a shared secret for wp-admin during the incident window.
6. Keep backups: Ensure you have known-good backups taken before any suspected compromise. Do not overwrite clean backups with a compromised state.

Virtual patching recommendations (how a WAF or edge layer can protect you now)

Use these layered rules as temporary mitigations until the plugin is fixed or removed:

1. Block or challenge requests to the plugin’s endpoints:

   Identify the plugin’s REST endpoints, admin-ajax actions, and plugin file paths. Block POST requests to those endpoints from untrusted IP ranges or apply a CAPTCHA/JavaScript challenge.

2. Enforce HTTP header checks:

   Require valid Origin and Referer headers for requests that create sessions, and reject requests with missing or clearly forged headers from untrusted clients. Validate Content-Type and disallow unexpected types.

3. Rate-limit suspicious flows:

   Apply strict per-IP rate limits on session-creation endpoints to disrupt automated exploitation. Consider progressive delays or temporary blocking after a small number of attempts.

4. Detect anomalous parameter combinations:

   Create rules to match unusual patterns in token, state, or user-identifying parameters used by passwordless flows (for example, tokens that are too short/long or contain malformed characters).

5. Protect the admin area with an access layer:

   Require additional authentication or IP whitelisting for wp-admin and XML-RPC. This reduces lateral movement risk even if an attacker bypasses a plugin flow.

6. Audit and alert:

   Create alerts for POST requests that result in successful authentication actions without a preceding challenge or a valid state value and forward alerts to administrators for immediate review.

Virtual patching is a mitigation only. Replace or fix the vulnerable plugin as the long-term solution.

Detection signatures and logging suggestions for hosts and edge providers

Create rules to log and alert on the following observable behaviors:

• POST requests to plugin-specific endpoints from clients with no valid session cookie.
• Successful HTTP responses (200/302) from session creation endpoints followed immediately by requests to /wp-admin/ or admin-ajax.php from the same IP.
• Repeated attempts creating or modifying accounts using the plugin’s endpoints.
• Abnormal request volumes for passwordless endpoints from a single IP or small IP range.

Log fields to capture for correlation:

• Timestamp, source IP, User-Agent
• Request URI and query string
• POST body parameter names (avoid logging full bodies if they contain sensitive tokens)
• Response code and response size
• Cookie state and session ID (if present)

Store logs off-host where possible to prevent tampering during an investigation.

Incident response and cleanup (if you suspect a compromise)

If you find evidence of compromise, follow a structured cleanup flow:

1. Isolate the site:
   • Put the site in maintenance mode or take it offline while you investigate and clean.
   • If on shared hosting, notify your host immediately and ask them to isolate the account.
2. Preserve evidence: Make copies of webserver logs, database dumps, and filesystem snapshots for forensic investigation. Do not modify those copies.
3. Rotate credentials and keys: Change WordPress admin passwords and any API keys used by the site. Rotate hosting and database credentials.
4. Remove the vulnerable plugin and replace: Deactivate and delete OwnID Passwordless Login. Replace with a well-reviewed alternative only after independent verification and testing.
5. Search and remove backdoors:
   • Scan for injected PHP files containing eval, base64_decode, preg_replace with /e, create_function, gzinflate, system, exec, shell_exec.
   • Example search:

     grep -R --exclude-dir=uploads -nE "eval\(|base64_decode\(|gzinflate\(|shell_exec\(|system\(" .

6. Inspect database for unauthorized changes:
   • Check wp_users for unknown accounts.
   • Check wp_options for malicious autoloaded code.
   • Check posts for injected scripts.
7. Reinstall core, plugins, and themes from trusted sources: Do not trust files left on a compromised filesystem. Replace them with fresh downloads from official sources.
8. Restore from a clean backup: If you have a clean backup taken before the compromise, restore and then apply security hardening.
9. Post-recovery monitoring: Monitor logs closely for 30+ days after recovery for signs of reinfection. Consider a professional security audit if the site contains sensitive data.
10. Engage professional incident response: For sites handling financial or sensitive personal data, engage experienced incident responders.

Hardening WordPress authentication (long-term)

• Avoid single points of failure: passwordless flows are acceptable only when implemented with signed tokens, nonce binding and strict validation.
• Enforce multi-factor authentication for administrator accounts.
• Minimize admin accounts and apply least privilege.
• Keep plugins and themes updated and only install from reputable sources.
• Use central monitoring and patching processes for all sites you manage.
• Enable logging and alerting for admin logins and unexpected file changes.
• Harden file permissions and disable PHP execution in uploads where possible:

  <FilesMatch "\.php$">
    Deny from all
  </FilesMatch>

• Enforce strong passwords and periodic rotation for admin users.

Recommendations for plugin developers (secure-by-design checklist)

• Use signed tokens (JWT or similar) with short expirations and audience claims.
• Bind tokens to server-side state or nonce and validate on callback.
• Validate redirect URIs and origins strictly.
• Always verify issuer and signature for tokens from third-party providers.
• Avoid creating sessions or elevating privileges on simple GET requests.
• Implement CSRF/nonce protection for endpoints that change state or create sessions.
• Log significant authentication events with sufficient context (without exposing secrets).
• Maintain a responsible disclosure process and a documented patch timeline.
• Provide hardening guidance to site owners and suggested mitigations for edge providers.

For hosts and agencies — operational recommendations

• Patch quickly and offer virtual patching or blocking at the edge if a widely used plugin is vulnerable.
• Offer site isolation and scanning services for affected customers.
• Block or rate-limit known malicious scanning and exploitation patterns at the edge.
• Notify customers with actionable steps and offer help to implement mitigations (deactivation, blocking, session resets).
• Maintain tested backup and recovery processes and offer incident response support to customers.

Timeline & references

• Report date: 15 October 2025
• CVE: CVE-2025-10294
• Research credited to: Jonas Benjamin Friedli

For the technical disclosure, see the official CVE entry and the researcher’s writeup. (Exploit code is not reproduced here to avoid enabling attackers.)

Frequently asked questions

Q — If I deactivate the plugin, will users lose access to their accounts?
A — Deactivating the plugin will disable the passwordless flow provided by that plugin. Users who rely on it will need to log in via standard username/password or other available authentication methods until a secure replacement or patched version is available.

Q — Is my site automatically compromised if I have the plugin installed?
A — Not automatically. Presence of the vulnerability means exploitation is possible — actual compromise depends on whether an attacker discovered and successfully exploited the flaw on your site. Assume risk and act accordingly.

Q — When will an official patch be available?
A — At the time of disclosure there may not be an official fixed release. Follow the plugin’s official channel for updates and apply the patch immediately when released. In the meantime, apply the mitigations described above.

Final words — prioritise containment and verification

This authentication bypass is high-impact because it requires no prior credentials. If your site uses OwnID Passwordless Login (≤ 1.3.4), act now: deactivate or block the plugin, apply edge/WAF mitigations, and inspect logs for signs of compromise. For operators managing many sites, automate detection and mitigation steps to reduce manual triage time and to protect customers before an official patch is available.

If you need help assessing a site or responding to a suspected compromise, engage an experienced incident response team or a trusted security consultant.