Имя плагина	OwnID Passwordless Login
Type of Vulnerability	Authentication bypass
CVE Number	CVE-2025-10294
Срочность	Критический
CVE Publish Date	2025-10-15
Source URL	CVE-2025-10294

Urgent: OwnID Passwordless Login (<= 1.3.4) — Authentication Bypass (CVE-2025-10294)

WP‑Firewall security advisory and mitigation guide

Опубликовано: 15 October 2025
Серьезность: High (CVSS 9.8) — unauthenticated authentication bypass
Затронутые версии: OwnID Passwordless Login plugin <= 1.3.4
Fix status: No official vendor patch available at time of advisory

This advisory comes from the WP‑Firewall security team. If your site uses the OwnID Passwordless Login plugin, treat this as an emergency. The vulnerability allows unauthenticated attackers to bypass authentication and impersonate users (including potentially administrators). Because the plugin changes the core authentication flow, the impact is far greater than a typical plugin bug: an attacker who successfully exploits this can gain persistent administrative control, install malicious code, modify pages, create backdoor accounts, and steal data.

Below you’ll find a clear, technical but practical breakdown — what the flaw is in plain terms, how attackers are likely to exploit it, detection tips, immediate containment steps, recommended virtual‑patch / WAF rules you can apply right now, and recovery/hardening guidance.

This is written from the perspective of real WordPress security practitioners — no fluff, just actionable next steps.

---

Executive summary (short)

• CVE-2025-10294: an authentication bypass in OwnID Passwordless Login (versions <= 1.3.4).
• Exploitable by unauthenticated attackers — no login required.
• Consequences: attacker can impersonate users (including admins), take over sites, install malware, and persist.
• No official patch available at time of writing — immediate mitigations required.
• Recommended actions: disable the plugin or block its endpoints, implement WAF rules/virtual patching, rotate salts and secrets, audit user accounts and uploads, and restore from clean backup if you see evidence of compromise.

---

What is the issue (technical, simplified)

Passwordless login plugins integrate additional authentication flows (magic links, WebAuthn, REST callbacks, challenge/response). A robust passwordless implementation requires strict validation of challenge responses, unforgeable signatures, proper session establishment, and never setting authenticated cookies without full verification.

The reported vulnerability is a logic/validation failure in the OwnID plugin’s authentication flow. In affected versions, certain plugin endpoints or callback handlers do not properly verify the authentication proof before establishing a WordPress session. That means an attacker can craft requests that the plugin accepts as legitimate authentication responses, causing WordPress to treat the attacker as the targeted user — all without knowing that user’s password or owning a valid session.

Key attributes:

• Attacker privilege: unauthenticated (no prior access required).
• Attack vector: web requests to plugin endpoints or AJAX/REST callback handlers used by OwnID.
• Impact: full account impersonation, potential admin takeover, site compromise.

Because this bypass occurs before WordPress’s normal credential checks, it sidesteps many traditional controls like password policies, and can be automated at scale.

---

How attackers are likely to exploit this

Adversaries will follow straightforward steps:

1. Discover sites with the vulnerable plugin (automated scanners search for known REST endpoint patterns, plugin assets, or identified headers).
2. Probe the plugin endpoints (REST / AJAX / callback URLs) for the vulnerable behavior.
3. Send crafted requests that trigger the flawed verification logic and cause the plugin to create or accept an authentication token/cookie for a target user (often targeting admin users).
4. Escalate from there: create new admin users, upload backdoors, modify posts, and extract sensitive data.

Exploitation is easy to automate. A widespread scanning and exploit run could lead to mass compromises in hours once exploit code is public.

---

Immediate risk to your site

If you run OwnID Passwordless Login (<= 1.3.4) on any public-facing WordPress installation you should assume:

• Your site is at high risk of automated exploitation.
• Any admin-level accounts are targets for impersonation.
• If you do not take immediate containment steps, automated attackers will attempt compromise and install persistent malware/backdoors.

Do not wait for an official plugin update before acting.

---

Detection — signs your site may already be compromised

Check the following indicators of compromise (IOC) and logs immediately:

• New administrator accounts in the wp_users / wp_usermeta tables. Query:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
  SELECT user_id
  FROM wp_usermeta
  WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%'
)
ORDER BY user_registered DESC;

• Failed/suspicious login artifacts in your webserver logs: repeated POSTs to plugin REST endpoints or odd query strings directed at ownid-related paths (e.g., URLs containing “ownid”, “passwordless”, “magic-link”, or similar).
• Unusual authorization cookie creation events or session cookies being set after requests to plugin endpoints.
• Unexpected modifications to wp_options, wp_posts, or plugin files (file modification timestamps that you don’t recognize).
• Presence of suspicious files in uploads or wp-content, especially PHP files in the uploads folder.
• Outbound connections from your server to unknown domains from PHP processes.
• Scheduled cron jobs (wp_options cron entries) you did not create.

If you see any of these, treat the site as potentially compromised and follow the containment steps below.

---

Immediate containment steps (what to do right now — prioritized)

