miniOrange SAML SSO: bypass amministratore colpisce sei edizioni a pagamento

Due gravi vulnerabilità di bypass dell'autenticazione nel plugin miniOrange SAML 2.0 Single Sign On consentono a utenti non autenticati di falsificare le asserzioni SAML e di accedere a WordPress come qualsiasi utente esistente, inclusi gli amministratori. La ricerca è stata segnalata dal team di sicurezza di DigitalOcean, con analisi delle cause principali da parte di DigitalOcean e copertura e follow-up del fornitore gestiti congiuntamente con Patchstack. Entrambe le vulnerabilità hanno un punteggio CVSS di 9.8 e sono state divulgate pubblicamente a luglio 2026. Sebbene entrambe siano state corrette dal fornitore, un ampio gruppo di siti e molti clienti aziendali non avevano modo di sapere di essere stati colpiti, non vedevano aggiornamenti in sospeso nel loro pannello di controllo WordPress e non erano coperti da alcun database di vulnerabilità.

La prima vulnerabilità, CVE-2026-61979, è un problema di confusione dell'algoritmo di firma. Il plugin normalmente verifica una risposta SAML utilizzando una chiave pubblica RSA fidata dal provider di identità (IdP). Ma il plugin consente alla risposta SAML in arrivo di scegliere il proprio algoritmo di firma. Un attaccante può impostare il SignatureMethod su HMAC-SHA1, e il plugin usa quindi la chiave pubblica RSA PEM come segreto HMAC. Poiché quella chiave pubblica è pubblica per definizione, l'attaccante può recuperarla dall'endpoint dei metadati dell'IdP, usarla come segreto HMAC, firmare un'asserzione falsificata e il plugin la accetterà come autentica. L'analisi delle cause principali, eseguita sulla versione Standard 16.1.9, indica le righe 246-250 di Utilities.php, che leggono l'algoritmo selezionato dall'attaccante e convertono la chiave RSA, e le righe 308-314 e 546-548 di XMLSecurityKey.php, che lasciano il materiale della chiave PEM come byte grezzi e poi lo passano direttamente a hash_hmac(). miniOrange ha corretto questo problema nella versione Standard 17.0.5.

La seconda vulnerabilità, CVE-2026-15981, deriva da un controllo lasco del risultato della verifica OpenSSL. La funzione openssl_verify() restituisce 1 per una firma valida, 0 per una firma non valida e -1 quando OpenSSL incontra un errore interno. Il plugin controllava il risultato come booleano, e in PHP il valore -1 è truthy, quindi una firma malformata che innesca un percorso di errore OpenSSL veniva accettata come valida. I percorsi di codice rilevanti sono le righe 486-494 di XMLSecurityKey.php, che restituiscono il risultato grezzo a tre stati, e la riga 252 di Utilities.php, che lo valuta come booleano. miniOrange ha corretto questo problema nella versione Standard 17.0.6. Una terza questione separata è stata divulgata poco dopo queste correzioni, ma richiede che un amministratore clicchi qualcosa, quindi si colloca al di sotto delle prime due in termini di gravità pratica.

Il plugin è distribuito con un unico slug WordPress, miniorange-saml-20-single-sign-on, ma questo unico elenco contiene silenziosamente sette edizioni del prodotto con versioni separate. Gli advisory pubblici hanno sempre coperto solo l'edizione gratuita. Il fornitore ha fornito la seguente ripartizione. Free (sito singolo): prima versione 3.0.0, ultima 5.4.7, vulnerabile fino alla 5.4.4, corretta nella 5.4.5. Premium (sito singolo): prima versione 11.3.0, ultima 13.1.0, vulnerabile fino alla 13.0.3, corretta nella 13.0.4. Standard (sito singolo): prima versione 15.1.0, ultima 17.1.0, vulnerabile fino alla 17.0.5, corretta nella 17.0.6. Premium/Enterprise/All-Inclusive (multisito): prima versione 20.0.0, ultima 20.2.8, vulnerabile fino alla 20.2.7, corretta nella 20.2.8. Enterprise/All-Inclusive (sito singolo): prima versione 25.0.0, ultima 26.1.0, vulnerabile fino alla 26.0.2, corretta nella 26.0.3. VIP (sito singolo): prima versione 32.0.0, ultima 32.0.8, vulnerabile fino alla 32.0.7, corretta nella 32.0.8. VIP (multisito): prima versione 35.0.0, ultima 35.0.7, vulnerabile fino alla 35.0.6, corretta nella 35.0.7. Per controllare il tuo sito, trova la tua edizione e confronta la tua versione con le colonne vulnerabile e corretta.

Questo schema di versioni è il motivo per cui nessun database di vulnerabilità pubblico ha rilevato questi bypass dell'autenticazione. Un tipico record di vulnerabilità assume che tutte le versioni sotto un unico slug salgano in un'unica linea. Qui, salgono in sette fasce separate. L'unico advisory pubblico riguardava l'edizione gratuita, corretta alla 5.4.5. Qualsiasi installazione a pagamento ha un numero di versione superiore, quindi risulta già corretta. Ampliare l'intervallo interessato non aiuta, perché i siti dell'edizione gratuita dalla 5.4.5 in poi verrebbero erroneamente segnalati come vulnerabili. La soluzione corretta è registrare sette intervalli interessati disgiunti sullo stesso slug, che è ciò che ora contiene il record del database. Il pezzo mancante è sempre stata la tabella del fornitore, che non era stata pubblicata da nessuna parte fino a questo articolo.

