CVE-2026-18379: Yggdrasil-worker-package-manager: yggdrasil-worker-package-manager: path traversal via unsanitized repo name in addrepo/removerepo
=AddRepo()= and =RemoveRepo()= (=packagemanagerdnf.go:22-37=) build the destination path with =filepath.Join("/etc/yum.repos.d/", canonicalizeRepoName(name, ".repo"))=. =canonicalizeRepoName()= (=util.go:13-15=) only replaces spaces with underscores and appends a =.repo= suffix — it never strips =/= or =..=. Because =filepath.Join= calls =filepath.Clean= internally, a broker-supplied =name= such as =../../etc/cron.d/evil= resolves outside =/etc/yum.repos.d/=, letting =os.WriteFile= write attacker-controlled content to any root-writable path ending in =.repo=, and =RemoveRepo='s =os.Remove= delete any such path. Neither function is gated by the =allowPatterns= allowlist. The worker's systemd unit runs =User=root=.
Other sources
A flaw was found in yggdrasil-worker-package-manager. An authenticated attacker can exploit this issue to achieve arbitrary file modification or potential privilege escalation. The vulnerability exists because repository management operations fail to sanitize directory traversal sequences (such as '../') within repository names. By supplying a crafted repository name, an attacker can manipulate the root-level worker process into creating or deleting files outside the intended directory, compromising host system integrity.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated attacker who can supply repository-management requests to the worker can exploit it. The affected AddRepo and RemoveRepo operations accept a broker-supplied repository name.
Does the repository-name allowlist prevent exploitation?
No. AddRepo and RemoveRepo are not gated by the allowPatterns allowlist, so it does not restrict crafted repository names used through these operations.
What level of access can exploitation provide?
The worker runs as root, and a crafted name can cause creation or deletion of files outside /etc/yum.repos.d/ when the target path ends in .repo. This enables arbitrary root-level file modification within that constraint and may lead to privilege escalation.
How can I determine whether this vulnerability may have been exploited?
Review repository-management requests and filesystem activity for repository names containing traversal sequences such as ../. Investigate unexpected .repo files or deletions outside /etc/yum.repos.d/, especially in root-writable locations.