La sicurezza di un sito WordPress non dipende soltanto dagli aggiornamenti del CMS. Anche il runtime PHP installato sul server deve rientrare nelle procedure di controllo e manutenzione.
Secondo gli advisory citati nel dossier, il 21 ottobre 2026 sono indicate correzioni urgenti per due vulnerabilità critiche nel core PHP. In determinate condizioni, l’impatto può comprendere divulgazione di memoria ed esecuzione di codice con i privilegi del worker web.
Questo non significa che tutti i siti WordPress siano automaticamente vulnerabili o sfruttabili nello stesso modo. Il rischio effettivo dipende anche da build PHP, estensioni, web server, frontend HTTP, configurazione e comportamento dell’applicazione. Per web agency e freelance, la risposta corretta è quindi una verifica puntuale di ogni ambiente.
Di cosa parlerò in questa pagina
Perché verificare subito il runtime PHP
WordPress utilizza PHP, ma non gestisce direttamente l’installazione e l’aggiornamento dell’interprete. PHP opera a livello di server o hosting: la patch deve quindi essere installata dal provider oppure da chi amministra l’infrastruttura.
Non basta sapere che un sito utilizza genericamente “PHP 8” o una serie come “PHP 8.2”. Occorre identificare la release effettivamente in esecuzione e ottenere conferma dell’applicazione di entrambe le correzioni indicate.
Le release corrette riportate sono:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
Nelle rispettive serie, le release precedenti sono indicate come vulnerabili. Negli hosting gestiti, tuttavia, il numero visualizzato potrebbe non mostrare eventuali patch specifiche applicate dal provider: per questo serve anche una conferma esplicita dell’hosting.
Le due vulnerabilità PHP da conoscere
GHSA-6wmf-4rv5-p3rp: stato residuo e use-after-free
La vulnerabilità GHSA-6wmf-4rv5-p3rp riguarda riferimenti alla memoria di una richiesta precedente che possono essere conservati da un worker PHP. Questo stato globale residuo può determinare un possibile use-after-free tra richieste.
Per questa vulnerabilità sono riportati attacchi validati su Apache con mod_php e, attraverso la gestione delle sessioni, anche su PHP-FPM. PHP-FPM non deve quindi essere considerato immune.
Disattivare la visualizzazione degli errori, modificare error_reporting oppure utilizzare l’operatore @ non elimina il problema.
GHSA-w8hw-w9fx-j79w: corruzione della memoria in condizioni OOM
La vulnerabilità GHSA-w8hw-w9fx-j79w riguarda la gestione degli errori out of memory. Richieste HTTP appositamente costruite, comprese richieste multipart, possono provocare uno stato di memoria incoerente.
Limitare la dimensione delle richieste, gli upload o il numero di parametri può ridurre l’esposizione, ma non equivale alla correzione. La versione PHP corretta è indicata come l’unica mitigazione completa.
Perché aggiornare WordPress non basta
Aggiornare il core di WordPress, i temi e i plugin resta un’attività importante, ma non corregge un difetto presente nell’interprete PHP. Si tratta di due livelli distinti:
- livello applicativo: WordPress, temi, plugin, mu-plugin e codice personalizzato;
- livello server: runtime PHP, web server, worker, pool e container.
Anche la compatibilità dichiarata tra il core WordPress e una serie PHP non certifica automaticamente l’intero stack. Tema, plugin, mu-plugin e sviluppi personalizzati devono essere collaudati con la release aggiornata.
Checklist: versione PHP e conferma dell’hosting
- Rilevare la release effettiva. Controllare PHP tramite Salute del sito di WordPress, pannello hosting, strumenti CLI oppure comando
php -v. - Annotare il numero completo. Indicazioni generiche come “PHP 8” o “PHP 8.2” non sono sufficienti per il confronto.
- Confrontare la release. Verificare la presenza di PHP 8.2.35, 8.3.36, 8.4.27 o 8.5.12, in base alla serie utilizzata.
- Contattare il provider. Chiedere se siano state applicate entrambe le correzioni indicate per il 21 ottobre 2026.
- Conservare la risposta. Archiviare la conferma nel registro di manutenzione del sito o del cliente.
- Verificare tutti gli ambienti. Il controllo deve comprendere pool, nodi, container e worker interessati.
Se il provider applica patch specifiche senza modificare il numero di release mostrato, la conferma scritta dell’hosting diventa essenziale per documentare l’intervento.
Cosa fare dopo l’aggiornamento
L’installazione della patch non conclude il lavoro. Dopo l’aggiornamento devono essere riavviati tutti i worker PHP interessati, inclusi PHP-FPM, Apache o i container utilizzati dall’infrastruttura.
È poi necessario verificare il funzionamento del sito con controlli mirati:
- login e area di amministrazione;
- moduli e caricamento dei file;
- checkout e pagamenti;
- REST API;
- cron;
- webhook;
- integrazioni con servizi esterni.
Devono essere controllati anche i log PHP e del web server. L’assenza di errori, però, non dimostra da sola che il server sia sicuro.
Per gestire eventuali incompatibilità è opportuno predisporre un backup verificato e una procedura di rollback. Quando possibile, il collaudo dello stack aggiornato dovrebbe essere effettuato prima in staging.
Come stabilire le priorità nel portafoglio clienti
Quando si gestiscono numerose installazioni, è utile partire dai siti con una maggiore superficie operativa o con release inferiori a quelle corrette indicate.
La precedenza può essere assegnata a:
- siti pubblici con moduli o funzionalità di upload;
- ecommerce;
- aree riservate;
- server amministrati direttamente;
- installazioni che risultano sotto le release corrette.
Per siti ancora basati su PHP 8.1 o versioni precedenti, oppure bloccati da componenti incompatibili, è necessario programmare una migrazione e un’attività di risanamento. Staging, backup verificato e rollback aiutano a gestire il passaggio senza confondere l’urgenza della patch con la compatibilità applicativa.
Supporto per verifica e collaudo
Posso supportare web agency, digital agency e freelance nella verifica della release PHP, nella raccolta delle conferme del provider, nel controllo della compatibilità dello stack WordPress e nei collaudi successivi alla patch.
AI Modified
Fonti
- Critical PHP Core Security Flaws Affect Websites, Including WordPress via @sejournal, @vahandev (www.searchenginejournal.com)
- RCE via stale global state · Advisory · php/php-src · GitHub (github.com)
- RCE via OOM corruption · Advisory · php/php-src · GitHub (github.com)
- PHP Compatibility and WordPress Versions – Make WordPress Core (make.wordpress.org)
Domande frequenti
No. Gli aggiornamenti di WordPress intervengono sul livello applicativo, mentre queste vulnerabilità riguardano il runtime PHP gestito dal server o dall’hosting.
È possibile controllarla tramite Salute del sito, pannello hosting, CLI oppure comando php -v. È necessario annotare la release completa, non soltanto la serie.
Le release corrette riportate sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. In presenza di patch specifiche del provider, occorre richiedere una conferma diretta all’hosting.
No. Per GHSA-6wmf-4rv5-p3rp sono riportati attacchi validati anche su PHP-FPM attraverso la gestione delle sessioni.
Occorre riavviare tutti i worker interessati e testare login, amministrazione, moduli, upload, checkout, pagamenti, REST API, cron, webhook e integrazioni esterne. Devono inoltre essere controllati i log e la compatibilità dell’intero stack.
No. Possono ridurre l’esposizione alla vulnerabilità legata alle condizioni out of memory, ma non costituiscono una correzione completa.
