CVE-2026-116512: RCE nel plugin WordPress Project Manager, come verificare e aggiornare

Se sul tuo sito WordPress è installato il plugin Project Manager di weDevs (AI Powered Project Management, Task Management, Kanban Board & Time Tracker), devi intervenire ora. CVE-2026-116512 permette a chiunque, senza login, di eseguire codice PHP sul server. Punteggio CVSS 9.8, gravità critica. Qui spiego cosa è successo, come capire se sei esposto e cosa fare.

Cosa è successo: la vulnerabilità CVE-2026-116512 in Project Manager

Il plugin espone alcune rotte REST. Per validare gli argomenti usa un sistema di regole scritte in una stringa separata dal carattere pipe (|). Il valore del parametro id viene concatenato in quella stringa senza alcuna sanificazione. La stringa viene poi divisa e ogni pezzo viene invocato come funzione PHP dinamica, senza una lista di funzioni consentite.

Il punto che rende tutto grave è l'ordine di esecuzione di WordPress. Il core esegue la validate_callback degli argomenti dentro WP_REST_Server::dispatch() prima della permission_callback della rotta. Il controllo di autorizzazione del plugin (Project_Manage_Capability) quindi non viene mai raggiunto. Il codice vulnerabile gira prima che il sito chieda chi sei.

Chi è colpito: versioni vulnerabili di Project Manager

• Plugin: Project Manager – AI Powered Project Management, Task Management, Kanban Board & Time Tracker per WordPress (slug wedevs-project-manager).
• Versioni vulnerabili: tutte fino alla 4.1.1 inclusa.

Non conta se il plugin è attivo da anni o se nessuno lo usa davvero. Se è attivo, le sue rotte REST sono registrate e raggiungibili. La versione corretta va verificata sulla pagina del plugin nel repository WordPress.org e sull'advisory Wordfence linkato in fondo.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il vettore è CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, punteggio 9.8. Tradotto: attacco via rete, bassa complessità, nessun privilegio richiesto, nessuna interazione dell'utente, impatto alto su riservatezza, integrità e disponibilità.

Il risultato è una Remote Code Execution (RCE) non autenticata. Un attaccante può eseguire funzioni PHP sul server con i permessi dell'utente web. In pratica può leggere wp-config.php e quindi le credenziali del database, caricare una webshell, creare un amministratore, modificare i file del tema, usare il server per inviare spam o per attaccare altri sistemi.

La vulnerabilità non risulta al momento nel catalogo CISA KEV delle falle sfruttate attivamente. Questo non è una garanzia: le RCE non autenticate sui plugin WordPress vengono di norma scansionate in massa poco dopo la pubblicazione, perché il bersaglio è facile da individuare.

Come capire se sei esposto: verifica versione, esposizione e log

Versione installata

• Da bacheca: Plugin > Plugin installati, cerca Project Manager e leggi il numero di versione.
• Da riga di comando con WP-CLI: wp plugin get wedevs-project-manager --field=version.
• Da file system: apri l'intestazione del file principale in wp-content/plugins/wedevs-project-manager/ e leggi la riga Version.

Se la versione è 4.1.1 o inferiore e il plugin è attivo, sei esposto.

Esposizione delle rotte REST

Visita https://tuosito.it/wp-json/ e cerca nell'elenco dei namespace quello del plugin. Se compare, le rotte sono raggiungibili da internet. Un sito pubblico lo è quasi sempre, salvo filtri a livello di web server o WAF che bloccano l'API REST per utenti non autenticati.

Log e indicatori di compromissione

• Nei log di accesso del web server (access.log di Apache o Nginx) cerca richieste verso /wp-json/ con parametro id contenente il carattere pipe o nomi di funzioni PHP (per esempio system, exec, eval, file_put_contents).
• File PHP nuovi o modificati di recente in wp-content/uploads/, nella root del sito o nelle cartelle del tema. Un comando utile: find /percorso/sito -name "*.php" -mtime -14.
• Utenti amministratori sconosciuti in Utenti.
• Cron job di WordPress o di sistema non riconosciuti.
• Verifica integrità del core e dei plugin: wp core verify-checksums e wp plugin verify-checksums --all.