La storia della rimedizione peggiora. Se stai eseguendo la versione Standard 16.1.9, il tuo pannello di controllo WordPress non mostra aggiornamenti disponibili, anche se la 17.0.6 esiste sulla stessa linea Standard per cui hai già una licenza. Il percorso di aggiornamento da una 16.x vulnerabile a una 17.x corretta è un caricamento manuale del plugin, perché il tipico meccanismo di aggiornamento di WordPress non offre un salto tra linee. DigitalOcean ha confermato entrambi i bug sulla 16.1.9, una release Standard della metà di quella linea, e la correzione è la 17.0.6. Non è prevista alcuna patch per la serie 16.x.

DigitalOcean ha trovato il problema grazie alla difesa in profondità. Non c'era alcun advisory da leggere, nessuna voce di database segnalava l'edizione a pagamento, e il plugin si dichiarava completamente aggiornato. Un tentativo anomalo di sessione amministratore WordPress proveniente da fuori dalla loro rete fidata è stato bloccato. L'attaccante aveva già usato il bypass per ottenere un cookie di sessione amministratore WordPress, ma le operazioni del pannello di amministrazione erano comunque limitate dalla rete fidata. Da lì, DigitalOcean ha riprodotto il bypass end-to-end sulla versione 16.1.9, ha tracciato entrambi i bug fino alle loro cause principali, ha determinato quali versioni a pagamento erano interessate, ha scritto le hotfix e ha condiviso l'analisi per il beneficio pubblico. È stata osservata attività di scansione contro gli endpoint SSO di miniOrange dai seguenti indirizzi IP: 207.211.214.41 (Bruxelles, Belgio, VPN/datacenter), 79.127.224.14 (Bruxelles, Belgio, VPN/datacenter), 102.91.71.83 (Abuja, Nigeria, operatore mobile), 162.243.116.148 (Secaucus, USA, cloud/VPS), 84.201.6.54 (Francoforte, Germania, hosting/datacenter) e 64.225.25.188 (Clifton, USA, cloud/VPS). La diffusione suggerisce scansioni opportunistiche piuttosto che una campagna mirata. L'attaccante non ha bisogno di sapere quale edizione esegui; tu sì.

Per proteggere il tuo sito WordPress, aggiorna il plugin alla versione nella colonna corretta per la tua edizione, come minimo, e aspettati di farlo tramite caricamento manuale. Se non puoi aggiornare immediatamente, DigitalOcean fornisce due hotfix mirate. Per la confusione dell'algoritmo, aggiungi subito dopo la riga 246 in Utilities.php: if ( XMLSecurityKey::HMAC_SHA1 === $MG ) { printf( 'HMAC SAML signatures are not supported.' ); exit; }. Per il problema del tri-stato OpenSSL, sostituisci il return in includes/lib/SAML2Core/XMLSecurityKey.php:494 con: return openssl_verify( $ql, $hl, $this->key, $MG ) === 1;. Entrambe le hotfix sono volutamente strette e pensate per guadagnare tempo, non per sostituire la correzione del fornitore. Una correzione completa richiede una lista consentita di algoritmi di firma RSA, la rimozione del percorso di conversione della chiave pubblica, un blocco rigido delle chiavi asimmetriche che entrano nei rami HMAC e l'indurimento della libreria di sicurezza XML inclusa. Controlla anche i tuoi log per sessioni amministratore autenticate da IP al di fuori dei tuoi intervalli previsti. Quel segnale non dipende dalla conoscenza della versione del plugin.

La lezione più ampia è che i database di vulnerabilità sono validi quanto i dati sulle versioni che i fornitori pubblicano. Quando un fornitore gestisce sette edizioni con numerazione indipendente sotto un unico slug e ne corregge sei senza un advisory pubblico, l'intero ecosistema a valle diventa cieco all'istante: database, scanner, pannelli di controllo e gli amministratori di siti che si affidano a tutti e tre. Il virtual patching era diverso: una regola firewall che blocca il pattern di sfruttamento non si cura di quale edizione esegui, quindi la protezione poteva coprire tutte e sette le edizioni contemporaneamente. L'allertamento accurato non poteva fare lo stesso; funziona solo se sa esattamente cosa hai installato. In questo caso, la protezione ha funzionato bene, ma la segnalazione si è rotta. Per le organizzazioni che si affidano a WordPress, un servizio di hosting gestito come AEU Hosting può aggiungere un altro livello che osserva gli accessi amministratore insoliti e blocca i pattern di sfruttamento noti, anche quando il feed di aggiornamento di un plugin ti inganna.

Il merito va al team di sicurezza di DigitalOcean per tutta la ricerca originale. Hanno rilevato e bloccato l'attività contro la loro infrastruttura, confermato e riprodotto il bypass sulla versione Standard 16.1.9, prodotto la piena analisi delle cause principali per entrambi i CVE sulle edizioni a pagamento, identificato le versioni corrette 17.0.5 e 17.0.6 che il fornitore ha distribuito senza una voce di changelog pubblica o advisory, scritto e validato le hotfix e condiviso gli indicatori di compromissione.