Dell System Update flaw gives root: move to DSU 2.3.0.0
CVE-2026-86360, a CVSS 9.6 path traversal in Dell System Update, can lead to root code execution. How to find DSU across a fleet and upgrade it.
By Yaali. October 6, 2026, 6 min read, Vulnerabilities, Patching.
Dell has fixed a critical path traversal flaw in Dell System Update (DSU), the command-line tool administrators use to push BIOS, firmware and driver updates to PowerEdge servers running Linux or Windows. The bug, CVE-2026-86360, is rated CVSS 9.6. Dell's advisory DSA-2026-324 says an unauthenticated attacker with remote access could use it to reach the file system and run arbitrary code with root privileges, which Dell describes as complete compromise of DSU and the operating system under it. Every DSU release before 2.3.0.0 is affected.
The advisory went out on October 1 and drew wider attention on October 5, when BleepingComputer and CSO Online covered it. Dell has not reported exploitation, and no public proof of concept has appeared. DSU tends to sit unnoticed on servers for years after the build that installed it, though, and it runs with the highest privileges on the box. If your PowerEdge estate uses DSU, find every copy and bring it to 2.3.0.0 before anyone publishes the details.

How it works
DSU reads a catalog, an index of Dell Update Packages (DUPs) that apply to a given server model, compares it with the installed inventory, then downloads and runs the packages that are newer. The catalog and packages come from Dell's online repository by default, or from a local mirror or file share that administrators point it at with --source-location. Because the packages flash BIOS and firmware, DSU runs as root on Linux and as an administrator on Windows.
A path traversal flaw means a program builds a file path from input it does not control and fails to strip sequences such as ../. The file then lands, or is read from, a directory outside the one the program meant to use. In a tool running as root, a write anywhere on the file system turns into code execution quickly: a file dropped into a cron directory, a systemd unit or a binary that runs later is enough.
Dell has not said which input DSU mishandles. The CVSS vector, AV:N/AC:L/PR:N/UI:R/S:C, gives three useful facts. The attack is over the network, needs no account on the target, and needs a user to do something, which in DSU's case most plausibly means an administrator or a scheduled job running it. Our reading, which Dell has not confirmed, is that the attacker controls content DSU fetches or processes during a run. The "changed scope" (S:C) part of the score means the impact reaches beyond DSU itself to the whole operating system.
The same advisory fixes four more DSU bugs. CVE-2026-86361 (incorrect permission assignment) and CVE-2026-86362 (improper access control), both CVSS 8.2, let a low-privileged local user escalate privileges. CVE-2026-63697, CVSS 7.6, is improper certificate validation that a highly privileged remote attacker could use for remote execution; weak certificate checks matter in an updater because they decide whether DSU can tell a real Dell repository from an impostor. CVE-2026-71168, CVSS 7.3, is a second path traversal open to low-privileged local users. Ori Gabriel reported CVE-2026-86360 and CVE-2026-63697.
What attackers are doing
Nothing has been reported so far. Dell's advisory does not mention exploitation, BleepingComputer reports none, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. Dell has not published the vulnerable code path, which buys some time, but a fixed 2.3.0.0 build is now public and patch diffing is how many of these bugs get reproduced.
What to do

1. Find every copy of DSU
On Linux, DSU installs as the dell-system-update package. rpm -q dell-system-update returns the installed version or says it is not installed, and dsu --version prints the tool's own version. Across a fleet, run that query through whatever you already use, for example ansible all -b -m command -a "rpm -q dell-system-update", and collect anything below 2.3.0.0.
On Windows, dsu --version works from an elevated prompt where DSU is on the path. For a fleet sweep, read the uninstall keys in PowerShell rather than relying on the path:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object { $_.DisplayName -like "*System Update*" -and $_.Publisher -like "*Dell*" } | Select-Object PSComputerName, DisplayName, DisplayVersion
Run it with Invoke-Command across your server list, or use the software inventory in Intune, Configuration Manager or your endpoint agent. Older releases were branded "Dell EMC System Update", which the wildcard above still matches. Check golden images, PXE build scripts and container or VM templates too, since an old DSU there comes back with every rebuild.
2. Upgrade to 2.3.0.0
Dell's only remediation is DSU 2.3.0.0 or later. On Red Hat family systems that already use Dell's repository (set up with bootstrap.cgi from linux.dell.com/repo/hardware/dsu/), yum update dell-system-update pulls it; on SUSE, zypper update dell-system-update. On Windows, download the DSU 2.3.0.0 package from Dell's support site and run it. Confirm afterwards with dsu --version.
3. Until every host is upgraded
Dell lists no workaround. Because the 9.6 flaw needs a user action, the practical way to cut exposure is to stop old DSU builds from running against anything you do not control:
- Pause scheduled or scripted DSU runs on hosts still below 2.3.0.0.
- Where a run cannot wait, point
--source-locationat an internal repository you built and checked, rather than an arbitrary share or URL. - Limit outbound traffic from server management networks so DSU can reach only Dell's repository or your mirror.
These steps reduce the chance that DSU processes hostile content. They do not fix the flaw.
4. Check hosts that ran old DSU builds
Dell has published no indicators. On servers where DSU ran from untrusted or unexpected sources, review what changed around those runs: new or modified files in /etc/cron.d, /etc/systemd/system and root's authorized_keys on Linux; new services, scheduled tasks and Run keys on Windows. Look through your scripts and job definitions for the --source-location values they pass, and confirm each one points somewhere you own. If you find a change nobody can explain, treat the host as compromised: rebuild it, and rotate the local administrator, iDRAC (Integrated Dell Remote Access Controller) and service account credentials it held.
The wider lesson
Update agents are easy to forget because they only run occasionally, yet each one is a privileged program that pulls content from the network and executes it. Keep them in the software inventory with the same version tracking as the operating system, and decide on purpose where each one is allowed to fetch from.
Our hardening work covers update tooling, repository trust and management network egress, and our network penetration tests check what an attacker on your internal network can reach and tamper with. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Dell DSA-2026-324, BleepingComputer, CSO Online, SecurityOnline, Dell System Update 2.0.1.0 User's Guide, DSU help, Dell Linux DSU repository.
Read next
- Apache httpd 2.4.69 fixes 20 flaws: what to patch first
- LibreOffice and OpenOffice spreadsheets that run Java code
- Atlassian CVE-2026-21589: file access across 8 DC products
Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.