Per una lista più ampia di controlli, ho scritto una guida dedicata ai controlli di sicurezza su un sito WordPress.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

Il rimedio è aggiornare il plugin alla versione corretta. Nel repository WordPress.org esiste un changeset (3772103) che modifica il file core/Validator/Abstract_Validator.php nel trunk, cioè il punto in cui le regole di validazione vengono trasformate in chiamate di funzione. Il numero di versione che include questa correzione va verificato sulla pagina del plugin e sull'advisory Wordfence prima di considerarsi al sicuro.

1. Fai un backup completo (file e database) prima di toccare qualsiasi cosa.
2. Vai in Bacheca > Aggiornamenti oppure usa wp plugin update wedevs-project-manager.
3. Dopo l'aggiornamento ricontrolla la versione installata e confrontala con quella indicata come corretta nell'advisory.
4. Se non è disponibile una versione corretta, disattiva il plugin. La disattivazione rimuove le rotte REST e chiude il percorso di attacco.

Cosa fare subito: mitigazioni e hardening

1. Aggiorna o disattiva il plugin. È la misura che conta. Le altre riducono il rischio ma non lo eliminano.
2. Limita l'API REST. Se usi un WAF (Wordfence, un reverse proxy o le regole dell'hosting), blocca le richieste alle rotte del plugin da utenti non autenticati finché non hai aggiornato.
3. Rivedi i permessi dei file. L'utente web non dovrebbe poter scrivere nelle cartelle del core e dei plugin. Disabilita l'editor dei file da bacheca con DISALLOW_FILE_EDIT in wp-config.php.
4. Ruota le credenziali. Password degli amministratori, password del database, chiavi API di servizi collegati (SMTP, pagamenti, CRM). Se un attaccante ha letto wp-config.php, quelle credenziali sono compromesse.
5. Separa i siti. Se più siti condividono lo stesso utente di sistema o lo stesso database, una compromissione si propaga. Valuta utenti e database distinti per ogni installazione.
6. Rimuovi i plugin che non usi. Ogni plugin attivo è superficie di attacco.

Chi non ha tempo o competenze per seguire gli aggiornamenti può affidarsi a un contratto di manutenzione e assistenza del sito: la gestione delle patch dei plugin è esattamente ciò che include.

Se sospetti una compromissione: incident response e analisi forense

Se trovi file sconosciuti, utenti nuovi o richieste anomale nei log, l'aggiornamento da solo non basta. Una webshell caricata prima della patch continua a funzionare dopo.

• Non cancellare nulla di fretta e non reinstallare il sito prima di aver conservato le prove. Perderesti log e file che servono per capire cosa è stato fatto.
• Conserva i log del web server, di PHP e del database. Molti hosting li ruotano dopo pochi giorni: esportali subito.
• Fai una copia forense dei file e del database prima di ogni bonifica. Se il sito gira su una VPS, una copia dell'intero disco è preferibile.
• Metti il sito in manutenzione o isolalo finché non hai chiarito l'estensione del problema.
• Valuta gli obblighi di notifica. Se il sito gestisce dati personali (utenti, clienti, candidature), un accesso non autorizzato può essere una violazione da valutare ai sensi del GDPR entro i termini previsti.

Nel mio studio seguo questi casi con un servizio di incident response, con preventivo a prezzo fisso da 1.500 a 6.000 euro a seconda dell'estensione: acquisizione delle prove, ricostruzione dell'accesso, bonifica e relazione tecnica utilizzabile anche per denuncia o assicurazione.

Fonti ufficiali

• Advisory Wordfence su CVE-2026-116512
• Codice del router REST, versione 4.1.1
• Validatore vulnerabile, versione 4.1.1
• Validatore Update_Project, versione 4.1.1
• Changeset 3772103 sul trunk del plugin

Hai bisogno di una verifica?

Se non sai se il tuo sito è esposto, o se hai trovato qualcosa di strano nei log, posso controllarlo per te. Richiedi un preventivo gratuito: rispondo entro 24 ore. Per un'urgenza scrivimi direttamente dalla pagina contatti, anche su WhatsApp.