Una falla in miniOrange SAML SSO permetteva agli attaccanti di bypassare l'admin di WordPress

Due critiche vulnerabilità di bypass dell'autenticazione in WordPress nel plugin miniOrange SAML 2.0 Single Sign On, identificate come CVE-2026-61979 e CVE-2026-15981, permettevano a un attaccante non autenticato di accedere a un sito WordPress come qualsiasi utente esistente, incluso un amministratore. Non autenticato significa che l'attaccante non aveva bisogno di un proprio account né di una password. La scoperta e l'analisi della causa principale sono del team di sicurezza di DigitalOcean, con la copertura e il seguito del fornitore gestiti congiuntamente con Patchstack. Entrambi i bug hanno un punteggio CVSS di 9.8, una valutazione di gravità che va da 0 a 10, ed entrambi sono stati divulgati pubblicamente a luglio 2026.

Il plugin gestisce SAML, acronimo di Security Assertion Markup Language, uno standard che permette a un sito web di accettare un accesso confermato da un servizio di identità esterno invece di verificare la password da solo. Quel servizio esterno è chiamato Identity Provider, o IdP. Entrambe le falle annullano quella fiducia: convincono il plugin che un messaggio di accesso falsificato, chiamato asserzione SAML, sia autentico.

Il primo bug, CVE-2026-61979, è una confusione dell'algoritmo di firma. Una firma è il timbro digitale che prova che un messaggio proviene davvero dal servizio di identità fidato. Il plugin lascia che sia la risposta SAML in arrivo a scegliere quale metodo di firma è stato usato. Un attaccante può impostare quel metodo su HMAC-SHA1, un modo di firmare con una stringa segreta condivisa, e il plugin accetta allora la chiave RSA pubblica del provider di identità come se fosse quel segreto. Una chiave pubblica è, per definizione, pubblica. Quindi l'attaccante recupera la chiave dall'endpoint di metadati pubblicato dal provider di identità, firma la propria asserzione con essa, e il plugin accetta il risultato come autentico. L'analisi di DigitalOcean della versione Standard 16.1.9 indica percorsi di codice specifici: Utilities.php righe da 246 a 250, che leggono l'algoritmo scelto dall'attaccante e ricreano la chiave RSA; Utilities.php righe da 259 a 281, che estraggono e ricaricano la chiave pubblica; e tre punti in includes/lib/SAML2Core/XMLSecurityKey.php (righe da 216 a 218, da 308 a 314 e da 546 a 548) che permettono HMAC-SHA1 come opzione, lasciano il materiale della chiave pubblica come byte grezzi invece di rifiutarlo, e lo passano direttamente alla funzione hash_hmac come segreto. miniOrange ha corretto questo problema nella versione 17.0.5 per l'edizione Standard.

Il secondo bug, CVE-2026-15981, è un errore diverso con lo stesso esito. La funzione della libreria OpenSSL openssl_verify restituisce tre possibili risposte: 1 per una firma valida, 0 per una non valida e -1 quando OpenSSL stesso incontra un errore interno. Il plugin controllava quel risultato come un semplice vero o falso, e in PHP, il linguaggio di programmazione su cui gira WordPress, il numero -1 conta come vero. Quindi una firma malformata che attiva il percorso di errore di OpenSSL viene trattata come una firma valida. I percorsi di codice nella versione 16.1.9 sono XMLSecurityKey.php righe da 486 a 494, che restituisce il risultato grezzo a tre vie, e Utilities.php riga 252, che lo trasforma in un booleano. miniOrange ha corretto questo nella versione 17.0.6 per l'edizione Standard. Un terzo problema separato è stato divulgato poco dopo queste correzioni. Richiede che un amministratore clicchi qualcosa (descritto in termini CVSS come UI:R), quindi si colloca ben al di sotto degli altri due in termini di gravità pratica, ma Patchstack nota che vale la pena correggerlo nello stesso passaggio.

