mirth-connect-security-poc

PoC funzionanti per tre vulnerabilità di NextGen Connect 4.5.2.

CVSS 3.1 e 4.0 sono standard diversi; i punteggi accoppiati non sono un confronto prima-e-dopo.

Tutti e tre sono stati riprodotti contro:

NextGen ha segnalato privatamente che il problema XSLT è stato corretto in 4.7.1 e i problemi di SQL injection e XML Batch sono stati corretti in 4.7.2. L'advisory CISA ICSMA-26-253-01 considera 4.7.1 e precedenti come affetti e raccomanda 4.7.2 o successivi. Le release successive alla 4.5 sono proprietarie, quindi non esiste un'immagine corretta pubblica dalla quale questo repository possa fornire lo stesso tipo di controllo negativo riproducibile usato per una release di patch open-source.

Cosa ottiene un attaccante

CVE-2026-82583: esposizione del database e dei segreti di integrazione

Un foothold autenticato sull'API amministrativa diventa accesso a dati che l'account non era destinato a esportare. L'exploit incluso scrive la riga attiva PERSON_PASSWORD sotto public_html e prova che il file risultante è scaricabile senza autenticazione. Il passaggio che conta è andare da un'azione API ristretta a un file su disco che non necessita più della sessione dell'attaccante.

In un ambiente di integrazione reale, il database può descrivere canali, endpoint e credenziali usate per raggiungere database, server SFTP, mail relay, API e altri sistemi clinici. Un test controllato separato ha recuperato una password di connettore deliberatamente inserita dall'XML del canale esportato. Questo rende la primitiva utile per la mappatura dell'ambiente e il furto di segreti; l'uso di qualsiasi credenziale recuperata contro un sistema a valle non è stato testato e non viene affermato.

Il braccio opzionale di denial-of-service blocca il database Derby incluso. Le chiamate API supportate da DB vanno quindi in timeout, la stessa iniezione non può sbloccare il proprio entrypoint, ed è richiesto un riavvio del processo. Questo è un onere di ripristino pratico per le installazioni supportate da Derby, non la prova che database di produzione esterni si comportino allo stesso modo.

CVE-2026-78224: divulgazione non autenticata di file del server e interruzione del canale

Una volta che un canale XSLT affetto è distribuito, l'attaccante non ha bisogno di alcun account Mirth. L' XML in ingresso fa sì che il servizio legga un file locale al target e ne invii il contenuto a una callback controllata dall'attaccante. Questo è utile anche quando la normale risposta del canale non contiene i dati trasformati e l'attaccante non può leggere la cronologia dei messaggi.

Il client standalone accetta un URI file: a riga singola scelto dal chiamante. File come identificatori host, token, frammenti di configurazione o credenziali sono praticamente preziosi se l'account del servizio Mirth può leggerli e il server può raggiungere la callback. La prova inclusa usa solo un canary generato e non rivendica il recupero universale di file arbitrari, il trasporto multilinea o l'accesso oltre l'account del servizio.

Un'entità esterna lenta occupa anche il canale vittima predefinito a singolo thread. Questo può ritardare o fermare la specifica interfaccia clinica mappata su quel canale fino al rilascio dell'entità. Il canale di controllo e l'API amministrativa rimangono sani, quindi questa è un'interruzione locale al canale piuttosto che un'interruzione dell'intero server.

CVE-2026-82578: esfiltrazione cieca di file tramite input batch

Quando una modalità batch XML affetta è abilitata, un mittente non autenticato può usare il corpo batch grezzo per innescare lo stesso tipo di divulgazione di file in uscita. Il server restituisce HTTP 500, ma l'attaccante ha già il contenuto del file solo-target attraverso la callback OOB. Questo rende la falla praticamente utile come percorso di esfiltrazione cieca anche quando un test basato solo sul codice di risposta liquiderebbe la richiesta come un errore del parser.

L'elaborazione batch è disattivata per impostazione predefinita, la modalità split deve raggiungere il parser supportato da XPath, ed è richiesta l'egress del server. Questo repository non rivendica un denial of service dimostrato per CVE-2026-82578.

Esecuzione

Requisiti: Bash, Docker, Linux x86-64 e accesso alla rete per il pull iniziale dell'immagine. Entrambe le immagini sono bloccate per digest. Nessuna porta host è pubblicata; il target e l'attaccante comunicano solo su un bridge Docker interno specifico per il task.

Oppure esegui un singolo finding:

Ogni invocazione crea container con nomi univoci e una rete bridge, registra evidence/current-run.log e rimuove le proprie risorse di laboratorio all'uscita. I file evidence/vulnerable-4.5.2.log versionati sono trascrizioni di una replica su Linux x86-64.

Cosa è e cosa non è rivendicato

• La SQL injection è dimostrata attraverso il vero entrypoint REST e il database Derby incluso. Il PoC esporta la riga attiva PERSON_PASSWORD e recupera il file senza autenticazione. Il suo braccio opzionale di laboratorio invoca SYSCS_FREEZE_DATABASE, dopodiché le chiamate API supportate da DB smettono di rispondere fino al riavvio del target.
• Il PoC XSLT usa una identity transform fissa, installata dall'amministratore. L' attaccante controlla solo il messaggio in ingresso non autenticato. I contenuti dei file tornano attraverso una callback DTD esterna. Il suo client standalone accetta un URI file: a riga singola locale al target; il wrapper di laboratorio usa un canary casuale e un'asserzione esatta. La stessa esecuzione prova l'indisponibilità locale al canale con un secondo canale sano e l'API admin, poi verifica il ripristino.
• Il PoC XML Batch abilita la normale modalità batch XML Element Name del prodotto. L'attaccante controlla solo il corpo batch non autenticato. Il suo client standalone ha la stessa modalità --file-uri e la stessa limitazione OOB a riga singola.
• Nessun prodotto sanitario a valle, cartella clinica o sistema di terze parti è stato testato. I riferimenti a possibili PHI o credenziali a valle descrivono conseguenze di deployment, non ulteriori vittime dimostrate.
• Il candidato del percorso di export nel checkout di ricerca è intenzionalmente assente. L' API è progettata per l'export lato server e il materiale fornito non ha provato una violazione portabile del confine di privilegio o una catena completa di esecuzione di codice.

Sicurezza

Esegui solo in un laboratorio usa-e-getta di tua proprietà. Il PoC SQL blocca deliberatamente il database target; il ripristino richiede il riavvio del target. I PoC XXE leggono un canary montato per impostazione predefinita, ma i loro client standalone accettano URL di listener arbitrari e URI di file locali al target a riga singola. Non indirizzarli mai verso sistemi senza autorizzazione.

Mitigazione

Secondo CISA, aggiorna a Connect 4.7.2 o successivo. Dove un aggiornamento immediato non è possibile, limita l'API amministrativa a reti di gestione fidate, rimuovi gli step XSLT non necessari, disabilita l'elaborazione batch XML dove non è richiesta e blocca l'egress non necessario del server. Queste misure riducono l'esposizione ma non riparano il codice vulnerabile.

Crediti

I finding 1 e 3 dovrebbero essere attribuiti ad Abhinav Agarwal. Il finding 2 è stato scoperto indipendentemente da Abhinav Agarwal e segnalato per la prima volta a NextGen da Youngdu. NextGen ha coordinato le correzioni e l'assegnazione dei CVE.

Uso difensivo previsto

Questo repository è pensato per aiutare i difensori a trasformare il testo di un advisory in comportamento osservabile e testabile. In una copia isolata di un ambiente, i difensori possono usarlo per:

• determinare se il comportamento pubblico della 4.5.2 è presente e comprendere gli esatti prerequisiti di configurazione;
• validare che i controlli del piano di gestione impediscano ad account non fidati di raggiungere l'operazione Database Connector;
• confermare che il filtraggio dell'egress blocca il percorso di callback XXE testato;
• costruire detection per richieste _getTables sospette, esportazioni Derby inattese o procedure di freeze, nuovi file sotto public_html, XML in ingresso contenente un DOCTYPE e callback originate da Mirth dopo errori del listener;
• dare priorità alla rotazione delle credenziali dei connettori quando un piano amministrativo affetto potrebbe essere stato compromesso; e
• rieseguire le stesse asserzioni contro una build corretta fornita dal vendor come controllo negativo locale, anche se quella build non può essere distribuita qui.

Ogni PoC viene eseguito in un container, blocca le proprie immagini per digest e fallisce in modo sicuro a meno che un canary casuale non ritorni. Un difensore può riprodurre l'effettivo confine di sicurezza piuttosto che prendere per fede uno screenshot o un numero di severità. Esiste per aiutare le persone a scoprire cosa stanno eseguendo, testarlo e confermare che una patch ha funzionato. Non è qui per essere puntato contro un ospedale.