Critical Backdoor in LA‑Studio Element Kit for Elementor (CVE‑2026‑0920) — What WordPress Site Owners Must Do Now

Updated: 21 Jan 2026
CVE: CVE‑2026‑0920 — Plugin versions <= 1.5.6.3 are vulnerable; fixed in 1.6.0.
Severity: CVSS 9.8 (High). Attack vector: Unauthenticated. Classification: Backdoor / Privilege Escalation.

From a Hong Kong security expert perspective: this is an urgent, high‑risk disclosure that demands immediate, practical action. Follow the steps below carefully and prioritise containment first if you host affected sites in production.

TL;DR

• A backdoor was discovered in LA‑Studio Element Kit for Elementor (versions ≤ 1.5.6.3). It allows unauthenticated attackers to create administrative users via a hidden parameter (reported as lakit_bkrole), enabling full site takeover.
• If this plugin is installed on any WordPress site you operate: verify the version immediately and update to 1.6.0 or later.
• If you cannot update instantly: deactivate or remove the plugin, and apply immediate blocking rules at the webserver/WAF level to stop requests that attempt to exploit the hidden entry point.
• Scan for new administrators, suspicious users, unexpected files, and other indicators of compromise (IoCs). Treat any positive finding as a potential compromise and follow incident response procedures.

Why this is so urgent

• Backdoors permit persistent, stealthy access — attackers can return after initial exploitation.
• This backdoor is exploitable without authentication; any remote actor can trigger it.
• It allows creation of administrative accounts, granting full site control.
• Because of these properties the impact on confidentiality, integrity and availability is high (CVSS 9.8).
• Public disclosure means mass scanning and exploitation attempts will follow quickly; rapid action is essential.

What we know about the vulnerability (summary)

• Affected software: LA‑Studio Element Kit for Elementor (WordPress plugin)
• Vulnerable versions: any release at or below 1.5.6.3
• Fixed in: 1.6.0
• Vulnerability type: backdoor leading to unauthenticated privilege escalation (administrative user creation)
• Vector: undocumented entry point accepting a parameter identified in reporting as lakit_bkrole which can trigger admin user creation
• Discovery: reported by security researchers and publicly disclosed on 21 Jan 2026
• CVE: CVE‑2026‑0920
• CVSS v3.1 base score: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Note: attack payloads are not reproduced here. The goal is to help defenders detect and remediate quickly.

How the attack works (high level — defender focused)

Reports indicate the plugin exposes an entry point that accepts remote input (reported parameter lakit_bkrole) and processes it in a way that can create or elevate a user to administrative privileges without authentication. An attacker can craft an HTTP request to that endpoint and receive a privileged account on the target site.

Possible attacker actions after admin creation:

• Install persistent backdoors and webshells
• Deploy malware, create cron jobs, or modify site content
• Exfiltrate databases, user data and credentials
• Hijack email, payment or business workflows
• Use the site as a pivot to other infrastructure

Real attack scenarios

• Mass compromise: attackers scan the internet and create admin accounts across many sites.
• Targeted takeover: attacker targets high‑value sites, gains admin access and performs deeper lateral movement.
• Supply chain abuse: stolen credentials or API keys are abused beyond the site itself.

Am I vulnerable? Immediate checks

1. Plugin version

   Check WordPress Admin → Plugins for “LA‑Studio Element Kit for Elementor”. If version ≤ 1.5.6.3, you are vulnerable.

   WP‑CLI example:

   wp plugin list --format=table | grep lastudio-element-kit

2. New or unexpected administrator accounts

   Inspect All Users in WP Admin for unfamiliar admin accounts.

   WP‑CLI:

   wp user list --role=administrator --fields=ID,user_login,user_email,display_name,registered

3. Suspicious users and roles

   Look for non‑standard roles or modified capabilities.

   wp eval 'print_r(get_editable_roles());'

4. File modifications and suspicious files

   Search for modified plugin files and unexpected PHP files in uploads or plugin directories.

   find /path/to/wp-content -type f -mtime -30 -name '*.php' -ls
   grep -R --line-number "lakit_bkrole" wp-content/plugins/lastudio-element-kit

