Ubuntu 26.10 Ships Rust Coreutils: What Changes for cp, mv and rm
Ubuntu 26.10 moves the last three core file commands to a Rust rewrite. Here is what that means on day two for people who run Ubuntu machines.
In this article 7 sections
Ubuntu 26.10 ships Rust coreutils as its default, replacing the last three GNU file commands: cp, mv and rm. The new tools come from the uutils project and aim to behave like the old ones. For most servers nothing visible changes, but scripts that lean on rare flags deserve a test run before the upgrade.
This explainer covers what moved, why Canonical waited until now for the riskiest commands, and what the audits found. It is written for sysadmins, platform engineers and anyone who owns an Ubuntu fleet. Protocol Wire covers platform shifts like this one with a focus on what breaks first and who gets paged.
What Does Rust Coreutils Actually Replace in Ubuntu 26.10?
The change replaces the GNU implementations of cp, mv and rm with uutils coreutils, a Rust reimplementation of the same commands. Other tools such as ls, cat, chmod and du already made the switch. With this release, the default stack no longer depends on GNU for the core file commands.
Coreutils are the small programs every shell script touches. They copy files, move them, list them and delete them. When you run a backup job at 2 a.m., these commands do the work. That is why a swap here gets more attention than a new desktop theme.
According to It's FOSS reporting on the migration, the change shows up only as a brief mention in Canonical's work-in-progress 26.10 release notes. The quiet notice hides how large the shift is. Ubuntu 26.10 is an interim release with nine months of support, and it also brings Linux kernel 7.3 and GNOME 51, as Linuxiac reported.
The uutils project describes itself as a drop-in replacement for GNU coreutils. Its GitHub repository says the team treats any difference from GNU behavior as a bug. The code uses the MIT license, while GNU coreutils uses GPL 3.0 or later.
Why Did Canonical Wait Until 26.10 for cp, mv and rm?
Canonical held back cp, mv and rm from the 26.04 LTS release because of time-of-check to time-of-use (TOCTOU) problems and other flaws in the uutils versions. A TOCTOU bug happens when a program checks a file and then acts on it, while an attacker changes the file in between.
Those three commands are the riskiest ones. They write, overwrite and delete data. A bug in ls wastes a minute. A bug in rm can wipe a directory that should have survived.
The timeline shows how cautious the rollout was. Ubuntu 25.10 was the first release to ship uutils by default, and it also made sudo-rs the default privilege tool. The long-term support release in April 2026 kept GNU versions of the three risky commands. The 26.10 release is where they finally moved.
There was also a stumble along the way. In July, the uutils cp command was added to the Ubuntu archive and then removed after it broke live image builds. The developers marked the fix "Critical," and cp returned shortly after. That episode is a good reminder of why interim releases exist. They let a distribution find these problems before they reach a long-term support channel.
In my view, this staged approach is the right call. Releasing the safe commands first built a track record. It also gave Canonical time to pay for outside review.
What Did the Security Audits Find?
Canonical commissioned two rounds of security audits from the firm Zellic between December 2025 and March 2026. Zellic raised 113 issues across both rounds, and 44 of them received CVE identifiers. Canonical says most have since been resolved, according to It's FOSS.
A CVE is a public identifier for a specific security flaw, so 44 of them sounds alarming. It deserves context. Audits exist to find bugs, and a young codebase will have plenty. A long-lived project like GNU coreutils also accumulated its own list of flaws over decades, mostly fixed long ago.
The useful question is not whether Rust code has bugs. It does. The question is what kind of bugs. Memory-safety errors, such as buffer overflows, are far less likely in safe Rust. Logic errors, such as the TOCTOU issues above, are not prevented by the language at all.
Here is how the tradeoff looks at a glance.
| Factor | GNU coreutils | uutils (Rust) |
|---|---|---|
| Language | C | Rust |
| License | GPL 3.0 or later | MIT |
| Maturity | Decades of production use | Young, audited in 2025 and 2026 |
| Memory-safety bugs | Possible by design of C | Far less likely in safe Rust |
| Behavior differences | The reference | Treated as bugs, but some remain |
The table shows why the debate stays heated. Neither side wins on every row. Canonical is betting that the memory-safety gain outweighs the maturity gap, and the audits are how it hedges that bet.
How Do You Prepare Your Servers for the Switch?
Start by testing your scripts on a staging machine that runs Ubuntu 26.10. Pay special attention to anything that calls cp, mv or rm with unusual flags. If a script behaves differently, you can install the coreutils-from-gnu package to restore the GNU tools while you investigate.
Here is a short checklist for the first week after upgrade.
- Search your repositories for scripts that call cp, mv or rm with long or rare options.
- Run those scripts on a staging box and diff the results against a GNU baseline.
- Watch backup and deploy jobs closely on the first nightly run.
- Keep the coreutils-from-gnu package ready as a rollback.
Anyone who has watched enough migrations knows the pattern. The failure is rarely in the main path. It hides in the cleanup script nobody has touched in four years, which uses a flag that behaves a little differently now.
The same lesson shows up in other infrastructure stories. Our look at the AWS Bahrain outage and regional redundancy found that plans fail where nobody tested them. Package swaps follow the same rule. If you have not run the script, you do not know what it does.
Fleet owners should also decide whether the upgrade is worth taking at all. Interim releases get nine months of support. Many teams stay on the long-term release and watch how 26.10 performs in the wild before adopting the Rust tools.
What Comes After Coreutils for Ubuntu's Rust Push?
The next target is ntpd-rs, a Rust rewrite of Ubuntu's clock synchronization tools. It is already available for testing, and Canonical has set it as the default for Ubuntu 27.04. Canonical also became a Gold Sponsor of the Trifecta Tech Foundation, contributing 40,000 euros per year to memory-safe system software.
That sponsorship matters for governance. Open source projects live or die by who pays for the boring work. A distribution that funds the maintainers of its own default tools reduces the risk that the code stalls after the headlines fade.
It also connects to a wider pattern in open source. Packaging and shipping software reliably is a harder problem than writing it, which is the same theme behind the Mozilla and Mila effort to package open source AI for production. A good project needs a funded path from repository to server.
Trust in the toolchain also has a security side. When your build and deploy scripts depend on tools you did not write, the supply chain matters. Our explainer on how GhostJacking targets AI coding agents shows how attackers go after the tools people already trust.
Who Should Upgrade to Ubuntu 26.10 Now, and Who Should Wait?
Developers and desktop users are the natural early adopters. They run short scripts, they notice quirks quickly, and a broken command costs them a few minutes. Interim releases also suit teams that already rebuild machines often and keep configuration in version control.
Operators of long-lived servers have less reason to rush. A production host that runs payroll exports or database backups does not benefit from a new default tool on day one. The long-term support line gives those teams a calmer path, and the Rust tools will have more miles on them by then.
There is also a middle option. Run one canary machine on 26.10, point a copy of your nightly jobs at it, and compare the logs for a week. That costs almost nothing and turns a vague worry into a concrete answer. If the logs match, you gain confidence. If they differ, you learn exactly which flag to fix.
Whichever path you pick, write the decision down. Note which release you chose, which package version of the coreutils you run, and who owns the rollback. The next engineer to inherit the fleet will thank you.
What Should You Do Next?
The practical answer is simple. Do not panic, and do not ignore it. Treat the move to Rust coreutils as a normal package change that needs a test pass. At Protocol Wire, our editors rate it low risk for most fleets and moderate risk for anyone with old, flag-heavy scripts.
Plan the test first, then the upgrade, then the rollback. Keep the GNU package one command away. Within a release or two, the Rust tools will probably feel as boring as the old ones, and boring is exactly what you want from cp, mv and rm.
