miniOrange SAML SSO CVE-2026-15981: Chiunque Può Fare l'Admin del Tuo WordPress

Il single sign-on esiste per rendere un solo identity provider l'unico arbitro di chi sei. Quando il codice che verifica la firma dell'IdP è sbagliato, quell'arbitro dice sì a tutti. È esattamente la situazione in cui si trova questa settimana il plugin miniOrange SAML 2.0 Single Sign-On per WordPress. Due vulnerabilità — CVE-2026-15981 (CVSS 9.8) e CVE-2026-61979 (CVSS 8.1, valutata 9.8 dagli scopritori di Patchstack) — consentono a un attaccante non autenticato di forgiare un'asserzione SAML che il plugin accetta come autentica ed entrare in /wp-admin come qualsiasi utente esistente, amministratori inclusi. Patchstack ha trovato il plugin che pubblica questa porta su sette edizioni versionate separatamente, e DigitalOcean ha già intercettato qualcuno che bussava.

Due bug, una porta: come funziona il bypass di miniOrange SAML SSO

Un login SAML è un documento XML firmato. L'identity provider dichiara "questa è Alice", firma l'asserzione con la propria chiave privata, e il service provider — qui il plugin WordPress — verifica quella firma contro il certificato pubblico dell'IdP prima di fidarsi del nome contenuto. La sicurezza dell'intero flusso poggia su un punto solo: chi verifica deve controllare la firma nel modo in cui l'IdP l'ha prodotta, sui byte che effettivamente consuma. Il plugin miniOrange sbaglia in due modi indipendenti.

CVE-2026-61979 — confusione di algoritmo. Il plugin lascia che la risposta SAML in ingresso scelga da sé l'algoritmo di firma invece di imporre quello configurato per l'IdP. L'attaccante imposta l'algoritmo su HMAC-SHA1. HMAC è una costruzione simmetrica: firmare e verificare usano lo stesso segreto. Il plugin, ricevuto un documento firmato in HMAC, prende l'unico materiale di chiave che ha per quell'IdP — il certificato RSA pubblico — e lo usa come segreto HMAC. Ma quel certificato è pubblico. Chiunque può scaricarlo. Così l'attaccante calcola una firma HMAC-SHA1 perfettamente valida su un'asserzione a sua scelta, usando la stessa chiave pubblica con cui il plugin verificherà, e il controllo passa.

CVE-2026-15981 — quel -1 che voleva dire sì. Il percorso di verifica RSA del plugin chiama la funzione PHP openssl_verify(), che restituisce tre valori, non due: 1 per firma valida, 0 per firma non valida e -1 per errore. Il codice trattava il risultato come un booleano. In PHP, -1 è truthy. Una firma malformata che manda OpenSSL in errore restituisce -1, il plugin lo legge come "valida", e l'asserzione forgiata passa.

Uno solo dei due bug è già game over. Insieme, significano che né la strada "usa una chiave simmetrica" né la strada "rompi la matematica RSA" sono chiuse.

A un attaccante non serve il tuo IdP, non servono le tue credenziali, non serve un'esca di phishing. Scarica il tuo certificato SAML pubblico — è pubblico per progetto — costruisce un'asserzione che dice NameID: [email protected], la firma con un algoritmo che il plugin avrebbe dovuto rifiutare e la invia in POST al tuo endpoint SSO. Il plugin verifica la contraffazione contro la stessa chiave che l'ha prodotta e restituisce una sessione admin autenticata. Interazione totale: una richiesta HTTP.

Perché i bug di firma SAML tornano sempre — una classe, non un incidente

Se la cosa suona familiare, è giusto così. La stessa knowledge base di Zero Hunt segnala CVE-2026-61979 come una ripetizione quasi identica di un bug riscoperto in libreria SAML dopo libreria SAML. Lo schema è sempre una di due forme: verificare un algoritmo diverso da quello inteso dall'IdP, oppure verificare una parte del documento diversa da quella che si consuma. La discendenza è lunga e recente:

Vulnerabilità	Libreria	Causa radice
CVE-2024-45409	Ruby-SAML	Firma verificata sul nodo sbagliato; qualsiasi documento firmato dall'IdP poteva essere riusato per forgiare una response
GHSA-c27r-x354-4m68	xml-crypto	Key confusion HMAC-SHA1 — firma valida forgiata dalla sola conoscenza della chiave RSA pubblica
CVE-2017-11428 / -11429	Ruby-SAML / saml2-js	Disallineamento canonicalizzazione XML + traversal del DOM (signature wrapping)
CVE-2021-21239	PySAML2	Verifica di firma impropria nel backend crittografico di default
CVE-2025-54419	Node-SAML	Asserzione caricata dalla response originale non firmata, non dal sottoinsieme verificato

