Ubuntu USN-7604-1 fixed two Sudo vulnerabilities, CVE-2025-32462 and CVE-2025-32463. For a small server operator, the practical response is not panic; it is to confirm whether the server runs an affected Ubuntu release, apply the fixed package through normal updates, and treat local shell access as the main exposure question.
The important detail is scope. These were Sudo issues, which matters because Sudo controls privileged actions, but Ubuntu describes the abuse path in terms of local attackers and specific sudoers configurations.
What did Ubuntu fix in USN-7604-1?
Ubuntu says USN-7604-1 fixed several security issues in the sudo package across Ubuntu 25.04, 24.10, 24.04 LTS, and 22.04 LTS. The notice covers the host-option issue CVE-2025-32462 and the chroot-option issue CVE-2025-32463.
The host-option issue matters where per-host rules are configured in sudoers. The chroot-option issue matters where sudoers is configured to allow the chroot option; Ubuntu notes that this second issue applied to Ubuntu 24.04 LTS, 24.10, and 25.04.
That distinction is why a good triage does not stop at “Sudo vulnerability.” Ask which release, which package version, and whether your server gives untrusted users local accounts.
Which Ubuntu releases were listed?
USN-7604-1 lists supported fixes for these releases and package versions:
| Ubuntu release | Fixed sudo package version listed by Ubuntu |
|---|---|
| 25.04 | 1.9.16p2-1ubuntu1.1 |
| 24.10 | 1.9.15p5-3ubuntu5.24.10.1 |
| 24.04 LTS | 1.9.15p5-3ubuntu5.24.04.1 |
| 22.04 LTS | 1.9.9-1ubuntu2.5 |
If you run Ubuntu Pro/ESM or a nonstandard package source, check Ubuntu’s current notice and package page before assuming this table is the whole story. Security notices can receive related updates.
Is this remotely exploitable over SSH?
Not by itself in the way an unauthenticated network service bug is. Ubuntu’s descriptions are about a local attacker abusing Sudo behavior under certain configurations.
That still matters for servers. A “local attacker” may be a compromised application account, a shared shell user, a developer account that should not be able to become root, or a low-privilege user created for automation. On a single-user VPS with no untrusted local accounts, the urgency is different from a multi-user box.
Do not turn that into complacency. Sudo is part of the privilege boundary, so security updates should be applied promptly even when the exposure path is narrower than a public remote-code-execution bug.
What should a small-server operator do first?
Start with normal update hygiene. Ubuntu’s notice says a standard system update will generally make the necessary changes.
A reasonable triage order is:
- Identify whether the server is Ubuntu 22.04 LTS, 24.04 LTS, 24.10, or 25.04.
- Apply normal security updates from trusted Ubuntu repositories.
- Confirm the installed
sudopackage matches or exceeds the fixed version for that release. - Review whether untrusted users have local shell access.
- Review unusual
sudoersrules, especially host-specific or chroot-related entries. - Record the maintenance action in your server notes.
If SSH access is fragile, do not make broad access changes at the same time as patching. Patch first, keep a console or recovery path available, and review access policy after the package is fixed.
What not to do
Do not copy exploit snippets into production to “see if you are vulnerable.” You do not need exploit testing to follow a vendor security notice.
Do not assume that hiding SSH on a nonstandard port changes the local-user risk. Port changes can reduce log noise, but they do not fix privilege escalation once a user is already on the system.
Do not treat one Sudo notice as the whole security program. Pair patching with a CISA KEV triage habit, a small business server security review checklist, and a small VPS exposure audit.
FAQ
Was every Ubuntu server equally at risk?
No. The listed releases needed package fixes, but practical exposure depends on local-user access and sudoers configuration. Patch anyway; prioritize deeper review where untrusted users or complex Sudo policy exist.
Should I reboot after updating Sudo?
A Sudo package update does not usually imply the same reboot requirement as a kernel update. Still, check your normal maintenance tools for pending service restarts or reboot requirements instead of guessing.
Should I remove Sudo?
Usually no. Removing Sudo can break normal administration. Update it, review who can use it, and keep privileged access deliberate.
Sources
- Ubuntu Security Notice USN-7604-1: Sudo vulnerabilities
- Ubuntu CVE pages for CVE-2025-32462 and CVE-2025-32463
- TheLinuxForum secure server review and exposure-audit cluster