Nessun login richiesto

Il 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato in silenzio, e con qualche ora di anticipo condiviso solo con i principali fornitori di infrastruttura, la patch per due vulnerabilità che insieme formano una catena di attacco particolarmente pericolosa: una SQL injection e una remote code execution non autenticata. Nessuna delle due richiede che l’attaccante possieda credenziali o interagisca con un utente reale: basta una richiesta HTTP costruita ad arte contro l’endpoint batch della REST API.

Se gestisci anche un solo sito WordPress — e in Italia sono milioni, molti dei quali proprio su blog tecnici o aziendali come questo — questa è una di quelle vulnerabilità da trattare come priorità operativa immediata, non come lettura per il weekend.

Le due CVE, in breve

Le vulnerabilità colpiscono punti diversi della catena di elaborazione di una richiesta:

• CVE-2026-60137 — SQL injection. Presente da WordPress 6.8 in poi. Un input malformato riesce ad alterare una query verso il database. Severità: Alta.
• CVE-2026-63030 — Remote Code Execution non autenticata. Presente da WordPress 6.9 in poi, e collegata direttamente alla SQL injection precedente. Sfrutta l’endpoint batch della REST API quando il sito non utilizza una cache a oggetti persistente (persistent object cache). Severità: Critica.

La combinazione delle due — nella comunità di sicurezza già ribattezzata informalmente “wp2shell” — permette a un attaccante di passare da un parametro malformato a esecuzione di codice arbitrario sul server, senza autenticazione e senza alcuna interazione da parte di amministratori o utenti.

Perché la object cache fa la differenza

Il dettaglio tecnico più interessante per chi amministra WordPress è che la RCE si manifesta specificamente quando manca una cache a oggetti persistente (tipicamente basata su Redis o Memcached). Molte installazioni WordPress “di default” — senza un livello di caching applicativo esterno a PHP — si affidano a una cache in memoria che vive solo per la durata della singola richiesta: è proprio l’assenza di persistenza a lasciare aperta la finestra che l’endpoint batch della REST API sfrutta per concatenare SQL injection ed esecuzione di codice. In altre parole, i siti più “semplici”, senza uno stack di caching avanzato, sono paradossalmente più esposti di quelli con un’infrastruttura più sofisticata.

La risposta di WordPress

Trattandosi della classe di severità più alta prevista dal team di sicurezza di WordPress, il rilascio della patch è stato accompagnato da aggiornamento automatico forzato per la maggior parte dei siti, un meccanismo che WordPress riserva solo alle emergenze più critiche. Le versioni corrette sono:

• 7.0.2 — release principale, corregge entrambe le vulnerabilità
• 6.9.5 — backport, corregge entrambe le vulnerabilità
• 6.8.6 — backport, corregge solo la SQL injection (la RCE non è presente su questo ramo)
• 7.1 Beta 2 — corregge entrambe

Le versioni precedenti alla 6.8 non risultano affette. Anche con l’aggiornamento automatico attivo, è buona norma verificare manualmente la versione installata:

# Da riga di comando, con WP-CLI
wp core version

# Oppure dalla dashboard: Bacheca → Aggiornamenti

Il ruolo del WAF: difesa in profondità, non sostituto della patch

Cloudflare, informata in anticipo dal team WordPress, ha distribuito due regole WAF dedicate alle 17:03 UTC del 17 luglio, attive automaticamente per tutti i clienti — inclusi quelli su piano gratuito — il cui traffico passa attraverso il proxy Cloudflare:

La prima regola intercetta i valori dei parametri malformati prima che raggiungano WordPress; la seconda blocca le richieste dirette verso il percorso di esecuzione del codice. Insieme coprono due punti distinti della catena di attacco. Cloudflare è però esplicita su un punto che vale la pena ribadire: le regole WAF riducono l’esposizione, non sostituiscono la patch. Chi utilizza Cloudflare su piano Pro, Business o Enterprise dovrebbe verificare che il Managed Ruleset sia attivo e che non vi siano override che trasformano l’azione da “Block” a “Log” — una configurazione non rara in ambienti dove si è voluto in passato ridurre i falsi positivi.

Checklist operativa

Per chi amministra siti WordPress, indipendentemente dal fatto che si usi o meno Cloudflare, questi sono i passi concreti da seguire subito:

• Verificare la versione di WordPress su tutte le installazioni gestite (non solo quella principale — anche i sotto-siti, gli ambienti di staging e i multisite dimenticati).
• Forzare l’aggiornamento a 7.0.2, 6.9.5 o 6.8.6 se l’auto-update non è ancora scattato:

  wp core update --version=7.0.2
  wp core update-db

• Se dietro Cloudflare: controllare in dashboard che le due regole (ID gestito 7dfb2bd4708d4b88b9911dc0550664b6 per la RCE e 1c060d3a371549219ee290d7ed933fcc per la SQLi) siano impostate su Block, e monitorare i Security Events per richieste bloccate su questi ID.
• Se non si usa un WAF: valutare regole custom su ModSecurity con OWASP CRS mirate all’endpoint /wp-json/*/batch, oppure disabilitare temporaneamente il batch endpoint tramite un mu-plugin, in attesa che l’aggiornamento venga completato su tutta la flotta:

  <?php
  // mu-plugins/disable-rest-batch.php
  add_filter('rest_pre_dispatch', function ($result, $server, $request) {
      if (strpos($request->get_route(), '/batch') !== false) {
          return new WP_Error('batch_disabled', 'Endpoint batch temporaneamente disabilitato', ['status' => 403]);
      }
      return $result;
  }, 10, 3);

• Abilitare una object cache persistente (Redis o Memcached) come mitigazione indiretta aggiuntiva, oltre ai benefici di performance che porta comunque.
• Controllare i log delle ultime settimane per richieste sospette verso gli endpoint REST batch, prima di considerare l’incidente chiuso.

In conclusione

Questa vicenda è un promemoria utile su due fronti. Il primo è tecnico: un endpoint REST pensato per efficienza (il batching di più operazioni in un’unica chiamata) può diventare superficie di attacco se la validazione dei parametri non è sufficientemente rigorosa lungo tutta la catena. Il secondo è organizzativo: la differenza tra un incidente e un mancato incidente, in casi come questo, si misura in ore — quelle tra la disclosure coordinata e la disponibilità pubblica dei dettagli, durante le quali chi ha automatizzato patching e monitoraggio dorme sonni più tranquilli di chi deve intervenire manualmente su decine di installazioni.

Fonte: The Cloudflare Blog.