Atacuri SQL injection pe WordPress: cum funcționează și cum te protejezi

Atacurile SQL injection reprezintă una dintre cele mai vechi și mai periculoase amenințări pentru site-urile WordPress, rămânând în 2026 al treilea cel mai grav risc de securitate web conform clasificării OWASP. Prin exploatarea vulnerabilităților din plugin-uri, teme sau cod personalizat, atacatorii pot accesa, modifica sau distruge întreaga bază de date a site-ului dumneavoastră.

Conform unui raport Patchstack realizat în parteneriat cu Sucuri, 87% dintre vulnerabilitățile WordPress se găsesc în plugin-uri, 11% în teme și doar 2% în core-ul WordPress, ceea ce înseamnă că plugin-urile instalate sunt principalul vector de atac SQLi.

Atacuri SQL injection pe WordPress: cum funcționează și cum te protejezi

WordPress folosește MySQL sau MariaDB pentru stocarea tuturor datelor: articole, pagini, conturi de utilizatori, comentarii, setări și date din plugin-uri. Când un atacator reușește să injecteze comenzi SQL malițioase în interogările bazei de date, poate extrage parole, crea conturi de administrator sau șterge conținutul site-ului.

Câmpurile vulnerabile sunt oriunde utilizatorul poate introduce date: formulare de contact, câmpuri de căutare, parametri URL și secțiuni de comentarii.

Tipuri de atacuri SQL injection

SQL injection nu este o singură tehnică, ci o familie de metode cu mecanisme diferite. Înțelegerea acestora vă ajută să identificați și să preveniți fiecare tip.

SQL injection bazat pe erori

Atacatorul forțează baza de date să afișeze mesaje de eroare care dezvăluie structura tabelelor sau numele coloanelor. Aceste informații sunt folosite ulterior pentru atacuri mai sofisticate.

SQL injection UNION-based

Folosind operatorul UNION, atacatorul combină interogări multiple pentru a extrage date din tabele diferite simultan. Este unul dintre cele mai eficiente tipuri pentru furtul de credențiale.

Blind SQL injection

Atacatorul nu primește rezultate directe, ci observă comportamentul site-ului pentru a deduce conținutul bazei de date. Varianta time-based folosește funcții de tip SLEEP() pentru a detecta vulnerabilitățile prin întârzieri de răspuns.

Vulnerabilități SQLi reale din 2026

În februarie 2026, pluginul Ally pentru WordPress a primit patch pentru CVE-2026-2413, o vulnerabilitate SQL injection neautentificată care expunea peste 400.000 de site-uri. Atacatorii puteau extrage hash-urile parolelor direct din baza de date fără autentificare.

Tot în 2026, pluginul WP Maps a primit un patch pentru CVE-2026-3222, un SQL injection de tip time-based blind care bypassa funcția esc_sql() prin interpretarea input-ului ca denumire de coloană SQL în loc de valoare.

De ce esc_sql() nu este suficient

O greșeală frecventă a dezvoltatorilor de plugin-uri este să folosească esc_sql() fără să încadreze valoarea în ghilimele în interogarea SQL. Funcția scapă caracterele speciale, dar dacă valoarea este inserată direct ca identificator numeric sau denumire de coloană, escaparea devine ineficientă.

Soluția corectă este folosirea metodei wpdb->prepare(), care separă codul SQL de datele furnizate de utilizator prin interogări parametrizate.

Cum să protejați site-ul WordPress împotriva SQLi

Protecția eficientă combină măsuri tehnice la nivel de cod, configurații de server și plugin-uri de securitate.

• Actualizați constant plugin-urile și temele: majoritatea vulnerabilităților SQLi exploatate activ vizează versiuni vechi ale plugin-urilor pentru care există deja patch-uri disponibile. Activați actualizările automate pentru plugin-urile de securitate.
• Folosiți un Web Application Firewall (WAF): Cloudflare, Wordfence sau Sucuri pot detecta și bloca pattern-urile specifice atacurilor SQLi înainte ca acestea să ajungă la baza de date.
• Limitați privilegiile bazei de date: utilizatorul MySQL al WordPress-ului nu ar trebui să aibă privilegii de DROP, CREATE sau ALTER. Privilegiile SELECT, INSERT, UPDATE și DELETE sunt suficiente pentru funcționarea normală.
• Dezactivați afișarea erorilor PHP și MySQL: erorile detaliate oferă atacatorilor informații despre structura bazei de date. Setați WP_DEBUG la false în producție.
• Schimbați prefixul tabelelor WordPress: prefixul implicit wp_ este cunoscut de orice script automatizat de atac. Un prefix personalizat reduce eficiența atacurilor automate.

Configurare wpdb->prepare() corectă

Orice interogare SQL care include date din input-ul utilizatorului trebuie scrisă astfel:

global $wpdb;
$rezultat = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE ID = %d AND post_status = %s",
        $id_articol,
        'publish'
    )
);

Placeholder-urile %d (integer) și %s (string) asigură că datele sunt tratate ca valori, nu ca cod SQL executabil.

Detectarea unui atac SQL injection în desfășurare

Monitorizarea log-urilor de acces poate revela tentative de SQL injection. Căutați pattern-uri ca UNION SELECT, INFORMATION_SCHEMA, sau parametri URL cu caractere speciale (apostrof, ghilimele, comentarii SQL ca -- sau #).

Pluginuri ca Wordfence sau WP Activity Log înregistrează tentativele de acces suspect și pot trimite alerte în timp real.

Concluzie

SQL injection rămâne o amenințare activă pentru WordPress în 2026, alimentată de ecosistemul vast de plugin-uri cu cod de calitate variabilă. Actualizările regulate, un WAF configurat corect și limitarea privilegiilor bazei de date formează fundația unei protecții eficiente.

Dacă suspectați că site-ul dumneavoastră a fost compromis printr-un atac SQLi, serviciile noastre de curățare malware și audit de securitate WordPress vă stau la dispoziție.