miniOrange CVE-2026-61979 è il bug di key confusion di xml-crypto, re-implementato in PHP. CVE-2026-15981 è una variante del "chi verifica ha restituito qualcosa che non hai controllato bene". Nessuno di questi è esotico. Sono ciò che accade quando SAML — uno standard di sicurezza XML vecchio di vent'anni, con più funzionalità opzionali di quante la maggior parte dei team ne legga — viene implementato da zero invece di essere delegato a un toolkit indurito e ben verificato che impone l'algoritmo e firma-ciò-che-legge per costruzione.

Sette edizioni, uno slug: il problema del patch-gap

Il plugin è distribuito sotto un unico slug WordPress, miniorange-saml-20-single-sign-on, ma come sette edizioni versionate in modo indipendente. Le versioni corrette non sono "aggiorna a 5.4.5" per tutti — ogni edizione ha la sua linea:

Edizione	Vulnerabile fino a	Corretta in
Free	5.4.4	5.4.5
Premium (single site)	13.0.3	13.0.4
Standard (single site)	17.0.5	17.0.6
Premium/Enterprise/All-Inclusive (multisite)	20.2.7	20.2.8
Enterprise/All-Inclusive (single site)	26.0.2	26.0.3
VIP (single site)	32.0.7	32.0.8
VIP (multisite)	35.0.6	35.0.7

La parte pericolosa non è la frammentazione delle versioni — è l'asimmetria nella comunicazione. Secondo BleepingComputer, le vulnerabilità sono state corrette a luglio, ma il vendor ha avvisato solo gli utenti dell'edizione Free. I clienti paganti sui piani Standard, Premium, Enterprise e VIP — proprio quelli che più probabilmente hanno business reale dietro l'SSO — hanno ricevuto una patch silenziosa senza alcun avviso. miniOrange dichiara circa 30.000 clienti su tutte le edizioni; la sola versione Free mostra circa 10.000 installazioni attive. Una patch che nessuno ti dice di applicare è, ai fini dell'esposizione, come non averla.

Già in the wild: cosa ha visto DigitalOcean

Non è teoria. Il 16 agosto 2026 il team di sicurezza di DigitalOcean ha rilevato — e bloccato — una sessione amministratore WordPress anomala proveniente da fuori della propria rete fidata, risalendo a un tentativo di sfruttamento contro l'edizione Standard. Patchstack ha documentato l'attività successiva: scansioni opportunistiche da sei indirizzi IP distribuiti tra Belgio, Nigeria, Stati Uniti e Germania. Sia SecurityWeek sia The Hacker News descrivono il traffico come ampio e opportunistico più che come una campagna mirata — il che è peggio, non meglio. Opportunistico significa indiscriminato, e per l'edizione Free circola già un proof-of-concept pubblico. Ogni installazione raggiungibile da internet con una versione vulnerabile è un bersaglio.

Remediation

Considera qualsiasi sito che abbia avuto una versione vulnerabile raggiungibile da internet dopo metà luglio come forse già acceduto, non semplicemente esposto. Un login con asserzione forgiata lascia una sessione valida, non un crash — l'assenza di errori non è l'assenza di compromissione.

1. Sono interessato? Conferma il plugin e la sua esatta edizione/versione:

