CVE-2026-49009

    ▄█████ ██  ██ ██████    ████▄  ▄██▄ ████▄ ▄██▀▀▀    ██  ██ ▄█▀▀█▄  ▄██▄   ▄██▄ ▄█▀▀█▄
    ██     ██▄▄██ ██▄▄   ▄▄▄ ▄██▀ ██  ██ ▄██▀ ██▄▄▄ ▄▄▄ ▀█████  ▀▀▀██ ██  ██ ██  ██ ▀▀▀██
    ▀█████  ▀██▀  ██▄▄▄▄    ███▄▄  ▀██▀ ███▄▄ ▀█▄██▀        ██  ▄▄██▀  ▀██▀   ▀██▀  ▄▄██▀

            ░█▄█░█▀▀░█▀█░█▀▄░█▀▀░█▀▄░░░█▀▀░█▀▀░█▀▄░█░█░█▀▀░█▀▄░░░█▀▄░█▀▀░█▀▀░
            ░█░█░█▀▀░█░█░█░█░█▀▀░█▀▄░░░▀▀█░█▀▀░█▀▄░▀▄▀░█▀▀░█▀▄░░░█▀▄░█░░░█▀▀░
            ░▀░▀░▀▀▀░▀░▀░▀▀░░▀▀▀░▀░▀░░░▀▀▀░▀▀▀░▀░▀░░▀░░▀▀▀░▀░▀░░░▀░▀░▀▀▀░▀▀▀░

Mender Server Autenticato: Path Traversal verso Esecuzione Remota di Codice !

Ho scoperto e segnalato responsabilmente una vulnerabilità critica nel flusso di generazione di artefatti a file singolo di Mender Server. Il problema iniziava come un bug di sanitizzazione dell'input e path traversal nel campo args.filename controllato dall'utente, ma ho dimostrato che il bug non si fermava alla scrittura arbitraria di file. Puntando a un eseguibile di proprietà del worker all'interno del contenitore di generazione degli artefatti, ho escalation del problema in una esecuzione remota di codice affidabile.

In pratica, un utente autenticato con accesso alla generazione di artefatti potrebbe sovrascrivere /usr/bin/mender-artifact all'interno del create-artifact-worker. Il flusso di lavoro invocava poi quello stesso binario durante la normale generazione di artefatti, causando l'esecuzione del payload controllato dall'attaccante.

Questo ha trasformato un bug di traversal / sovrascrittura arbitraria in un problema di esecuzione di codice nel backend nel flusso di lavoro degli artefatti.

• Questo repository è fornito solo per scopi educativi e di ricerca difensiva sulla sicurezza.
• Non eseguirlo su sistemi di cui non sei proprietario o per cui non hai esplicita autorizzazione al test.

Versioni Affette

• Vulnerabile: Mender Server v4.1.0, v4.0.1 e precedenti
• Corretto: Mender Server v4.1.1 e v4.0.2

Qual era la Vulnerabilità?

Il flusso di lavoro vulnerabile accettava input controllato dall'attaccante nel flusso di generazione di artefatti a file singolo e non vincolava sufficientemente dove il contenuto caricato sarebbe stato scritto.

Ho scoperto che potevo controllare args.filename e abusare del path traversal per scrivere al di fuori della destinazione prevista. Invece di scrivere un normale file di input dell'artefatto, ho puntato la destinazione di scrittura a /usr/bin/mender-artifact all'interno del contenitore worker. Poiché l'utente runtime possedeva quel binario nella configurazione vulnerabile, la scrittura ha avuto successo.

Il flusso di lavoro in seguito chiamava mender-artifact come parte del processo di costruzione dell'artefatto. Poiché avevo già sostituito quell'eseguibile con il mio payload, il worker eseguiva codice controllato dall'attaccante.

Prerequisiti dell'Attaccante

Un attaccante necessitava di:

• un account Mender valido e autenticato
• accesso al flusso di lavoro di generazione di artefatti a file singolo

Percorso dello Sfruttamento

A livello generale, la catena di sfruttamento funzionava così:

1. Mi autenticavo come utente tenant normale.
2. Inviavo una richiesta di generazione di artefatto a file singolo.
3. Fornivo un valore malevolo che usciva dal percorso previsto e puntava a /usr/bin/mender-artifact.
4. Caricavo un payload al posto del contenuto del file previsto.
5. Il worker scriveva il mio payload nel percorso di destinazione.
6. Il flusso di lavoro in seguito invocava mender-artifact durante la generazione dell'artefatto.
7. Il worker eseguiva il mio payload, dandomi l'esecuzione di comandi all'interno del worker backend.

Questo era importante perché la destinazione di scrittura vulnerabile non era un file qualsiasi. Era un binario che il flusso di lavoro fidava immediatamente ed eseguiva.

Cosa Poteva Raggiungere un Attaccante

Un attaccante con successo poteva eseguire comandi arbitrari all'interno del worker di generazione artefatti condiviso.

Da lì, l'impatto si estendeva oltre una singola richiesta:

• compromissione persistente del worker: una singola sovrascrittura riuscita poteva influenzare i job successivi gestiti dallo stesso worker
• abuso della pipeline di artefatti: l'attaccante poteva alterare il comportamento di generazione degli artefatti
• esposizione di segreti: l'attaccante poteva accedere a contesto sensibile del flusso di lavoro come token o URL presigned gestiti dai job backend
• esposizione di servizi interni: una volta all'interno dell'ambiente worker, l'attaccante otteneva un punto d'appoggio all'interno della zona fidata del backend
• rischio cross-tenant in deployment condivisi: se l'infrastruttura worker e la messaggistica del flusso di lavoro erano condivise tra tenant, la compromissione di un tenant poteva influenzare i job di generazione artefatti di altri tenant

In breve, non era solo un bug di scrittura file. Era un bug di esecuzione di codice in un componente backend sensibile che si trovava nel percorso di distribuzione del software.

HackerOne ha infine valutato il report come Critico e ha assegnato una bounty di $3,000, in linea con l'impatto pratico dimostrato durante la validazione.

Causa Tecnica Principale

La causa principale era un fallimento del confine di fiducia nel percorso di generazione di artefatti a file singolo.

Il flusso di lavoro si fidava dell'input di percorso controllato dall'attaccante troppo a fondo nella catena di elaborazione backend. Permetteva a un nome file influenzato dall'utente di uscire dalla sua posizione prevista e raggiungere target sensibili del filesystem. L'ambiente worker amplificava poi quell'errore perché esponeva percorsi eseguibili che erano scrivibili dall'utente runtime e successivamente eseguiti dal flusso di lavoro stesso.

Quella combinazione creava una catena di sfruttamento pulita:

Input di percorso controllato dall'utente → Sovrascrittura arbitraria di file → Sovrascrittura di eseguibile fidato → RCE nel backend

Riferimenti

• Avviso del fornitore: CVE-2026-49009 – Sanitizzazione input impropria in Mender Server
• CVE-2026-49009 su CVE.org
• Commit patch 484cc2a

Conclusione

CVE-2026-49009 mostra come un'apparente ristretta questione di sanitizzazione dell'input possa diventare una catena completa di RCE quando un flusso di lavoro fidato scrive dati controllati dall'attaccante in percorsi eseguibili.

Nelle versioni vulnerabili, un attaccante autenticato poteva trasformare la funzione di generazione di artefatti a file singolo in una catena di path traversal, sovrascrittura arbitraria ed esecuzione remota di codice. Le versioni corrette hanno bloccato quel percorso e ripristinato il flusso di lavoro al comportamento previsto.