1. Disable the plugin immediately.
   – If you can access WP Admin: deactivate OwnID Passwordless Login from the Plugins screen.
   – If WP Admin is not reachable: rename the plugin folder via SFTP/SSH (e.g., rename wp-content/plugins/ownid к ownid.disabled).
   This prevents the vulnerable code from executing.
2. Block plugin endpoints at the web server / WAF level.
   If you cannot or will not disable the plugin immediately (for availability reasons), block all requests to the plugin’s REST/AJAX endpoints. Example rules are provided in the next section.
3. Rotate authentication salts / keys to invalidate sessions.
   Edit wp-config.php and generate new AUTH_KEY / SECURE_AUTH_KEY / LOGGED_IN_KEY / NONCE_KEY values (use the WordPress.org secret-key service). Changing these will invalidate existing authentication cookies and force re-authentication for all users.
4. Force password reset and rotate critical credentials.
   – Reset passwords for all administrator accounts.
   – Rotate API keys stored on the server (e.g., third-party services, payment gateways).
   – Revoke any OAuth tokens stored within plugins.
5. Inspect user accounts and remove unknown admins.
   Carefully audit user roles and delete unauthorized users. If you remove an account, check for artifacts left by that account.
6. Scan for malware and backdoors.
   Use a file integrity scanner to identify modified core/plugin/theme files and PHP files in uploads. WP‑Firewall’s malware scanner can identify known signatures and suspicious files.
7. Take a forensic snapshot.
   Before making invasive changes (if possible), snapshot the filesystem and database for later forensic analysis. If you must act quickly, prioritize containment and recovery.
8. If you detect compromise — restore from a clean backup.
   If you find backdoors or unauthorized code, the safest route is to restore the site to a clean backup made before the compromise. After restoration, apply the containment steps (disable plugin, block endpoints, rotate salts).
9. Alert hosting provider and increase logging.
   Turn on verbose access logging and monitoring. If you are on a managed host, notify them — they can block attacker IPs or assist with cleanup.

---

Recommended WAF / virtual patch rules (apply now)

If you have a Web Application Firewall (WAF) or can add server-level rules, virtual patching is the fastest way to reduce risk before an official plugin update is released. Below are suggested rule patterns. Adjust to your environment and test on staging first.

Important: the exact endpoints and parameter names may vary by plugin version. The goal is to deny unauthenticated access to plugin-specific REST or AJAX endpoints that perform authentication.

Example Nginx rule to block likely plugin REST namespace:

# Deny requests to the OwnID REST namespace
location ~* ^/wp-json/(ownid|ownid-.*) {
    return 403;
}

Example Apache/.htaccess rule:

# Block OwnID REST endpoints
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/wp-json/(ownid|ownid-.*) [NC]
  RewriteRule .* - [F]
</IfModule>

Example ModSecurity (SecRule) snippet:

SecRule REQUEST_URI "@rx ^/wp-json/(ownid|ownid-.*)" 
    "id:1009001,phase:1,deny,status:403,log,msg:'Block OwnID REST endpoints (virtual patch) - authentication bypass mitigation'"

Block known AJAX actions (if plugin uses admin-ajax.php action parameters):

# Example: block admin-ajax requests that contain ownid actions
if ($request_method = POST) {
    set $block_ajax 0;
    if ($request_uri ~* "admin-ajax.php") {
        if ($request_body ~* "(action=.*ownid|ownid_auth|ownid_callback)") {
            set $block_ajax 1;
        }
    }
    if ($block_ajax = 1) {
        return 403;
    }
}

Other protective measures to implement in WAF:

• Rate-limit requests to plugin-specific endpoints and admin login paths.
• Block requests with missing or invalid Nonce headers where applicable.
• Block POST requests to plugin endpoints from remote IPs unless they match your known service IP ranges.
• Deny requests with suspicious payloads (blank tokens, oversized parameters, or parameter values that match known exploit patterns).
• Monitor and alert on spikes in requests to any ownid/ passwordless paths.

If you are using WP‑Firewall, enable the managed ruleset / virtual patching feature to automatically protect vulnerable endpoints until an official vendor patch is available. (If you’re not currently using WP‑Firewall, see the free plan option below for rapid deployment.)

---

Practical server-level countermeasures (quick rules you can add now)

If you cannot deploy WAF rules, apply these server-level locks:

• Restrict access to wp-login.php and /wp-admin by IP (if admin access is limited to static IPs).
• Add a webserver rule to deny requests containing strings related to the plugin’s REST namespace (ownid, passwordless etc.).
• Reduce exposure: temporarily disable REST API for unauthenticated users using a lightweight plugin or a small mu-plugin that denies access to endpoints from unauthenticated requests, but be careful to avoid breaking legitimate API consumers.

A small mu-plugin example to block common ownid REST calls:

