How a Path Traversal in an Update Client Turns a Downloaded File Into Root

Dell's October 2026 advisory for Dell System Update describes CVE-2026-86360 as a path traversalPath Traversal🛡️A web vulnerability (CWE-22) where user-supplied input in a file path escapes the directory the application intended to serve from, typically via parent-directory references, letting an attacker read or write files elsewhere on the server. that lets an unauthenticated remote attacker execute code as root on a PowerEdge server. That sentence packs two ideas together that are worth separating. Path traversal is a file-handling bug. Root code execution is the worst outcome a server can have. The distance between them is shorter than most people expect, and update clients are the category of software where it is shortest of all.

What an update client actually does

Strip away the vendor branding and every firmwareFirmware🏠Permanent software programmed into a device's hardware that controls its basic functions. or package update tool performs the same loop. It downloads a catalog, which is a structured list of available updates with names, versions, applicability rules and the locations of the actual payload files. It inventories the local machine to decide which entries apply. It downloads the matching payloads into a working directory. It then unpacks and executes them, which for firmware means handing them to a flashing utility and for drivers means installing files into system locations.

Three properties of that loop are fixed by the job itself and cannot be designed away. The tool must run with the highest privilege on the system, because flashing a BIOS or installing a kernel moduleKernel Module🛡️A piece of kernel code (driver, filesystem, protocol or crypto component) that is loaded into a running Linux kernel on demand rather than compiled in. Blocking a vulnerable module from loading is a common stopgap mitigation until a patched kernel can be booted. is impossible otherwise. The tool must write files to disk, because payloads arrive over the network and have to land somewhere before they run. And the tool must trust the names and paths that arrive inside the catalog and the payload archives, at least enough to decide where to put each file.

That third property is where traversal lives.

The traversal primitive

A path traversal vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. is any case where software builds a filesystem path from input it did not fully control and fails to confine the result to the directory it intended. The classic form is a filename containing parent-directory segments, so that a file the tool meant to write under its working directory resolves instead to a location several levels up. Archive extraction is the most common place to find it, because archive formats carry a path for every member and a naive extractor will honour whatever path is present. Catalogs that specify output locations for payloads are a second common site. Configuration files that name log or cache directories are a third.

In an ordinary application running as an unprivileged user, a traversal bug is serious but bounded. The attacker can write files, but only where that user can already write, and turning that into code execution takes extra work. In an update client, the bounds disappear. The process is root. Every directory on the system is writable. The attacker does not need to find a clever target; they need to pick one.

Why one root file write is enough

On a Linux server there are more root-owned locations that execute content automatically than most administrators can list from memory, and an attacker who can write a file anywhere needs only one of them. The scheduler directories that run scripts on a timer. The system service manager's unit directories, where a dropped unit file runs at the next reload or boot. The shell profile directories that execute for every login. The dynamic linker's preload configuration, which makes the loader inject an attacker's library into every new process. The authorised keys file for root's SSH login. The sudoers drop-in directory. Any of these turns a write into execution with no further vulnerability required, and some of them fire within minutes without waiting for a reboot. How an Arbitrary File WriteArbitrary File Write🛡️A vulnerability class in which an attacker controls both the contents and the destination path of a file written by a target system. On a general-purpose OS it is usually equivalent to code execution, because files written to certain locations are loaded or run automatically. Becomes Code Execution Through ld.so.preloadld.so.preload🛡️A Linux file read by the dynamic linker that lists shared libraries to load into every dynamically linked process before any other library. Designed for legitimate interposition, it is a favored persistence mechanism: writing a path into it forces attacker code to load into processes system-wide, including root-owned ones. covers one of those paths in detail.

Windows has the equivalent set: startup folders, scheduled task definitions, service binary paths, and the search order that lets a planted library shadow a legitimate one. The specifics differ; the principle does not. A file write as the most privileged account is code execution with a short delay.

This is why the CVSS vector for the Dell flaw carries a scope change. The vulnerable component is the update tool, but the thing that gets compromised is the operating system it runs on.

How the malicious content gets there

A traversal bug in an update client only matters if an attacker can influence what the client downloads, and that is the part of the Dell case that remains undisclosed. The CVSS vector says network attack, no privileges, user interaction required. Translated for a command-line tool with no listening port, that reads as: an administrator runs the tool, the tool fetches content, and the attacker controlled some of that content.

There are three realistic ways to achieve that, and defenders should assume all of them until a vendor rules them out.

The first is a hostile repository. Update tools typically let operators point at a custom source, whether a vendor-built mirror, a network share or an internal web server, so that servers do not need internet access. Anyone who can write to that source can write to every server that pulls from it. A compromised build host, a misconfigured share permission or a stale service accountService Account🛡️A non-human operating system or application account under which a service runs. Its permissions define the blast radius of any exploit against that service, since attacker code executes with the service account's access to files, secrets, and the network. with write access to the mirror becomes a fleet-wide root compromise on the next maintenance window.

The second is interception. If the tool fetches from the vendor over TLS but does not properly validate the certificate it is shown, an attacker on the network path can present their own certificate and serve their own catalog. Dell's advisory lists exactly this as a separate flaw in the same product, CVE-2026-63697, an improper certificate validation issue. A traversal bug and a certificate validation bug in the same download path are not two problems; they are one attack with two components.

The third is upstream compromise of the vendor itself. That is the hardest to pull off and the most damaging when it happens, and it is the reason signed catalogs and signed payloads exist. A traversal bug that fires before signature verification completes, or that lives in a code path the signature does not cover, defeats that protection.

What this means for defenders

The uncomfortable conclusion is that a firmware update tool deserves the same threat model as a remote administration agent, because functionally that is what it is: a root-privileged process that downloads and executes content from the network on a schedule you set. Three practical consequences follow.

Treat the update source as a tier-0 asset. Whatever your servers pull updates from, whether a vendor URL or an internal mirror, controls root on every server that pulls from it. Write access to that source should be as restricted as domain administrator credentials. How to Mirror a Vendor Firmware Repository So Servers Never Pull Updates From the Internet covers how to build a source you can actually control.

Keep the update client itself patched, which is harder than it sounds because these tools rarely announce their own updates and vendors rarely attach urgency to them. Dell shipped the fixed version of DSU in July 2026, labelled it Optional, and published the advisory in October. Why a Vendor's 'Optional' Update Label Tells You Nothing About Security takes that problem on directly.

Finally, run update tooling from controlled hosts on controlled networks. If a path traversal needs an administrator to run the tool against hostile content, the question is who can put hostile content in front of your administrators. A dedicated management host on a segment with no untrusted neighbours, fetching from a mirror that only a handful of people can modify, shrinks that answer to something you can audit.