WordPress 7.1.2: aggiorna adesso, poi leggi il perché

Se hai un sito WordPress, fermati un attimo e controlla la versione. Il 22 settembre è uscito WordPress 7.1.2, una release di sicurezza che corregge una vulnerabilità classificata come critica. Non è il solito aggiornamento da rimandare a venerdì pomeriggio.

Ti racconto cosa corregge, cosa fare subito e perché, dopo aver ripulito un paio di siti bucati, io su queste cose non scherzo più.

Cosa corregge WordPress 7.1.2

Secondo l’annuncio ufficiale, la falla permetteva a un attaccante non autenticato di includere file PHP locali che stanno fuori dalla cartella del tema attivo. Tradotto: in certe condizioni qualcuno, senza nemmeno fare login, poteva far eseguire al tuo server del codice PHP che non doveva essere eseguito. Da lì all’esecuzione di codice remoto il passo è breve, ed è proprio lo scenario che l’annuncio mette nero su bianco.

La vulnerabilità è tracciata come CVE-2026-87902 ed è stata segnalata in modo responsabile da Robert Ressl. La buona notizia è che la correzione è stata riportata su tutti i rami ancora supportati per la sicurezza, fino alla 4.7. Quindi anche se sei su una versione vecchia hai una patch disponibile, senza dover per forza fare il salto di major.

Tra l’altro arriva cinque giorni dopo la 7.1.1, uscita il 17 settembre con 11 correzioni di sicurezza. Se sei rimasto fermo alla 7.1, adesso i motivi per aggiornare sono due.

Cosa fare adesso, in ordine

Prima di tutto controlla a che versione sei. Lo vedi in Bacheca > Aggiornamenti oppure, se hai accesso SSH, con WP-CLI:

wp core version

In teoria gli aggiornamenti minori di sicurezza WordPress li installa da solo, e l’annuncio conferma che sui siti configurati per farlo l’aggiornamento parte in automatico. In pratica ho visto tante installazioni dove questa cosa era spenta: una costante nel wp-config.php, un plugin di gestione, oppure il WP Toolkit di Plesk con gli aggiornamenti automatici disattivati. Quindi non dare per scontato niente e controlla.

Se sei rimasto indietro, fai un backup e aggiorna. Con WP-CLI puoi limitarti alla release minore del tuo ramo, così non ti ritrovi con una major che non avevi in programma:

wp core update --minor

Se gestisci più siti per clienti, questo è il momento di farti un giro completo. Un sito dimenticato su un vecchio hosting è esattamente quello che un bot va a cercare.

Perché io un aggiornamento di sicurezza non lo rimando mai

Qualche tempo fa mi è capitato di gestire la compromissione completa di un sito WordPress di un cliente. Webshell nascoste dentro BuddyPress e nella cartella uploads, cioè file PHP che permettevano a chi li aveva caricati di fare praticamente quello che voleva sul server. Su un altro sito, invece, avevo trovato codice malevolo iniettato direttamente nel wp-settings.php, uno dei file del core.

In entrambi i casi la pulizia non è stata una passeggiata. Analisi dei file, confronto con il core originale, reinstallazione, cambio di tutte le credenziali, e poi giorni a controllare i log per essere sicuro che non ci fosse una seconda porta aperta. Aggiornare in tempo costa cinque minuti. Rimettere in piedi un sito bucato costa giorni, e spesso anche la fiducia del cliente.

Due controlli veloci che faccio sempre

Il primo: nella cartella uploads non dovrebbero esserci file PHP. Quella cartella serve per immagini e documenti, punto. Se trovi qualcosa qui, fermati e indaga:

find wp-content/uploads -name "*.php"

Il secondo: verifica che i file del core siano quelli originali. WP-CLI confronta i checksum con quelli ufficiali e ti dice se qualcuno ha toccato qualcosa:

wp core verify-checksums

Se entrambi tornano puliti e sei aggiornato a WordPress 7.1.2 (o alla patch del tuo ramo), puoi respirare. Se no, meglio saperlo oggi che scoprirlo quando Google inizia a segnalare il tuo sito come pericoloso.

Altri casi come questo li racconto nella categoria Sicurezza & Compliance, e prima o poi ci scrivo anche il diario completo di quell’incident response.