WPsec.itSicurezza WordPress
Tutti gli articoli
Vulnerabilità4 min di letturaTeam WPsec.it

miniOrange SAML SSO: due bypass admin sfuggiti agli scanner

Due vulnerabilità critiche in miniOrange SAML SSO hanno coinvolto sette edizioni con versioni diverse. Perché il dashboard poteva dire tutto aggiornato e cosa verificare.

Condividi
miniOrange SAML SSO: due bypass admin sfuggiti agli scanner

La lezione di questo incidente va oltre miniOrange. Un controllo automatico è affidabile solo quanto i dati di versione che riceve. Se un singolo identificatore di plugin rappresenta sette linee di prodotto con numeri diversi, la normale regola "versione minore della patch" non descrive più la realtà.

Patchstack e il team di sicurezza DigitalOcean hanno ricostruito il perimetro dopo aver rilevato e bloccato un tentativo di sessione amministrativa anomala. La loro analisi segnala anche scansioni opportunistiche contro gli endpoint SSO.

Cosa consentivano le due vulnerabilità

Entrambe sono bypass di autenticazione ad alto impatto, ma hanno punteggi diversi nei record pubblici: CVE-2026-61979 ha CVSS 8.1, mentre CVE-2026-15981 arriva a CVSS 9.8. Nascono inoltre da errori differenti.

CVE-2026-61979: confusione dell'algoritmo di firma

Il plugin poteva accettare un algoritmo HMAC scelto nella risposta in ingresso e usare materiale della chiave pubblica RSA come segreto. Una chiave pubblica, per definizione, non è segreta: la verifica finiva così per fidarsi di una firma costruibile dall'attaccante.

CVE-2026-15981: un errore OpenSSL trattato come successo

La funzione OpenSSL coinvolta può restituire tre risultati: firma valida, firma non valida oppure errore. Un controllo booleano non rigoroso interpretava il valore di errore come vero, permettendo a una firma malformata di superare la verifica.

Il risultato operativo era lo stesso: una risposta SAML falsa poteva essere associata a un utente WordPress già esistente, compreso un amministratore.

Le sette edizioni e le versioni corrette

La tabella seguente riprende il perimetro pubblicato dopo l'analisi congiunta. Va identificata prima l'edizione, poi confrontata la versione.

EdizioneVulnerabile fino aCorretta da
Free, sito singolo5.4.45.4.5
Premium, sito singolo13.0.313.0.4
Standard, sito singolo17.0.517.0.6
Premium, Enterprise o All-Inclusive multisite20.2.720.2.8
Enterprise o All-Inclusive, sito singolo26.0.226.0.3
VIP, sito singolo32.0.732.0.8
VIP, multisite35.0.635.0.7

Una versione 16.x, per esempio, non è "più nuova" della 5.4.5 nel senso utile al controllo: appartiene a un'altra edizione. Patchstack documenta inoltre che alcuni passaggi tra linee maggiori non venivano proposti dal normale aggiornamento WordPress e richiedevano un caricamento manuale del pacchetto corretto.

Perché scanner e dashboard potevano non avvisare

Un record di vulnerabilità WordPress usa normalmente tre dati:

  • slug del componente;
  • intervallo di versioni affette;
  • prima versione corretta.

Qui lo stesso slug rappresentava sette intervalli disgiunti. Il record pubblico iniziale copriva la linea Free, l'unica scaricabile liberamente. Le edizioni commerciali avevano numeri superiori e potevano quindi apparire automaticamente "oltre la versione corretta", anche quando il loro ramo specifico era vulnerabile.

Non era un falso negativo dovuto alla scansione del codice del sito. Era un limite del modello dati e della disclosure disponibile in quel momento.

Cosa fare se usi miniOrange SAML SSO

1. Identifica l'edizione esatta

Non annotare solo il nome del plugin e il numero di versione. Registra piano, edizione, sito singolo o multisite, canale di distribuzione e licenza associata.

2. Confronta la versione con la riga corretta

Usa la tabella del vendor o dell'advisory per la tua edizione. Se il dashboard non offre un update, non concludere che il sito sia già allineato: verifica il percorso di aggiornamento previsto dalla licenza.

3. Aggiorna con backup e test

Su un SSO aziendale, un update non testato può bloccare l'accesso legittimo. Prepara un backup verificato, conserva un accesso di emergenza controllato e prova login, logout, mapping dei ruoli e multisite dopo la patch.

4. Riduci l'esposizione durante la finestra

Se non puoi applicare subito la versione corretta, valuta con il vendor la disattivazione temporanea del flusso SSO o la mitigazione ufficiale. Non copiare patch manuali senza aver verificato edizione e file: le linee di prodotto non sono intercambiabili.

5. Cerca attività già avvenuta

Controlla sessioni amministrative provenienti da reti inattese, nuovi utenti, modifiche ai ruoli, plugin installati, cambi di configurazione e accessi fuori orario. Se trovi una sessione sospetta, revoca le sessioni, ruota le credenziali e le chiavi pertinenti, preservando prima log ed evidenze.

Il punto più importante: un semaforo verde non è una prova

Il caso miniOrange mostra perché un inventario serio deve contenere più del numero versione. Per software commerciale servono anche edizione, canale di aggiornamento e stato della licenza.

Uno scanner "verde" è un segnale utile, non una garanzia. Quando advisory, vendor e prodotto non condividono lo stesso modello di versioning, il controllo manuale diventa parte della patch.

Fonti

Pubblicato il

Condividi

Scritto dal team WPsec.it

Team WPsec.it

Bonifica malware, hardening, performance e manutenzione WordPress.

Prevenzione e gestione

Dopo l'emergenza, o per non arrivarci: le guide sulla gestione.

Sicurezza, velocità e manutenzione di WordPress sono lo stesso lavoro visto da tre lati. Queste pagine spiegano cosa controllare, con quale priorità e quanto costa farlo fare.

Continua a leggere

Articoli correlati.