প্লাগইনের নাম	OwnID Passwordless Login
Type of Vulnerability	প্রমাণীকরণ বাইপাস
CVE Number	CVE-2025-10294
জরুরি অবস্থা	উচ্চ
CVE Publish Date	2025-10-15
Source URL	CVE-2025-10294

Critical authentication bypass in OwnID Passwordless Login (<= 1.3.4) — What WordPress site owners must do right now

লেখক: WP-Firewall Security Team
তারিখ: 2025-10-15
ট্যাগ: WordPress, security, WAF, vulnerability, authentication, incident response

---

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. But they also concentrate trust in a smaller number of moving parts: a callback endpoint, 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 admin-level 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 WP-Firewall (a WordPress firewall and security team) 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 (using WP-CLI)
     • Dashboard: Plugins → Installed Plugins → Deactivate
2. If you cannot deactivate immediately, restrict access to wp-admin to trusted IPs and enable strict rate-limits at the webserver/WAF layer.
3. Monitor logs for suspicious login activity or unexpected user creations (see Detection section below).
4. Implement short-term virtual patching with your WAF: block suspicious endpoints and anomalous parameter combinations associated with the passwordless flow (see WP-Firewall mitigations).
5. Rotate secrets 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.

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

---

Vulnerability overview

• Affected software: OwnID Passwordless Login plugin for WordPress
• ঝুঁকিপূর্ণ সংস্করণ: <= 1.3.4
• Vulnerability type: Broken Authentication (OWASP A7)
• CVE: CVE-2025-10294
• Reported by: Jonas Benjamin Friedli (research credit)
• Privilege required: অননুমোদিত
• স্থির সংস্করণ: N/A (at time of disclosure)

High-level description: The plugin’s authentication flow contains an implementation flaw that enables an attacker to bypass the intended authentication checks and obtain an authenticated session on a target site without valid credentials or consent. The exact 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. Avoid sharing 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 blacklisting by search engines.
• Lateral movement for hosts: 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 scan the web for vulnerable plugin signatures and systematically attempt login bypasses.

---

How to detect exploitation on your site

Immediate signals to check:

1. Unexpected admin users:
   • WP-CLI: wp user list --role=administrator
   • Dashboard: Users → All Users → filter by Administrator
   • Look for recently created admins or users with strange email addresses.
2. Recent successful logins for admin users from unfamiliar IP addresses:
   • Check your webserver access logs (nginx/apache) for POST requests to wp-login.php or to REST endpoints with 200/302 responses around suspicious timestamps.
   • If you have activity logging enabled (audit logs), check for admin logins outside business hours.
3. File changes and new files:
   • Search plugin/theme directories and wp-content for unexpected files.
   • Common indicators: files with names similar to system PHP files but with recent timestamps, files containing ইভাল/base64_decode/gzuncompress.
   • Sample find command (run from site root):
     find . -type f -mtime -14 -print
     (Lists files modified in the last 14 days.)
4. Database changes:
   • Check for modifications in wp_options (suspicious auto-load entries), new cron jobs (wp_options->cron), or unauthorized content changes.
   • Search for suspicious PHP in options:
     SELECT option_name, LENGTH(option_value) FROM wp_options WHERE option_name LIKE '%template%' OR option_name LIKE '%cron%';
5. Unusual outgoing traffic:
   • Check server firewall or network logs for connections to unknown IPs/domains originating from your webserver.
6. Login activity patterns specific to passwordless endpoints:
   • Review access logs for POST/GET requests to endpoints associated with the plugin or for suspicious parameters that match the passwordless flow.

Keep detailed copies of logs for investigation and possible forensic analysis.

---

Immediate mitigation options (site owners & admins)

If you run the vulnerable plugin, pick the fastest safe route:

1. Deactivate the plugin immediately
   • Most reliable short-term mitigation.
   • Use WP-CLI when you have many sites to manage:
     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 PHP files and endpoints producing the vulnerability.
   • Example (nginx, block by URI pattern):
     
location ~* /wp-content/plugins/ownid-passwordless-login/ {
    return 403;
}

   • Note: Be careful — blocking by path may break legitimate features. Prefer to deactivate when possible.
3. Use your WAF to implement virtual patching:
   • Block requests with suspicious parameter payloads to the plugin’s endpoints.
   • Enforce origin and referer checks for requests that establish sessions.
   • Add strict rate limits to throttle brute-force and automated scanning.
4. Rotate keys and invalidate sessions:
   • Force password resets for admin users:
     wp user update <admin-id> --user_pass='<new-strong-password>'
   • Invalidate sessions by asking users to log out and/or using plugins that destroy active sessions.
   • 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 (if possible).
   • Move login page or use an access-layer that requires a shared secret or HTTP Basic auth for wp-admin.
6. Keep backups:
   • Ensure you have a known-good backup taken before any suspected compromise. Do not overwrite backups with a compromised state.

---