Il motivo per cui questa storia è più grande del codice è il confezionamento. miniOrange distribuisce tutti questi prodotti sotto un'unica scheda e slug di WordPress, miniorange-saml-20-single-sign-on, e quella singola scheda contiene sette edizioni con versioni separate. Nessuna coppia condivide un numero di versione. L'edizione gratuita per singolo sito va dalla 3.0.0 ed è attualmente alla 5.4.7, ed era vulnerabile fino alla 5.4.4 inclusa, corretta nella 5.4.5. La Premium per singolo sito va dalla 11.3.0 alla 13.1.0, vulnerabile fino alla 13.0.3 e corretta nella 13.0.4. La Standard per singolo sito va dalla 15.1.0 alla 17.1.0, vulnerabile fino alla 17.0.5 e corretta nella 17.0.6. Il piano multisito Premium, Enterprise e All-Inclusive va dalla 20.0.0 alla 20.2.8, vulnerabile fino alla 20.2.7 e corretto nella 20.2.8. Enterprise e All-Inclusive per singolo sito va dalla 25.0.0 alla 26.1.0, vulnerabile fino alla 26.0.2 e corretta nella 26.0.3. VIP per singolo sito va dalla 32.0.0 alla 32.0.8, vulnerabile fino alla 32.0.7 e corretta nella 32.0.8. VIP multisito va dalla 35.0.0 alla 35.0.7, vulnerabile fino alla 35.0.6 e corretta nella 35.0.7. Poiché ogni edizione copre diversi numeri di versione principali, un numero di versione da solo non ti dice quale edizione stai usando. Il fornitore ha fornito questa ripartizione completa a Patchstack, che afferma che non era stata pubblicata da nessuna parte prima.

Gli avvisi pubblici per entrambi i CVE coprivano solo l'edizione gratuita, l'unica che chiunque può scaricare da WordPress.org. Quel documento diceva che il plugin era interessato fino alla 5.4.4 inclusa e corretto nella 5.4.5. Il documento in sé è corretto, ma è un singolo intervallo associato a un singolo slug. Ogni installazione a pagamento ha un numero di versione superiore alla 5.4.5, quindi ogni installazione a pagamento risultava già corretta. Un sito sulla vulnerabile versione Standard 16.1.9 veniva segnalato come non interessato, e così ogni altra versione a pagamento vulnerabile nelle linee 13.x, 20.x, 26.x, 32.x e 35.x. Ampliare l'intervallo non risolve nemmeno: estendi il documento alla 17.0.5 in modo che una 16.1.9 vulnerabile venga intercettata, e i siti con edizione gratuita già corretti sulla 5.4.5 o successiva iniziano a essere segnalati come vulnerabili. La tabella del fornitore descrive l'insieme interessato esattamente come sette intervalli separati su uno slug, che è ciò che il documento del database contiene ora. Le sei edizioni a pagamento sono state corrette senza alcuna voce pubblica nel changelog e senza alcun avviso di sicurezza pubblico, ed è così che l'intera catena a valle, database, scanner e dashboard, è diventata cieca all'improvviso.

Anche la risoluzione è stata difficile da trovare. Patchstack afferma che i siti WordPress su una versione Standard 16.x vulnerabile non vedono alcun aggiornamento disponibile nella dashboard di amministrazione, anche se la 17.0.6 corretta esiste sulla stessa linea Standard per cui il cliente ha già una licenza. Il tipico meccanismo di aggiornamento di WordPress non offre quel tipo di salto tra linee di versione principali, quindi la correzione deve essere caricata manualmente.

