Due bypass di autenticazione critici nel plugin miniOrange SAML 2.0 Single Sign On per WordPress sono sotto attacco. Le falle, tracciate come CVE-2026-61979 e CVE-2026-15981 (entrambe CVSS 9.8), permettono a un attaccante non autenticato di forgiare una risposta SAML e ritrovarsi in /wp-admin con l'identità di qualsiasi utente esistente, amministratori compresi.

La parte interessante di questa vicenda, però, non è il bug in sé: è il motivo per cui migliaia di siti già patchabili da luglio risultavano "non vulnerabili" a ogni scanner del pianeta.

I due bug, in concreto

Il plugin trasforma un sito WordPress in un service provider SAML, permettendo il login tramite Entra ID, Okta, Google Workspace o OneLogin invece delle credenziali WordPress. La verifica della firma dell'asserzione SAML è quindi l'unico controllo che separa un visitatore anonimo dalla dashboard di amministrazione.

CVE-2026-61979 — confusione di algoritmo. Il plugin accetta l'algoritmo di firma indicato nella risposta SAML in arrivo, invece di imporre quello configurato. Un attaccante imposta SignatureMethod su HMAC-SHA1 e il plugin usa la chiave pubblica RSA dell'identity provider come segreto condiviso HMAC. La chiave pubblica è, per definizione, pubblica: si scarica dall'endpoint dei metadati dell'IdP, si firma la propria asserzione con quella e il plugin la considera autentica. Corretta nella 17.0.5 per l'edizione Standard.

CVE-2026-15981 — errore OpenSSL letto come successo. La funzione openssl_verify() restituisce tre valori: 1 per firma valida, 0 per non valida, -1 quando OpenSSL stesso va in errore. Il plugin valutava il risultato come booleano e in PHP -1 è truthy. Una firma malformata che manda OpenSSL in errore interno viene quindi accettata come valida. Corretta nella 17.0.6 per l'edizione Standard.

Le due falle possono essere concatenate. Il risultato è un accesso amministrativo completo senza credenziali.

Sette edizioni sotto un unico slug: perché i database non le hanno viste

Xecurify, l'azienda dietro miniOrange, distribuisce il plugin sotto un unico slug WordPress (miniorange-saml-20-single-sign-on), ma quello slug contiene sette edizioni versionate in modo indipendente: gratuita (3.x-5.x), Premium (11.x-13.x), Standard (15.x-17.x), Premium/Enterprise/All-Inclusive multisite (20.x), Enterprise/All-Inclusive single site (25.x-26.x), VIP single site (32.x) e VIP multisite (35.x).

L'advisory pubblico copriva solo l'edizione gratuita: vulnerabile fino alla 5.4.4, corretta nella 5.4.5. Un record di vulnerabilità WordPress associa uno slug a un intervallo di versioni affette. Applicando quell'intervallo allo slug, ogni installazione a pagamento — che porta un numero di versione più alto — risultava già patchata. Un sito con la Standard 16.1.9, cioè vulnerabile a entrambe le CVE, veniva riportato come sicuro da qualsiasi scanner.

E non è un problema risolvibile allargando l'intervallo: portarlo fino alla 17.0.5 farebbe risultare vulnerabili tutti i siti free sulla 5.4.5, che invece sono a posto. Le sei edizioni a pagamento erano state corrette senza changelog pubblico e senza advisory, quindi nessun database poteva saperlo.

Il colpo di grazia: su una 16.x la dashboard WordPress non mostra alcun aggiornamento disponibile, perché il salto alla linea 17.x non è gestito dal meccanismo di update automatico. Va fatto a mano.

Come è emerso, e cosa dice sulle difese

Il team di sicurezza di DigitalOcean ha bloccato, il 16 agosto, una sessione amministrativa WordPress anomala proveniente da fuori dalla propria rete fidata. L'attaccante aveva già ottenuto il cookie di sessione admin tramite il bypass, ma le operazioni sul pannello erano vincolate alla rete fidata: la difesa in profondità ha retto proprio dove il controllo primario aveva ceduto.