<?php
// mu-plugin/block-ownid-rest.php
add_filter( 'rest_request_dispatch', function($result, $server, $request) {
    $route = $request->get_route();
    if (preg_match('#^/ownid#', $route) || preg_match('#ownid#', $route)) {
        return new WP_Error('rest_forbidden', 'Forbidden', ['status' => 403]);
    }
    return $result;
}, 10, 3);

Note: test thoroughly before deploying; this mu-plugin is a temporary stop-gap. Remove it once the plugin is patched and you have validated behavior in staging.

---

How to validate your site is clean (post-containment)

After containment (plugin disable and WAF rules), run these checks:

1. Search for unknown admin accounts and remove them.
2. Confirm wp-config.php has updated salts — this invalidates old sessions.
3. Scan file system for recently changed files after the time of suspected compromise:
   find . -type f -mtime -n (adjust n to the timeframe).
4. Look for PHP files in uploads:
   find wp-content/uploads -type f -name "*.php"
5. Check for unexpected scheduled tasks:
   In WP Admin or examine wp_options['cron'].
6. Inspect database for suspicious options or rogue widget/content that could provide backdoors.
7. Check webserver logs for persistent POSTs or unusual user agents.
8. Re-scan with a trusted malware scanner and a file integrity tool.

If you find evidence of malware/backdoors, consider restoring from a clean backup — not just removing files — and then re-apply containment and rotate secrets.

---

Recovery steps and long-term hardening

• Restore from a clean backup if compromise is confirmed.
• After restoring, immediately disable the vulnerable plugin and apply WAF rules described above.
• Rotate all credentials (admin passwords, service credentials, API keys) and generate new auth salts (wp-config.php).
• Deploy two-factor authentication (2FA) for all admin accounts.
• Enforce strong admin user policies: limited number of admin accounts, use of least privilege.
• Enable file change monitoring and regular malware scans.
• Use automated backups stored offsite and verify backup integrity.
• Monitor for reappearance of suspicious users/files for at least 30 days.

---

Developer guidance (for plugin/theme authors and integrators)

If you maintain code that integrates with passwordless authentication libraries or you develop plugins:

• Always validate the authenticity of any authentication proof server-side; do not trust client-side assertions.
• Validate digital signatures, nonces, CSRF tokens, and timestamps firmly.
• Ensure that success states only occur after cryptographic verification and that no code path sets authentication cookies based on uncontrolled inputs.
• Minimize the number of custom endpoints that can set authentication state; re-use WordPress core login flows where possible.
• Add comprehensive logging for authentication flows and rate-limit endpoints that can be abused.

---

Indicators of compromise checklist (quick scan)

• Unexpected admin-level users created within the last 30 days.
• Recent modification timestamps on active theme/plugin files without your knowledge.
• PHP files in wp-content/uploads or other non-code directories.
• Outbound network connections originating from PHP processes to unknown hosts.
• New scheduled cron jobs you did not configure.
• Sudden spikes in requests to REST API endpoints matching ownid-related paths.

If any of these appear, escalate to incident response.

---

Offer from WP‑Firewall — Protect now with a free plan

Protect Your Site Now — Try WP‑Firewall Free Plan

If you need a fast way to protect WordPress sites before vendor patches are available, WP‑Firewall offers a Basic (Free) plan that provides essential protection you can enable within minutes:

• Essential protection: managed firewall, unlimited bandwidth, Web Application Firewall (WAF), malware scanner, and mitigation of OWASP Top 10 risks.
• Deploy rules to block plugin REST endpoints and apply virtual patches immediately — no code changes required.
• If you need more: Standard and Pro tiers include automatic malware removal, IP blacklist/whitelist controls, virtual patching, monthly security reports, and premium managed services.

Sign up for the free plan and get baseline protection quickly: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Final recommendations — prioritized checklist

1. If OwnID Passwordless Login is installed: disable or remove it immediately.
2. If you cannot disable it: block its REST/AJAX endpoints via WAF or webserver rules.
3. Rotate WordPress keys/salts in wp-config.php to invalidate sessions.
4. Force password resets for administrators and rotate critical credentials.
5. Audit users, plugins, themes, and core files for signs of tampering.
6. Scan and, if necessary, restore from a known‑clean backup.
7. Deploy WAF rules/virtual patches and enable continuous malware scanning.
8. Harden the site: 2FA for admin users, limited admin accounts, routine backups, monitoring.

---

Closing thoughts

Authentication bypass vulnerabilities in plugins that rework the login flow are among the highest-risk issues for WordPress sites. They turn the very gatekeepers of access into an attack surface. The pace of automated exploitation means site owners must act swiftly — plugin deactivation and virtual patching are valid and necessary emergency responses until the plugin author releases a verified fix.

If you manage multiple sites, prioritize high‑traffic and eCommerce properties first — attackers will go where there’s the most reward. When in doubt, assume compromise and follow containment, cleanup, and recovery best practices.

If you’d like WP‑Firewall to scan your site, deploy virtual patches, and keep you protected while vendors build official fixes, visit our free plan to get started: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Stay safe, and if you need help implementing any of the containment steps above, WP‑Firewall’s support team can assist with rule deployment and incident response.