Ciò che rende il caso notevole è come il problema è stato effettivamente individuato. Non c'era alcun avviso da leggere e nessuna voce nel database che segnalasse le edizioni a pagamento, e il plugin si dichiarava completamente aggiornato. Ogni segnale che normalmente avverte di un problema diceva che tutto andava bene. DigitalOcean lo ha individuato attraverso la difesa in profondità piuttosto che attraverso i dati del plugin: un tentativo anomalo di sessione amministratore di WordPress è arrivato dall'esterno della sua rete fidata ed è stato bloccato. L'attaccante aveva già usato il bypass per ottenere un cookie di sessione amministratore, il token che ti mantiene connesso, ma è stato fermato perché le operazioni del pannello di amministrazione su quell'infrastruttura erano limitate alla rete fidata. Il team ha poi riprodotto il bypass dall'inizio alla fine sulla versione 16.1.9, ha rintracciato entrambi i bug a righe specifiche, ha capito quali versioni a pagamento erano interessate dove il fornitore non aveva pubblicato nulla, ha scritto e convalidato due hotfix, e ha condiviso l'analisi per la pubblicazione. Patchstack segnala attività di scansione contro gli endpoint SSO di miniOrange da 207.211.214.41 e 79.127.224.14 a Bruxelles, Belgio (VPN o datacenter), 102.91.71.83 ad Abuja, Nigeria (operatore mobile), 162.243.116.148 a Secaucus, Stati Uniti (cloud o VPS), 84.201.6.54 a Francoforte, Germania (hosting o datacenter) e 64.225.25.188 a Clifton, Stati Uniti (cloud o VPS). La diffusione geografica suggerisce una scansione opportunistica piuttosto che una campagna mirata, con l'attaccante che colpisce ogni sito che ha il plugin installato senza controllare quale edizione ci sia dietro. Una prova di concetto pubblica per le versioni gratuite esiste su GitHub; Patchstack ha detto che non avrebbe riprodotto i passaggi di sfruttamento perché non aggiungono nulla in termini difensivi.

Per chiunque gestisca una versione interessata, il consiglio di Patchstack è di aggiornare alla versione corretta per la propria edizione, aspettandosi di caricare il file del plugin a mano invece di cliccare un pulsante di aggiornamento. Se un aggiornamento immediato è impossibile, DigitalOcean ha pubblicato due hotfix deliberatamente ristretti: uno che impedisce al plugin di accettare un metodo di firma HMAC-SHA1, aggiunto subito dopo la riga 246 di Utilities.php, e uno che fa sì che il controllo della firma alla riga 494 di XMLSecurityKey.php accetti solo un risultato esattamente pari a 1. Entrambi servono a guadagnare tempo, non a sostituire la correzione del fornitore. Una correzione completa richiederebbe una restrizione su quali algoritmi di firma sono consentiti, la rimozione del percorso di codice che ricrea una chiave pubblica, un blocco rigido sulle chiavi asimmetriche che entrano nel ramo HMAC, e un rafforzamento generale della libreria di sicurezza XML inclusa. Patchstack raccomanda anche di controllare i log per sessioni amministratore autenticate provenienti da indirizzi IP al di fuori dei tuoi intervalli abituali, poiché quel segnale non dipende dalla versione del tuo plugin. Per i team che preferiscono non gestire da soli gli aggiornamenti dei plugin, AEU Hosting fornisce hosting WordPress gestito con l'applicazione delle patch gestita come parte del servizio, che è il tipo di accordo che elimina un passaggio di caricamento manuale dalla tua lista di cose da fare.

La lezione più ampia che Patchstack trae è che i database delle vulnerabilità valgono solo quanto le informazioni sulla versione che i fornitori pubblicano. Quando uno slug nasconde sette edizioni numerate indipendentemente e sei di esse vengono corrette senza un avviso pubblico, i database, gli scanner e le dashboard a valle falliscono tutti insieme. Patchstack fa qui una distinzione precisa: una regola del firewall che blocca il pattern di exploit non si preoccupa di quale edizione tu stia usando, quindi il patching virtuale può proteggere tutte e sette contemporaneamente, che siano documentate o meno, mentre un avviso accurato non può, perché funziona solo se sa cosa hai installato. In questo caso la protezione è scalata; ciò che si è rotto è la segnalazione.