5. Logs and access patterns

   Check webserver logs for unusual POST/GET requests to plugin endpoints, particularly requests containing unusual parameters.

6. Database check

   Query the users table for recent entries:

   SELECT ID,user_login,user_email,user_registered FROM wp_users WHERE user_registered > '2026-01-01' ORDER BY user_registered DESC;

If any checks show suspicious results — treat the site as potentially compromised and follow containment and investigation procedures.

Immediate mitigation steps (first 60 minutes)

1. Update the plugin to 1.6.0 or later immediately

   This is the definitive fix. If you can update safely, do so now.

2. If update is not possible right away
   • Deactivate the plugin: WP Admin → Plugins → Deactivate, or:

   wp plugin deactivate lastudio-element-kit

   • If deactivation fails, rename the plugin folder to disable it (preserve files for investigation):

   mv wp-content/plugins/lastudio-element-kit wp-content/plugins/lastudio-element-kit.bak

3. Apply virtual patching / blocking rules

   If you control a web application firewall (WAF), hosting firewall, or webserver ruleset, create a rule to block requests that attempt to invoke the plugin endpoint with the suspicious parameter (e.g., lakit_bkrole). This buys time while you update and investigate.

4. Lock down access

   Temporarily restrict admin area access by IP or block suspicious IP ranges if you see scanning activity. Use .htaccess or host controls as appropriate.

5. Rotate credentials

   Change administrative passwords (WordPress, database, hosting panel, FTP/SSH) and revoke API keys and tokens. Reissue credentials only after the site is confirmed clean.

6. Check for persistence

   Search for backdoors (uploads, mu‑plugins, cron tasks), edits to wp-config.php, and other persistence mechanisms.

7. Snapshot and preserve

   Take a full backup (files + database) and preserve logs before making further changes for forensic analysis.

How to clean and recover (if compromise is confirmed)

1. Isolate and preserve

   Take the site offline or place it in maintenance mode. Preserve logs, backups and suspicious files.

2. Identify scope

   Inventory malicious artifacts, newly added admin accounts and timeline of events. Determine potential data exfiltration.

3. Remove backdoors

   Replace modified core, plugin and theme files with clean copies from official sources. Remove suspicious files in uploads and writable directories.

4. Clean database

   Remove unauthorized administrator accounts and suspicious user meta. Check wp_options for malicious autoloaded entries and cron hooks.

5. Harden and restore

   Reinstall the plugin with the fixed version (1.6.0 or later) or remove the plugin entirely if you do not trust it. Reset passwords and rotate credentials. Update all WordPress core, themes and plugins.

6. Post‑recovery monitoring

   Enable enhanced logging and file integrity monitoring. Monitor outbound connections for suspicious activity.

If recovery exceeds your team’s capability, engage a professional incident response provider experienced with WordPress forensics.

Detection & Indicators of Compromise (IoCs)

• Newly created administrator accounts around 21 Jan 2026 or later.
• Unusual HTTP requests to plugin endpoints containing parameters like lakit_bkrole.
• Unexpected PHP files under:
  • wp-content/uploads/
  • wp-content/plugins/lastudio-element-kit/
  • wp-content/mu-plugins/
• Abnormal scheduled events (wp‑cron) or mu‑plugins that persist after plugin removal.
• Unexplained changes to wp_options (malicious autoloaded entries).
• Outbound connections to suspicious IPs/domains from the webserver.

Preserve copies of suspicious files and logs for analysis and reporting.

WAF / Virtual patching guidance (technical)

If you manage your own WAF or webserver rules, apply conservative blocking and alerting measures. The aim is to reduce attack surface without disrupting legitimate admin use.

• Block requests where the path contains /wp-content/plugins/lastudio-element-kit/ and parameters include lakit_bkrole.
• Rate‑limit or block requests with unusual payload sizes or unknown user agents targeting the plugin path.
• Create alerts for any HTTP requests to the plugin path that are followed by user creation events or other backend changes.
• Tune signatures to reduce false positives — prioritise blocking on public-facing sites and monitoring in staging environments.

Example conceptual pseudo-rule:

IF request_path CONTAINS '/wp-content/plugins/lastudio-element-kit/' AND request_params CONTAIN 'lakit_bkrole' THEN block & log