DigitalOcean ha poi riprodotto il bypass sulla 16.1.9, tracciato le cause fino alle righe di codice, identificato le versioni corrette e pubblicato l'analisi insieme a Patchstack. La scansione opportunistica è in corso da sei indirizzi IP fra Europa, Africa e Stati Uniti, e un proof of concept pubblico per l'edizione gratuita è già su GitHub.

Cosa significa per le aziende italiane

Il primo punto è il più scomodo. Il plugin serve a integrare WordPress con l'identity provider aziendale: chi lo usa non è il blog personale, è l'azienda strutturata con Entra ID o Okta, quella con una intranet, un portale clienti o un sito corporate agganciato all'SSO. Sono esattamente le organizzazioni che hanno un processo di patching, uno scanner e una policy — e tutti e tre dicevano "a posto".

Questo è il motivo per cui la vicenda merita attenzione oltre il singolo plugin. Il modello mentale diffuso è: lo scanner non segnala nulla, quindi siamo aggiornati. Qui il vendor ha spezzato l'assunto su cui l'intera catena si regge — un numero di versione più alto significa più recente — e tutto ciò che sta a valle è diventato cieco insieme. La lezione operativa è che l'assenza di segnalazioni non è una prova di sicurezza, ed è tanto più vera quanto più il software è a pagamento, distribuito fuori dai repository pubblici e privo di changelog di sicurezza.

Il secondo punto riguarda l'impatto. Un amministratore WordPress ottenuto in questo modo non è "solo" un defacement: è caricamento di plugin arbitrari, quindi esecuzione di codice PHP sul server, accesso al database con i dati degli utenti registrati e, in un'integrazione SSO, un punto di osservazione sul flusso di autenticazione aziendale. Se sul sito ci sono account clienti, siamo nel perimetro del GDPR: violazione dei dati personali da valutare ai sensi dell'articolo 33 e, se il rischio per gli interessati è elevato, notifica al Garante entro 72 ore e comunicazione agli interessati stessi. Per i soggetti in perimetro NIS2, un sito corporate integrato con l'IdP aziendale è a tutti gli effetti parte della superficie da governare, non un asset di marketing da lasciare all'agenzia esterna.

Terzo punto, la responsabilità del fornitore. Molti siti aziendali italiani sono gestiti da agenzie web con contratti di manutenzione. Vale la pena verificare cosa dice esattamente il contratto: "aggiornamento plugin" via dashboard non copre un caso come questo, dove l'aggiornamento va caricato manualmente e nessun alert lo segnala.

Cosa fare subito

  • Verificare l'edizione, non solo la versione. Le versioni corrette sono: Free 5.4.5, Premium 13.0.4, Standard 17.0.6, Premium/Enterprise/All-Inclusive multisite 20.2.8, Enterprise/All-Inclusive single site 26.0.3, VIP single site 32.0.8, VIP multisite 35.0.7.
  • Aggiornare a mano. Su una 16.x non comparirà alcun prompt: scaricare il pacchetto dal portale miniOrange e caricarlo via upload manuale.
  • Se non si può aggiornare subito, DigitalOcean ha pubblicato due hotfix chirurgici: rifiutare esplicitamente HMAC-SHA1 in Utilities.php e confrontare il risultato di openssl_verify() con === 1 invece di valutarlo come booleano. Sono tamponi per guadagnare tempo, non sostituti della patch.
  • Controllare i log per sessioni amministrative autenticate provenienti da IP fuori dagli intervalli attesi. È il segnale che ha fatto emergere il caso e non richiede di conoscere la versione del plugin.
  • Limitare /wp-admin alla rete fidata o dietro VPN. È la misura che ha effettivamente fermato l'attacco su DigitalOcean.
  • Ruotare le credenziali amministrative, le chiavi API e i sali di autenticazione WordPress se emergono accessi sospetti, e verificare la presenza di plugin o utenti creati di recente.
  • Chiedere all'agenzia che gestisce il sito una conferma scritta dell'edizione e della versione installate.