# Dalla root di WordPress
wp plugin get miniorange-saml-20-single-sign-on --field=version
# Oppure senza WP-CLI:
grep -i "Version:" wp-content/plugins/miniorange-saml-20-single-sign-on/*.php

Confronta il numero con la matrice delle edizioni qui sopra. Se non riesci a stabilire subito quale edizione hai licenziato, assumila vulnerabile finché non provi il contrario.

2. Patch — versioni corrette esatte. Aggiorna alla build corretta per la tua edizione (Free ≥ 5.4.5, Standard ≥ 17.0.6, Premium ≥ 13.0.4, Premium/Enterprise multisite ≥ 20.2.8, Enterprise single ≥ 26.0.3, VIP single ≥ 32.0.8, VIP multisite ≥ 35.0.7). Poiché i piani a pagamento sono stati corretti in silenzio, non aspettare un'email del vendor — scarica l'aggiornamento direttamente.

3. Non puoi patchare subito? — controlli compensativi.

• Metti l'endpoint Assertion Consumer Service (ACS) dell'SSO dietro una regola WAF che rifiuti le response SAML il cui algoritmo SignatureMethod non sia esattamente quello usato dal tuo IdP (blocca hmac-sha1 senza eccezioni — un IdP che firma davvero in RSA non lo invia mai).
• Applica un IP-allowlist a /wp-admin e all'endpoint ACS limitandolo agli intervalli di uscita aziendali. DigitalOcean ha intercettato l'attacco proprio perché la sessione admin arrivava da una rete non fidata.
• Se l'SSO non è in uso attivo, disattiva del tutto il plugin invece di lasciare un endpoint ACS dormiente e sfruttabile in ascolto.

4. Caccia alla compromissione. Il login forgiato è Forge Web Credentials: SAML Tokens (MITRE ATT&CK T1606.002), tipicamente seguito da Valid Accounts (T1078) e, per la persistenza, da Create Account (T1136) o da una web shell in un plugin/tema (T1505.003). Cerca:

• Login admin riusciti tramite il percorso SSO/ACS da indirizzi IP fuori dai tuoi range IdP o aziendali abituali — lo stesso segnale su cui ha reagito DigitalOcean.
• Response SAML nei log web che portano un algoritmo di firma HMAC-SHA1.
• Nuovi utenti con ruolo administrator, application password o chiavi API REST create poco dopo un login SSO anomalo.
• File modificati di recente o appena aggiunti sotto wp-content/ (plugin, mu-plugins, upload) — il classico drop di web shell post-autenticazione:

find wp-content -type f -name '*.php' -newermt '2026-07-01' \
  -exec grep -lE 'eval\(|base64_decode\(|assert\(|system\(|passthru\(' {} \;

5. Eradica + verifica. Se trovi un qualsiasi indicatore: prima patcha, poi rimuovi gli account admin abusivi e ogni web shell rilasciata, ruota tutte le password degli amministratori, revoca application password e chiavi API, e forza l'invalidazione delle sessioni attive (cambia i salt di autenticazione WordPress in wp-config.php). Solo dopo che il plugin è su una versione corretta la rotazione delle credenziali regge — ruotarle prima della patch significa solo riconsegnare la nuova sessione attraverso la stessa porta aperta.

Dove la validazione continua avrebbe chiuso la porta per prima

Il fatto scomodo di questo bug è che è invisibile a tutto ciò che si fida del login. Una volta che il plugin dice "valida", la sessione forgiata è indistinguibile da una reale — nessun picco di autenticazioni fallite, nessuna firma malware, nessun crash. Non lo trovi guardando la porta d'ingresso; lo trovi verificando se la porta d'ingresso può essere forzata prima che lo faccia un attaccante.

È la domanda operativa a cui è costruito per rispondere il pentest generativo a 10 agenti di Zero Hunt. Contro una superficie SSO, gli agenti Web e Credential non si limitano a rilevare una versione e associarla a una lista di CVE — generano un tentativo di exploit per-target: scaricano il certificato pubblico, costruiscono un'asserzione con algoritmo di firma degradato, la inviano e riportano se una sessione admin autenticata è davvero tornata indietro. È un reperto provato, firmato ECDSA al momento della scrittura, non una stima "sembra che tu usi una versione vulnerabile". Poiché le campagne sono change-triggered, nell'istante in cui un nuovo endpoint SSO compare sul perimetro — o arriva un aggiornamento del plugin — lo swarm lo rivalida entro l'ora, prima backtestato nell'AI Gym perché la tecnica sia nota-buona prima di toccare il tuo ambiente.

Due cose chiudono il cerchio. Il modello di AI Traffic Analysis copre il caso in cui la validazione è arrivata troppo tardi: le sue teste di inferenza segnalano la sessione admin anomala che arriva da un ASN mai visto — esattamente il segnale comportamentale su cui ha agito DigitalOcean — mentre sta accadendo, non nella revisione dei log del mattino dopo. E ogni reperto viene mappato automaticamente sui 32 framework di conformità, così "abbiamo dimostrato che il nostro SSO non poteva essere forgiato, in questa data, firmato" diventa evidenza d'audit per i requisiti di controllo degli accessi di NIS2 e ISO 27001, invece di uno screenshot in una slide. Una patch che nessuno ti ha detto di applicare è un rischio finché qualcosa di indipendente dalla mailing list del vendor non va a cercare. È questo il lavoro.