Privilege escalation in Magic Login Mail / QR Code plugin (<= 2.05): what happened, why it’s dangerous, and how to protect your WordPress sites

Published: 15 Feb, 2026  |  CVE: CVE-2026-2144 — Severity: High (CVSS 8.1)  |  Author: Hong Kong Security Expert

सारांश

• A high-severity vulnerability was disclosed in the WordPress plugin “Magic Login Mail or QR Code” (versions <= 2.05).
• Classification: Unauthenticated Privilege Escalation via insecure QR code file storage.
• Impact: An unauthenticated attacker can obtain or reuse QR code-based login artifacts stored in web-accessible locations, enabling impersonation or privilege escalation and potentially full site compromise.
• No official fixed version was available at publication time. This article explains the issue at a high level, lists safe immediate mitigations, and gives longer-term guidance for developers and site owners.

सामग्री की तालिका

• समस्या क्या है?
• Why is this vulnerability serious?
• Typical attack flow (high level)
• What to look for: detection and indicators of compromise
• Immediate mitigations you can apply (step-by-step, safe)
• Hardening recommendations for site owners and hosting providers
• Secure design guidance for plugin developers
• Example server rules to protect QR files (Apache/Nginx)
• How managed WAFs and virtual patching can help (generic)
• Prioritized checklist — what to do now
• समापन नोट्स

समस्या क्या है?

The plugin provides “magic login” functionality — sending login links and/or QR codes that allow users to log in without a password. To generate QR codes the plugin creates an artifact (file) representing the one-time login link or token. The vulnerability stems from those files being stored in a web-accessible location with predictable names and without sufficient access controls or lifecycle enforcement.

In short: an attacker who discovers or guesses the URL to a stored QR image (or other artifact) can extract the embedded magic login link or token and use it to authenticate as the intended user. If that user has elevated privileges (author, editor, administrator), the attacker can escalate from unauthenticated to high privileges and potentially take full control of the site.

This is an identification/authentication failure: the system depends solely on the secrecy of a file in the public webroot and lacks access controls, proper token lifecycle management, and unpredictable non-enumerable storage.

Why is this vulnerability serious?

• अनधिकृत: no prior login or privileges are required to attempt exploitation.
• विशेषाधिकार वृद्धि: magic login tokens map to user accounts; exposure of a token for a high-privilege user yields their capabilities to an attacker.
• Low friction for attackers: public uploads directories with predictable filenames are trivial to scan and automate.
• No vendor fix at disclosure: site owners must mitigate until an official patch is available.
• Chain risk: compromised accounts can be used to install backdoors, create admin users, exfiltrate data, or pivot to other systems.

CVSS 3.1 score of 8.1 reflects network accessibility, no required privileges, and high impact on confidentiality, integrity, and availability.

Typical attack flow (high level, non-exploitative)

Outlined steps an attacker might take — kept high-level so defenders can respond without exposing exploit details:

1. पहचान: identify target WordPress site and enumerate installed plugins via public pages, known plugin URLs, or automated fingerprinting. Confirm presence of the Magic Login plugin.
2. Artifact discovery: enumerate common upload paths (e.g., /wp-content/uploads/magic-login/, /wp-content/uploads/magic_login/, or directories with “qr”/“magic”) looking for QR images or predictable filenames.
3. Extract and reuse: extract the embedded login URL or token from the QR image/filename and use it to authenticate as the target user.
4. Post-compromise: for high-privilege accounts, attacker may install malicious plugins/themes, create admin users, exfiltrate data, or persist via backdoors or scheduled tasks.

The attack is easy to automate and can be executed en masse, giving it strong worm-like potential when used at scale.

What to look for: detection and indicators of compromise (IoCs)

Scan your site for these signs immediately:

1. Plugin and file artifacts: look for directories under uploads containing QR images or magic login artifacts. Common locations include:
   • /wp-content/uploads/magic-login/
   • /wp-content/uploads/magic_login/
   • /wp-content/uploads/*qr* or /wp-content/uploads/*magic*

   File types: .png, .svg, .jpg. Inspect filenames for embedded tokens or predictable patterns.

2. Server logs — suspicious GET requests: many GETs to upload paths from unknown IPs, especially sequential filename access patterns or frequent requests for static images that look like token harvesting.
3. Authentication logs: unusual logins by users who normally don’t access the site at those times, or logins via one-time link endpoints.
4. User & capability changes: newly created admin accounts, privilege escalations, or unexpected email changes on admin accounts.
5. Unexpected files or backdoors: new PHP files in uploads, modified plugin/theme files, or scheduled jobs. Look for base64-encoded or obfuscated payloads.
6. Outgoing connections: unexpected connections from the web server to unknown IPs or domains (possible command-and-control traffic).

If any of these are present, follow incident response procedures immediately (see Immediate mitigations).

Immediate mitigations you can apply (safe, prioritized)

Apply these in order — start with the highest-impact, lowest-risk steps.

1. प्लगइन को निष्क्रिय करें: the simplest and safest action is to deactivate the Magic Login plugin on production sites. This prevents new QR artifacts from being created and stops further abuse.
2. Block direct web access to the QR files directory: if deactivation is not possible for business reasons, block direct access to the directory where the plugin stores QR artifacts using server rules (examples below). This prevents external retrieval while leaving the plugin code installed.
3. Rotate/expire outstanding tokens and remove stored artifacts: delete the stored files from uploads, or move them to a non-web-accessible location. If the plugin provides revocation controls, use them. If not, rotate authentication factors as described below.
4. Force password resets for privileged users and rotate WP salts/keys: require admin users to reset passwords. Rotate authentication salts/keys in wp-config.php (AUTH_KEY, SECURE_AUTH_KEY, etc.) — note this invalidates sessions and requires coordinated reauthentication.
5. Audit users and authentication logs: remove unknown users, demote suspicious accounts, and review recent login timestamps and IPs for admin users.
6. Tighten file and directory permissions: ensure uploads/ and plugin directories are owned by the web server user and permissions are restrictive (e.g., 755 for directories, 644 for files). Avoid world-writable settings.
7. Full website scan and forensic snapshot: run malware scanners, take file/database snapshots for later analysis, and preserve logs for investigation.
8. If compromise is suspected — isolate and recover: take the site offline or isolate it, restore from a known-clean backup, and apply the steps above.
9. लॉगिंग और निगरानी: enable or enhance access logging, watch for repeated GETs to upload paths, and monitor for suspicious activity.

Notes: deleting files alone is insufficient if an attacker already used a token to gain admin access — you must verify accounts, logs, and audit for persistence.

Hardening recommendations for site owners and hosting providers

Short-term hardening you can implement site-wide:

• Enforce least privilege on user roles — limit admin accounts and use them sparingly.
• Disable or limit plugins that store authentication tokens in public locations.
• Implement generic WAF rules or server-side protections to block automated scanning and token enumeration patterns.
• Require MFA for all privileged accounts to reduce impact if tokens are exposed.
• Keep PHP, WordPress core, and plugins/themes updated; remove unused components.
• Maintain regular, tested backups stored offline and offsite.

Hosting provider recommendations

• Implement host-level access controls to restrict direct file serving for private artifacts.
• Offer private storage (outside webroot) for sensitive generated files.
• Provide tenant-level role-based access and activity logging for administrators.

Secure design guidance for plugin developers (don’t be the next headline)

This vulnerability is an example of insecure design: storing authentication secrets in web-accessible locations and relying on obscurity. If you develop “magic link” or QR login features, follow these design rules:

1. Never expose authentication tokens in public filenames or static files: avoid embedding raw tokens in filenames or QR payloads. If an image is required, include only a server-side identifier that requires validation.
2. Store tokens securely: use server-side storage (database) with strong randomness, associated metadata (expiry, user id, usage count, IP restrictions), and store hashed tokens where appropriate.
3. Enforce token lifecycle controls: short expiry windows (minutes), single-use tokens, and rate limiting on validation attempts.
4. Require capability checks for privilege-changing operations: always verify request origin and token validity before changing roles or capabilities; use WordPress capability checks (current_user_can) properly.
5. Make artifacts non-enumerable and out of webroot: render images on-demand behind authenticated endpoints or store artifacts outside the webroot and serve via controlled scripts that enforce authorization.
6. लॉगिंग और अलर्टिंग: log token issuance, validation attempts, failed validations, and reuse attempts; alert site owners on suspicious activity.
7. Input validation & sanitization: validate parameters used to look up token files or DB rows; do not map user input directly to file paths.
8. Security by default: default settings should be safe — require an explicit admin decision to enable any risky behaviour and provide controls to purge outstanding tokens.

Example server rules to protect QR files

If the plugin stores files under a subdirectory of uploads and you cannot deactivate it immediately, add restrictive server rules. These examples block public access to a directory named magic-login-qr (adjust to your path).

Apache (.htaccess placed in the directory that holds QR image files — e.g., /wp-content/uploads/magic-login-qr/.htaccess)

# Block all HTTP access to this directory
Require all denied

# If you need the PHP process to read files but block external HTTP access, place in parent directory:
<FilesMatch "\.(png|jpg|jpeg|svg)$">
  Require all denied
</FilesMatch>

Nginx (add to site configuration)

location ~* /wp-content/uploads/magic-login-qr/ {
    deny all;
    return 404;
}

Important: deny rules will stop legitimate magic-login functionality; treat these as temporary mitigations and coordinate with stakeholders before applying.

How managed WAFs and virtual patching can help (generic)

A managed Web Application Firewall (WAF) can provide layered protection while you implement permanent fixes:

• वर्चुअल पैचिंग: WAF rules can block requests matching exploitation patterns (enumeration attempts, repeated GETs to QR file paths, known token formats).
• दर सीमित करना और बॉट शमन: reduce the effectiveness of mass scanning and slow attackers.
• Attack signature detection: detect automated exploitation tools and block suspicious IPs or patterns.
• Centralized rules: for administrators managing many sites, a centralized WAF can apply mitigations across multiple installations quickly.

Note: WAFs are a stopgap and not a substitute for fixing the root cause in plugin code. Use them only to buy time while a secure patch is produced.

A short note about responsible disclosure

Vulnerabilities should be reported privately to the plugin author with reasonable time for a fix before public release. Site owners must monitor vendor advisories and apply official patches as soon as they become available. Given the severity of this issue, a public advisory may be warranted to protect sites from rapid exploitation.

Secure recovery checklist — prioritized (what to do now)

1. Deactivate the Magic Login Mail/QR plugin on all production sites. (High priority)
2. Block access to plugin upload directories via webserver rules if deactivation is not possible. (Quick mitigation)
3. Remove or move all QR artifacts from public uploads directories. (Mitigates exposed tokens)
4. Force password resets for all privileged users and rotate wp-config salts. (Mitigates stolen sessions/tokens)
5. Audit users & login logs; remove unknown admin accounts. (Detect compromise)
6. Scan site for backdoors and suspicious files; restore from clean backup if compromise is detected. (Recovery)
7. Apply WAF rules to block enumeration and token abuse patterns where possible. (Prevent scanning)
8. Monitor logs and re-scan after one week. (Ensure remediation)

Closing notes — long term thinking and next steps

This vulnerability highlights a common mistake: authentication mechanisms that rely on “secrecy by storage location” are fragile. Magic link and QR workflows can be convenient but must be engineered with token lifecycle, storage, and access controls in mind.

For site owners, the three most impactful actions today are:

1. Remove or block public access to any stored authentication artifacts.
2. Force resets of high-privilege accounts and rotate auth keys/salts.
3. Apply server-level protections and WAF rules to buy time until a permanent plugin fix is available.

If you operate multiple WordPress sites, automate scanning for the vulnerable plugin and the presence of QR artifacts in uploads directories. If you develop authentication plugins — never store sensitive tokens in web-accessible files; store server-side, validate via authenticated endpoints, expire tokens quickly, and log token events.

We are monitoring this disclosure closely. If you need assistance assessing exposure across several sites, crafting temporary server rules, or hardening your infrastructure, contact your security team, hosting provider, or a trusted local security consultant for support.

Appendix: quick commands and searches (defensive)

Use these for initial reconnaissance on your own installations.

# Find likely QR files
find /path/to/wordpress/wp-content/uploads -type f \( -iname "*magic*.png" -o -iname "*qr*.png" -o -iname "*magic*.jpg" -o -iname "*qr*.svg" \)

# Search webserver logs for access to upload paths (Apache / Nginx example)
grep -E "/wp-content/uploads/.{0,50}(magic|qr|login)" /var/log/nginx/access.log | awk '{print $1,$4,$7,$9}' | sort | uniq -c | sort -nr | head

# Check for new admin users via WP-CLI
wp user list --role=administrator --fields=ID,user_login,user_email,display_name,user_registered

Rotate salts in wp-config.php by generating new keys at https://api.wordpress.org/secret-key/1.1/salt/ — this will invalidate active sessions and force reauthentication.

Stay vigilant. Prioritise privileged account protection and take immediate action.

— हांगकांग सुरक्षा विशेषज्ञ