WP-Firewall virtual patch recommendations (how a WAF can protect you now)

As a WordPress firewall vendor, we recommend the following layered WAF rules (generic, non-exploit-specific) to mitigate the risk until an upstream patch is available:

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 a valid Origin and Referer header for requests that create sessions, and reject requests with missing or clearly forged headers from untrusted clients.
   • Validate common headers such as 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 stops many lateral movement techniques even if an attacker manages to bypass the plugin.
6. Audit and alert:
   • Create WAF alerts on POST requests that result in successful authentication actions without a preceding challenge or a valid state value.
   • Forward alerts to site admins and hosting teams for immediate review.

Important: Do not rely solely on WAF rules as a long-term fix — they are a mitigation. The plugin must be updated or replaced with a secure implementation.

---

Detection signatures and logging suggestions for WAFs and hosts

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/ বা অ্যাডমিন-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 a copy of webserver logs, database dumps, and file system snapshots for forensic investigation. Do not modify these copies.
3. Rotate credentials and keys:
   • Change WordPress admin passwords and any API keys used by the site.
   • Rotate hosting and database passwords.
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 keywords: ইভাল, base64_decode, preg_replace with /e, create_function, gzinflate, system, exec, shell_exec.
   • Example command to find suspicious uses:
     grep -R --exclude-dir=uploads -nE "eval\(|base64_decode\(|gzinflate\(|shell_exec\(|system\(" .
6. Inspect database for unauthorized changes:
   • Users table (wp_users) for unknown accounts.
   • Options table for malicious autoloaded code.
   • Posts table for injected scripts.
7. Reinstall core, plugins, and themes from trusted sources:
   • Do not trust files on the compromised filesystem. Replace them by downloading fresh copies from WordPress.org or developer sites.
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 the recovery for signs of reinfection.
   • Consider a professional security audit if the site contains sensitive data.
10. Consider engaging professional incident response if you handle financial or personal data at scale.

---

Hardening WordPress authentication (long-term)

1. Avoid single points of failure: Passwordless flows are fine — but ensure they are implemented with signed tokens, nonce binding and strict validation.
2. Enforce multi-factor authentication for admin users.
3. Minimize admin accounts — use the least-privilege principle.
4. Keep plugins and themes updated and only install plugins from reputable sources.
5. Use a central monitoring and patching process for all sites you manage.
6. Enable logging and alerting for admin logins and unexpected file changes.
7. Harden file permissions and disable PHP execution in uploads where possible:

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

8. 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 state or nonce stored server-side and validated on callback.
• Validate redirect URIs and origins strictly.
• Always verify the issuer and signature for tokens coming from third-party providers.
• Avoid creating sessions or elevating privileges on simple GET requests.
• Implement CSRF/nonce protection for any endpoint that can change state or create sessions.
• Log significant authentication events with sufficient context (without exposing secrets).
• Create a responsible disclosure process and maintain a patch timeline.
• Provide hardening guidance to site owners and recommend WAF rules where appropriate.

---

For hosts and agencies — operational recommendations

• Patch quickly and provide on-demand virtual patching if a plugin used by many customers is vulnerable.
• Offer site isolation and scanning services for potentially 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 a tested backup and recovery process and offer incident response as a service.

---

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. (We do not reproduce exploit code 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 a standard username/password or other available authentication method until a secure replacement or patched version is available.

Q — Is my site automatically compromised if I have the plugin installed?
A — Not automatically. Vulnerability presence indicates possibility — actual compromise depends on whether an attacker discovered and successfully exploited the flaw on your site. You must 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.

---

Protect your WordPress sites — WP-Firewall Basic (Free) plan

Stronger Protection Without the Cost

If you manage WordPress sites, take advantage of the WP-Firewall Basic (Free) plan — designed to give essential, managed protection with zero commitment. The free plan includes our managed firewall, unlimited bandwidth, an active Web Application Firewall (WAF), a malware scanner, and protections that mitigate OWASP Top 10 risks. It’s an easy first step to reduce the window of risk from plugin vulnerabilities like this one.

Sign up for the free plan and get instant virtual mitigation rules applied to your site: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(If you need automatic malware removal, IP blacklist/whitelist controls, monthly security reports and vulnerability virtual patching, review our Standard and Pro plans for additional features and support.)

---

Final words — prioritize containment and verification

This authentication bypass is a high-impact vulnerability because it requires no prior credentials. If your site uses OwnID Passwordless Login (<=1.3.4), act now: deactivate or block the plugin, apply WAF mitigations, and inspect logs for signs of compromise. If you run many WordPress sites, automate the detection and mitigation steps with a managed firewall solution to reduce manual triage time and to protect customers before an official patch is released.

If you need help assessing a site or implementing virtual patching, WP-Firewall support is available to assist with rapid mitigation and recovery workflows.

নিরাপদে থাকো,
WP-ফায়ারওয়াল সিকিউরিটি টিম