▄█████ ██ ██ ██████ ████▄ ▄██▄ ████▄ ▄██▀▀▀ ██ ██ ▄█▀▀█▄ ▄██▄ ▄██▄ ▄█▀▀█▄
██ ██▄▄██ ██▄▄ ▄▄▄ ▄██▀ ██ ██ ▄██▀ ██▄▄▄ ▄▄▄ ▀█████ ▀▀▀██ ██ ██ ██ ██ ▀▀▀██
▀█████ ▀██▀ ██▄▄▄▄ ███▄▄ ▀██▀ ███▄▄ ▀█▄▄█▀ ██ ▄▄██▀ ▀██▀ ▀██▀ ▄▄██▀
░█▄█░█▀▀░█▀█░█▀▄░█▀▀░█▀▄░░░█▀▀░█▀▀░█▀▄░█░█░█▀▀░█▀▄░░░█▀▄░█▀▀░█▀▀░
░█░█░█▀▀░█░█░█░█░█▀▀░█▀▄░░░▀▀█░█▀▀░█▀▄░▀▄▀░█▀▀░█▀▄░░░█▀▄░█░░░█▀▀░
░▀░▀░▀▀▀░▀░▀░▀▀░░▀▀▀░▀░▀░░░▀▀▀░▀▀▀░▀░▀░░▀░░▀▀▀░▀░▀░░░▀░▀░▀▀▀░▀▀▀░
我发现并负责任地报告了 Mender Server 单文件工件生成工作流中的一个严重漏洞。该问题最初是用户控制的 args.filename 字段中的输入清理和路径遍历漏洞，但我证明该漏洞并不止于任意文件写入。通过针对工件生成容器内的工作进程所拥有的可执行文件，我将该问题升级为可靠的远程代码执行。
实际上，拥有工件生成权限的认证攻击者可以覆盖 create-artifact-worker 中的 /usr/bin/mender-artifact。工作流随后在正常工件生成期间调用了同一个二进制文件，从而导致攻击者控制的有效负载被执行。
这将一个遍历/任意覆盖漏洞变成了工件工作流中的后端代码执行问题。
存在漏洞的工作流在单文件工件生成流程中接受了攻击者控制的输入，并且没有充分限制上传内容的写入位置。
我发现我可以控制 args.filename 并利用路径遍历写入预期目标之外。我没有写入正常的工件输入文件，而是将写入目标指向工作容器内的 /usr/bin/mender-artifact。由于运行时用户在易受攻击的设置中拥有该二进制文件的所有权，写入成功。
工作流后来在工件构建过程中调用了 mender-artifact。由于我已经用我自己的有效负载替换了该可执行文件，工作进程执行了攻击者控制的代码。
攻击者需要：
从高层次来看，利用链的工作方式如下：
/usr/bin/mender-artifact。mender-artifact。这很重要，因为易受攻击的写入目标不仅仅是任何文件。它是一个工作流立即信任并执行的二进制文件。
成功的攻击者可以在共享的工件生成工作进程中执行任意命令。
从那里开始，影响超出了单个请求：
简而言之，这不仅仅是一个文件写入漏洞。这是一个位于软件交付路径上的敏感后端组件中的代码执行漏洞。
HackerOne 最终将报告评估为 严重，并给予了 $3,000 的赏金，这与验证期间展示的实际影响相符。
根因是单文件工件生成路径中的信任边界失效。
工作流对攻击者控制的路径输入过于信任，将其传递到后端处理链的深处。它允许受用户影响的文件名逃脱其预期位置并到达敏感的文件系统目标。工作进程环境随后放大了这一错误，因为它暴露了可由运行时用户写入且后续由工作流自身执行的可执行路径。
这种组合创建了一条清晰的利用链：
用户控制的路径输入 → 任意文件覆盖 → 覆盖受信任的可执行文件 → 后端 RCE
CVE-2026-49009 展示了当一个受信任的工作流将攻击者控制的数据写入可执行路径时，一个看似狭窄的输入清理问题如何演变成完整的 RCE 链。
在受影响版本中，认证攻击者可以将单文件工件生成功能变成路径遍历、任意覆盖和远程代码执行链。已修复版本阻止了该路径，并将工作流恢复为其预期行为。