j0xh-sec/CVE-2026-49009

▄█████ ██ ██ ██████ ████▄ ▄██▄ ████▄ ▄██▀▀▀ ██ ██ ▄█▀▀█▄ ▄██▄ ▄██▄ ▄█▀▀█▄ ██ ██▄▄██ ██▄▄ ▄▄▄ ▄██▀ ██ ██ ▄██▀ ██▄▄▄ ▄▄▄ ▀█████ ▀▀▀██ ██ ██ ██ ██ ▀▀▀██ ▀█████ ▀██▀ ██▄▄▄▄ ███▄▄ ▀██▀ ███▄▄ ▀█▄▄█▀ ██ ▄▄██▀ ▀██▀ ▀██▀ ▄▄██▀ ░█▄█░█▀▀░█▀█░█▀▄░█▀▀░█▀▄░░░█▀▀░█▀▀░█▀▄░█░█░█▀▀░█▀▄░░░█▀▄░█▀▀░█▀▀░ ░█░█░█▀▀░█░█░█░█░█▀▀░█▀▄░░░▀▀█░█▀▀░█▀▄░▀▄▀░█▀▀░█▀▄░░░█▀▄░█░░░█▀▀░ ░▀░▀░▀▀▀░▀░▀░▀▀░░▀▀▀░▀░▀░░░▀▀▀░▀▀▀░▀░▀░░▀░░▀▀▀░▀░▀░░░▀░▀░▀▀▀░▀▀▀░ ## Mender Server Authenticated Path Traversal to Remote Code Execution ! 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. - This repository is provided for educational and defensive security research only. - Do not run this against systems you do not own or do not have explicit permission to test. ## Affected Versions - **Vulnerable:** Mender Server **v4.1.0**, **v4.0.1 and below** - **Patched:** Mender Server **v4.1.1** and **v4.0.2** ## What Was the Vulnerability? 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. ## Attacker Prerequisites An attacker needed: - a valid authenticated Mender account - access to the **single-file** artifact generation workflow ## Exploit Path At a high level, the exploit chain worked like this: 1. I authenticated as a normal tenant user. 2. Submitted a single-file artifact generation request. 3. Supplied a malicious value that traversed out of the intended path and targeted `/usr/bin/mender-artifact`. 4. Uploaded a payload in place of the expected file content. 5. The worker wrote my payload to the targeted path. 6. The workflow later invoked `mender-artifact` during artifact generation. 7. The worker executed my payload, giving me command execution inside the backend worker. This mattered because the vulnerable write target was not just any file. It was a binary that the workflow immediately trusted and executed. ## What an Attacker Could Achieve A successful attacker could execute arbitrary commands inside the shared artifact generation worker. From there, the impact extended beyond a single request: - **persistent worker compromise:** one successful overwrite could affect later jobs handled by the same worker - **artifact pipeline abuse:** the attacker could tamper with artifact generation behavior - **secret exposure:** the attacker could access sensitive workflow context such as tokens or presigned URLs handled by backend jobs - **internal service exposure:** once inside the worker environment, the attacker gained a foothold inside the backend trust zone - **cross-tenant risk in shared deployments:** if worker infrastructure and workflow messaging were shared across tenants, one tenant’s compromise could affect other tenants’ artifact-generation jobs 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. ## Technical Root Cause 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** ## References - [Vendor advisory: CVE-2026-49009 – Improper input sanitization in Mender Server](https://mender.io/blog/cve-2026-49009-cve-2026-33552-input-sanitization-and-access-control-issues-in-mender-server) - [CVE-2026-49009 at CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-49009) - [Patch commit 484cc2a](https://github.com/mendersoftware/mender-server/commit/484cc2a13ad44d93cdf0f3c2ea9155b9bac4a969) ## Conclusion 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.