CVE-2026-49009

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

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

Mender Server : Contournement de chemin authentifié menant à l'exécution de code à distance !

J'ai découvert et signalé de manière responsable une vulnérabilité critique dans le workflow de génération d'artefacts à fichier unique du serveur Mender. Le problème a commencé comme un bogue de validation d'entrée et de contournement de chemin dans le champ args.filename contrôlé par l'utilisateur, mais j'ai montré que le bogue ne s'arrêtait pas à l'écriture arbitraire de fichiers. En ciblant un exécutable appartenant au worker à l'intérieur du conteneur de génération d'artefacts, j'ai transformé le problème en une exécution de code à distance fiable.

En pratique, un attaquant authentifié ayant accès à la génération d'artefacts pouvait écraser /usr/bin/mender-artifact à l'intérieur du create-artifact-worker. Le workflow invoquait alors ce même binaire lors de la génération normale d'artefacts, ce qui entraînait l'exécution de la charge utile contrôlée par l'attaquant.

Cela a transformé un bogue de contournement / écrasement arbitraire en un problème d'exécution de code backend dans le workflow d'artefacts.

• Ce dépôt est fourni à des fins de recherche défensive et éducative uniquement.
• N'exécutez pas ceci contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester.

Versions concernées

• Vulnérables : Mender Server v4.1.0, v4.0.1 et versions antérieures
• Corrigées : Mender Server v4.1.1 et v4.0.2

Quelle était la vulnérabilité ?

Le workflow vulnérable acceptait une entrée contrôlée par l'attaquant dans le flux de génération d'artefacts à fichier unique et ne contraignait pas suffisamment l'endroit où le contenu téléchargé serait écrit.

J'ai découvert que je pouvais contrôler args.filename et abuser du contournement de chemin pour écrire en dehors de la destination prévue. Au lieu d'écrire un fichier d'entrée d'artefact normal, j'ai pointé la cible d'écriture vers /usr/bin/mender-artifact à l'intérieur du conteneur du worker. Étant donné que l'utilisateur d'exécution possédait ce binaire dans la configuration vulnérable, l'écriture a réussi.

Le workflow appelait ensuite mender-artifact dans le cadre du processus de construction de l'artefact. Comme j'avais déjà remplacé cet exécutable par ma propre charge utile, le worker a exécuté le code contrôlé par l'attaquant.

Prérequis de l'attaquant

Un attaquant avait besoin :

• d'un compte Mender authentifié valide
• d'un accès au workflow de génération d'artefacts à fichier unique

Chemin d'exploitation

À un niveau élevé, la chaîne d'exploitation fonctionnait ainsi :

1. Je me suis authentifié en tant qu'utilisateur normal d'un locataire.
2. J'ai soumis une demande de génération d'artefact à fichier unique.
3. J'ai fourni une valeur malveillante qui sortait du chemin prévu et ciblait /usr/bin/mender-artifact.
4. J'ai téléchargé une charge utile à la place du contenu de fichier attendu.
5. Le worker a écrit ma charge utile dans le chemin ciblé.
6. Le workflow a ensuite invoqué mender-artifact lors de la génération de l'artefact.
7. Le worker a exécuté ma charge utile, me donnant l'exécution de commandes à l'intérieur du worker backend.

Cela importait car la cible d'écriture vulnérable n'était pas un fichier quelconque. C'était un binaire que le workflow faisait immédiatement confiance et exécutait.

Ce qu'un attaquant pouvait accomplir

Un attaquant réussi pouvait exécuter des commandes arbitraires à l'intérieur du worker de génération d'artefacts partagé.

À partir de là, l'impact s'étendait au-delà d'une seule requête :

• compromission persistante du worker : un seul écrasement réussi pouvait affecter les travaux ultérieurs traités par le même worker
• abus du pipeline d'artefacts : l'attaquant pouvait altérer le comportement de génération d'artefacts
• exposition de secrets : l'attaquant pouvait accéder à des informations sensibles du workflow, telles que des jetons ou des URL pré-signées manipulées par les travaux backend
• exposition des services internes : une fois à l'intérieur de l'environnement du worker, l'attaquant obtenait un point d'appui dans la zone de confiance du backend
• risque inter-locataires dans les déploiements partagés : si l'infrastructure des workers et la messagerie des workflows étaient partagées entre locataires, la compromission d'un locataire pouvait affecter les travaux de génération d'artefacts d'autres locataires

En bref, ce n'était pas seulement un bogue d'écriture de fichier. C'était un bogue d'exécution de code dans un composant backend sensible qui se trouvait dans le chemin de livraison logicielle.

HackerOne a finalement évalué le rapport comme Critique et a attribué une prime de 3 000 $, ce qui correspondait à l'impact pratique démontré lors de la validation.

Cause racine technique

La cause racine était une défaillance de la frontière de confiance dans le chemin de génération d'artefacts à fichier unique.

Le workflow faisait trop confiance à l'entrée de chemin contrôlée par l'attaquant dans la chaîne de traitement backend. Il permettait à un nom de fichier influencé par l'utilisateur de s'échapper de son emplacement prévu et d'atteindre des cibles sensibles du système de fichiers. L'environnement du worker amplifiait ensuite cette erreur car il exposait des chemins exécutables qui étaient inscriptibles par l'utilisateur d'exécution et exécutés ultérieurement par le workflow lui-même.

Cette combinaison créait une chaîne d'exploitation propre :

Entrée de chemin contrôlée par l'utilisateur → Écriture arbitraire de fichier → Écriture d'un exécutable de confiance → RCE backend

Références

• Avis du fournisseur : CVE-2026-49009 – Nettoyage d'entrée inadéquat dans Mender Server
• CVE-2026-49009 sur CVE.org
• Commit de correctif 484cc2a

Conclusion

CVE-2026-49009 montre comment un problème apparemment limité de nettoyage d'entrée peut devenir une chaîne RCE complète lorsqu'un workflow de confiance écrit des données contrôlées par l'attaquant dans des chemins exécutables.

Dans les versions vulnérables, un attaquant authentifié pouvait transformer la fonctionnalité de génération d'artefacts à fichier unique en une chaîne de contournement de chemin, d'écrasement arbitraire et d'exécution de code à distance. Les versions corrigées ont bloqué ce chemin et rétabli le workflow à son comportement prévu.