
POC for CVE-2026-49009, an authenticated path traversal to RCE issue in Mender Server.
▄█████ ██ ██ ██████ ████▄ ▄██▄ ████▄ ▄██▀▀▀ ██ ██ ▄█▀▀█▄ ▄██▄ ▄██▄ ▄█▀▀█▄
██ ██▄▄██ ██▄▄ ▄▄▄ ▄██▀ ██ ██ ▄██▀ ██▄▄▄ ▄▄▄ ▀█████ ▀▀▀██ ██ ██ ██ ██ ▀▀▀██
▀█████ ▀██▀ ██▄▄▄▄ ███▄▄ ▀██▀ ███▄▄ ▀█▄▄█▀ ██ ▄▄██▀ ▀██▀ ▀██▀ ▄▄██▀
░█▄█░█▀▀░█▀█░█▀▄░█▀▀░█▀▄░░░█▀▀░█▀▀░█▀▄░█░█░█▀▀░█▀▄░░░█▀▄░█▀▀░█▀▀░
░█░█░█▀▀░█░█░█░█░█▀▀░█▀▄░░░▀▀█░█▀▀░█▀▄░▀▄▀░█▀▀░█▀▄░░░█▀▄░█░░░█▀▀░
░▀░▀░▀▀▀░▀░▀░▀▀░░▀▀▀░▀░▀░░░▀▀▀░▀▀▀░▀░▀░░▀░░▀▀▀░▀░▀░░░▀░▀░▀▀▀░▀▀▀░
I discovered and responsibly reported a critical vulnerability in Mender Server’s single-file artifact generation workflow. The issue started as an input sanitization and path traversal bug in the user-controlled args.filename field, but I showed that the bug did not stop at arbitrary file write. By targeting a worker-owned executable inside the artifact generation container, I escalated the issue into reliable remote code execution.
In practice, an authenticated attacker with access to artifact generation could overwrite /usr/bin/mender-artifact inside the create-artifact-worker. The workflow then invoked that same binary during normal artifact generation, which caused the attacker-controlled payload to execute.
This turned a traversal / arbitrary overwrite bug into a backend code execution issue in the artifact workflow.
The vulnerable workflow accepted attacker-controlled input in the single-file artifact generation flow and did not sufficiently constrain where the uploaded content would be written.
I found that I could control args.filename and abuse path traversal to write outside the intended destination. Instead of writing a normal artifact input file, I pointed the write target at /usr/bin/mender-artifact inside the worker container. Because the runtime user owned that binary in the vulnerable setup, the write succeeded.
The workflow later called mender-artifact as part of the artifact build process. Since I had already replaced that executable with my own payload, the worker executed attacker-controlled code.
An attacker needed:
At a high level, the exploit chain worked like this:
/usr/bin/mender-artifact.mender-artifact during artifact generation.This mattered because the vulnerable write target was not just any file. It was a binary that the workflow immediately trusted and executed.
A successful attacker could execute arbitrary commands inside the shared artifact generation worker.
From there, the impact extended beyond a single request:
In short, this was not just a file write bug. It was a code execution bug in a sensitive backend component that sat in the software delivery path.
HackerOne ultimately assessed the report as Critical and awarded a $3,000 bounty, which aligned with the practical impact demonstrated during validation.
The root cause was a trust boundary failure in the single-file artifact generation path.
The workflow trusted attacker-controlled path input too far into the backend processing chain. It allowed a user-influenced filename to escape its intended location and reach sensitive filesystem targets. The worker environment then amplified that mistake because it exposed executable paths that were writable by the runtime user and later executed by the workflow itself.
That combination created a clean exploit chain:
User-controlled path input → Arbitrary file overwrite → Overwrite trusted executable → Backend RCE
CVE-2026-49009 shows how a seemingly narrow input sanitization issue can become a full RCE chain when a trusted workflow writes attacker-controlled data to executable paths.
In the vulnerable versions, an authenticated attacker could turn the single-file artifact generation feature into a path traversal, arbitrary overwrite, and remote code execution chain. The patched versions blocked that path and restored the workflow to its intended behavior.