Hardening recommendations (beyond patching)

• Principle of least privilege: only grant admin role to accounts that truly need it.
• Multi‑factor authentication: enforce MFA for all admin accounts.
• Regular backups: daily off‑site backups with versioning and restore tests.
• File integrity monitoring: alert on unexpected changes in wp-content, wp-config.php and other critical files.
• Security headers & HTTPS: ensure TLS is current and implement HSTS, CSP where appropriate.
• Disable file editing: in wp-config.php:

  define('DISALLOW_FILE_EDIT', true);

• Restrict admin area access: use server/WAF controls to allow admin access only from known IP ranges if feasible.
• Vulnerability management: monitor updates and subscribe to reliable vulnerability feeds.
• Sandboxed testing: test plugin updates in staging before production deployment.

Incident response playbook (concise)

1. Detect: identify suspicious activity via logs, alerts or integrity monitoring.
2. Contain: deactivate the vulnerable plugin and block attack traffic.
3. Analyze: preserve logs/backups and scan for artifacts.
4. Eradicate: remove malicious files and accounts, then patch the vulnerability.
5. Recover: restore a clean site, verify functionality and rotate credentials.
6. Post‑incident: perform root cause analysis, adjust controls and document lessons learned.

Frequently asked questions

Q: I updated the plugin — do I still need to scan my site?

A: Yes. Updating prevents future exploitation but does not remove backdoors or accounts created prior to the update. Scan and audit for persistence.

Q: Can I rely solely on a WAF instead of updating?

A: A WAF can provide immediate protection (virtual patching) and buy time, but it is not a substitute for applying the code fix. Update the plugin as soon as feasible and use defence‑in‑depth.

Q: What if I find a suspicious admin account — should I delete it?

A: Export and preserve evidence first (user details, logs). Then disable the account (reset password, force logout). If confirmed malicious, remove it and check for other persistence.

Q: How do I check for hidden backdoors I can’t find?

A: Use multiple scanning tools, compare files with clean copies, review scheduled tasks and database hooks. Bring in a forensic specialist if uncertain.

Timeline (recommended immediate actions)

• 0–15 minutes: Confirm plugin version. If vulnerable, deactivate or apply blocking rules. Change critical passwords.
• 15–60 minutes: Scan for new admins and suspicious files. Snapshot server and preserve logs.
• 1–24 hours: Update plugin to 1.6.0 (or remove plugin if untrusted). Clean any discovered persistence.
• 24–72 hours: Continue monitoring, harden and rotate credentials. Conduct a full audit.
• Ongoing: Maintain vulnerability scanning, monitoring and regular backups.

Why virtual patching and WAF matter for incidents like this

Backdoors are often exploited quickly after disclosure. Virtual patching (blocking exploit attempts at the edge) provides a critical window to patch and investigate. It is a stopgap — not a replacement for applying the upstream code fix — but can prevent mass compromise while you perform remediation.

Example safe commands and checks (defensive only)

# List installed plugin & version
wp plugin list --format=csv | grep lastudio-element-kit

# Deactivate plugin
wp plugin deactivate lastudio-element-kit

# List administrators
wp user list --role=administrator --format=csv

# Search plugin folder for suspicious tokens (defensive)
grep -R --line-number "lakit_bkrole" wp-content/plugins/lastudio-element-kit || true

# Find recently modified PHP files
find wp-content -type f -name '*.php' -mtime -30 -ls

Final notes for site owners and managers

• Treat this disclosure as an emergency if you host the vulnerable plugin.
• Patch is the definitive fix — plugin developer released version 1.6.0 to remediate the issue.
• If you cannot update immediately, take the plugin offline and apply blocking rules at the webserver/WAF level until you can verify integrity.
• Regular audits, least privilege, MFA and reliable monitoring greatly reduce the blast radius from incidents like this.

Closing — recommended next steps

Act now: verify versions, contain exposed sites, preserve evidence, and update to the fixed plugin release. If you lack in‑house capability for forensic analysis or recovery, engage a reputable incident response team experienced in WordPress and web hosting environments.

From Hong Kong to global operators: rapid, disciplined response is the difference between a contained event and a site takeover. Prioritise containment, preserve evidence, then remediate and harden.