Hackers are actively exploiting a critical vulnerability (CVE-2025-32463) in the sudo package that enables the execution of commands with root-level privileges on Linux operating systems.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added this vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, describing it as "an inclusion of functionality from untrusted control sphere."
CISA has given federal agencies until October 20 to apply the official mitigations or discontinue the use of sudo.
A local attacker can exploit this flaw to escalate privileges by using the -R (--chroot) option, even if they are not included in the sudoers list, a configuration file that specifies which users or groups are authorized to execute commands with elevated permissions.
Sudo ("superuser do") allows system administrators to delegate their authority to certain unprivileged users while logging the executed commands and their arguments.
Officially disclosed on June 30, CVE-2025-32463 affects sudo versions 1.9.14 through 1.9.17 and has received a critical severity score of 9.3 out of 10.
"An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file," explains the security advisory.
Rich Mirch, a researcher at cybersecurity services company Stratascale who discovered CVE-2025-32463, noted that the issue impacts the default sudo configuration and can be exploited without any predefined rules for the user.
On July 4, Mirch released a proof-of-concept exploit for the CVE-2025-32463 flaw, which has existed since June 2023 with the release of version 1.9.14.
However, additional exploits have circulated publicly since July 1, likely derived from the technical write-up.
CISA has warned that the CVE-2025-32463 vulnerability in sudo is being exploited in real-world attacks, although the agency has not specified the types of incidents in which it has been leveraged.
Organizations worldwide are advised to use CISA's Known Exploited Vulnerabilities catalog as a reference for prioritizing patching and implementing other security mitigations.
(Score: 5, Insightful) by epitaxial on Friday October 03, @06:50PM (10 children)
I simply su like a real man.
(Score: 5, Insightful) by bloodnok on Friday October 03, @07:47PM (6 children)
Me too.
Almost all of the uses of sudo that I see described in various forums strike me as an indication of poor security setups.
Sudo is great if you want to allow certain users to run a small set of very specific commands but allowing even a small set of users to run any command they like as root cannot be good security practice. It means that the security of the root account is now the lowest common denominator of the security of all of those users that are allowed to use sudo. To put it another way it increases the size of the attack surface: now an attacker can compromise any sudo user's account rather than having to concentrate on the root account.
Too many distributions set up sudo simply so that users do not need to know the root password. While this is very convenient for those users, it lessens their security.
For an example take a look at sshd (the daemon that runs the ssh service). Most distributions provide sshd with a configuration file that prevents directly logging in as root. This is a good thing. It clearly improves the security of your system. But given that many users can run any root command they like, sudo completely bypasses this small piece of good security practice.
If I need to remotely log in as root on any of my hosts, I ssh into my account and then su into root. For this I need my password (or appropriate certificates) and the root password. This is much more secure than just requiring just my password (or certs).
This (IMHO) poor practice is so prevalent that it is rare to find any installation instructions that don't suggest that you run almost everything using sudo.
And to those that say, ah but its audited, I'd ask whether you actually check that audit trail, and how much auditing is going to help when someone does:
The very worst thing of all is when installation tools simply refuse to work without sudo. Such tools do not merely accept poor security practice, they practically demand it. I wish a mildly unpleasant time on all developers of such things.
__
the Major
(Score: 2, Interesting) by shrewdsheep on Friday October 03, @09:23PM (2 children)
Very good points. Virtually all my machines are under ansible control which requires password-less root access using ssh. This makes the controlling machine a real Achilles heel of my setup which is a nagging feeling (I do find my night's sleep though). A much finer grained security model would be welcome.
(Score: 3, Informative) by RS3 on Saturday October 04, @02:46PM (1 child)
I've looked at but never tried ansible. So take this as sort of guessing out loud:
"password-less root access using ssh"
There isn't some kind of authentication mechanism available? Maybe key pairs?
https://docs.ansible.com/ansible/latest/inventory_guide/connection_details.html [ansible.com]
(Score: 4, Interesting) by VLM on Saturday October 04, @04:02PM
That's how I used to do it. Guessing thats what shrewdsheep meant by no password. Not literally hit the enter key at the password prompt but the ansible hosts ~/.ssh/id_rsa is in the remote hosts's /root/.ssh/authorized_keys No typing in a password just use SSH key-based authentication.
The way I run it personally is most systems demand you configure a local user at install, I create "ansible" user on the remote, then do SSH login from ansible@ansible on the ansible controller host. This means essentially everything Ansible does makes it have to "become:" root which wastes time and giving the remote ansible user full sudo privs means you're better off not creating an additional point of attack because its just root under a different name, so just log in as root and skip all the theater. OTOH, someone trying to break in can't log in as root regardless what password they try because I have no root password you can't log in as root over ssh, so there is some minor security gain. But its VERY small gain for something mostly theatrical.
(Score: 5, Interesting) by VLM on Saturday October 04, @02:31PM (1 child)
More than you might think. Check out "sudoreplay" and the LOG_OUTPUT options
https://www.sudo.ws/docs/man/1.8.14/sudoers.man/ [www.sudo.ws]
https://www.sudo.ws/docs/man/1.8.13/sudoreplay.man/ [www.sudo.ws]
"Ah I'll just delete the local logs" then look at logsrvd LOL
https://www.sudo.ws/docs/man/sudo_logsrvd.man/ [www.sudo.ws]
"OK then I'll change the local sudo config" Uh huh:
https://www.sudo.ws/docs/man/1.8.17/sudoers.ldap.man/ [www.sudo.ws]
There's a lot going on in sudo. More than you seem to think.
As a final comment you can run "sudo -i" instead of "sudo su -" thats (insert hand waving) the same thing.
https://www.sudo.ws/docs/man/sudo.man/ [www.sudo.ws]
(Score: 2) by bloodnok on Saturday October 04, @08:42PM
Interesting, thanks.
I guess my sudo installation is borked 'cos:
I don't think this is something that I broke. The only thing I've ever done with sudo was edit the sudoers file to prevent anyone other than root from using it. I'll take your word that the auditing should work though.
Auditing aside, I still reckon letting any command be used by sudoers is a terrible idea.
__
the Major
(Score: 3, Insightful) by aafcac on Sunday October 05, @07:45PM
There's also doas which uses a lot less code and covers most of the uses that sudo has. I think sudo as a way of executing as a different non-root user isn't so bad. Sometimes you do want to give a user the ability to do something, but want them to take a moment to consider whether or not it's a wise idea. I do sort of get that theoretically sudo is a measure between handing over root and giving no privileges at all, but as a practical matter when sudo isn't configured to just handle a limited number of things because there is no root password provided, that becomes a massive problem. And really, most of what sudo does could be handled in other ways.
As used sudo is just fundamentally a bad idea. Maybe it's because I came from FreeBSD and am currently using Linux mainly as a convenience due to a lack of decent alternative to Crashplan, but the whole idea of switching to root every 5 seconds has always seemed weird to me. Root is for certain things like updating system binaries, changing system settings and things of that nature. And those things shouldn't need to happen as often as they do on Linux.
Sudo strikes me as largely the same nonsense as you see with Windows where they pop up the access control and you can click through it if you've got the privileges.
(Score: 3, Funny) by turgid on Friday October 03, @08:21PM (2 children)
Well, yes. And when I have to use Ubuntu or similar, I just sudo su. It's been pretty clear over the last 15-20 years online that many people have absolutely no idea how the command line works and the "solutions" posted to the forums are like magic spells. No one understands them.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by RS3 on Saturday October 04, @02:51PM (1 child)
I rarely use sudo- mostly just when I've done a trial install of some distro that requires it, or boot a "live" system. It's been a few years, but IIRC I usually edit something in /etc (shadow and/or passwd?) to enable full root login, then su - . I don't remember if I ever did "sudo su -" but that's a great solution.
(Score: 4, Funny) by turgid on Saturday October 04, @03:01PM
It reminds me of Indiana Jones when the man with the sword attacks him and he just pulls out his gun and shoots him dead: sudo su.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Interesting) by Anonymous Coward on Saturday October 04, @12:39AM (9 children)
https://github.com/sudo-project/sudo/compare/v1.9.13...v1.9.14 [github.com]
Why does it even have all these "misfeatures" in the first place?
https://github.com/sudo-project/sudo/releases?page=2 [github.com]
(Score: 4, Insightful) by jb on Saturday October 04, @07:37AM (3 children)
Exactly. There is still (and probably always will be) a lot to be said for that core tenet of the Unix design philosophy: small tools for small jobs. Those who actually give a damn about security replaced sudo(8) with doas(1) a long time ago:
...about a decade ago, to be precise.
(Score: 2) by VLM on Saturday October 04, @02:02PM (2 children)
I was motivated enough to look into this.
doas originally came from openbsd and I couldn't find the source although I'm sure its out there.
https://github.com/nholstein/OpenDoas [github.com] cloned it for general unix/linux and was abandoned a decade ago
https://github.com/Duncaen/OpenDoas [github.com] is available in Debian (and all one zillion derrivatives) as opendoas package; looks like it was abandoned about half a decade ago.
There are several ports that claim to work on linux/unix/etc. I could probably find something abandoned more recently than the 2010s decade and compile it myself but my motivation is already seeping away.
Why use sudo? Well it seems to have git commits within the last half decade so it might be more secure (despite more known holes) and it has ELABORATE logging abilities which some corporates get all excited by. The only other use case I can think of is Ansible uses it by default to do "root stuff"
I looked into the Ansible situation and doas is supported by community.general however inside every friggin playbook I'd have to add something like "become_method: doas" or add "ansible_become_method=doas" in the inventory file (latter is a far more sane-ish way to do it).
There is some funny minor chicken and egg stuff where new installs and existing infra all use sudo so I'd have to have a playbook install doas using a working sudo system with "become_method: sudo" in the playbook then once doas is installed I can rely on the inventory setting for everything in general to use doas. I really don't need an extra headache in my life but this would probably work most of the time.
So in summary I could use abandonware to do security critical automated stuff, but I'd lose the ability to do nifty logging and it would "take a lot of work". Meh.
(Score: 4, Touché) by jb on Sunday October 05, @08:11AM (1 child)
Hardly abandonware.
The main downstream of Duncaen's port appears to be Alpine Linux, who have updated their package somewhat more recently: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/doas [alpinelinux.org]
There's also Jesse Smith's port which is still in active development: https://codeberg.org/thejessesmith/doas/ [codeberg.org].
And of course the genuine article (the OpenBSD original) remains actively maintained, see https://cvsweb.openbsd.org/src/usr.bin/doas/ [openbsd.org].
Sure there've been no commits to usr.bin/doas since 19 months ago, but that what do you expect? A well designed tool that's simple enough to be implemented in less than a thousand lines of code (610 lines of C plus 342 lines of yacc) doesn't tend to need much in the way of maintenance very often.
I haven't bothered to count the total LOC in sudo's tree, but it's clearly well over 10k ... and even just sudo's parse_args.c is almost as big doas' entire code base.
The real point I guess is that actively working to prevent "featuritis" is essential if any tool is going to remain useful/usable for long. Time was when hackers from all corners of the unix world used to follow that mantra, most quite successfully. But in recent years a big chunk of the Linux crowd seem to have been conned into believing that featuritis is something other than a nasty affliction.
(Score: 0) by Anonymous Coward on Thursday October 09, @12:37AM
A lot of software should be as boring and reliable as high grade concrete.
Unfortunately too many jobs depend on making software "too interesting".
(Score: 2) by VLM on Saturday October 04, @02:15PM (4 children)
Marketing.
It sold as "add yourself to a text file list to be allowed to run commands as root" which sounds terribly simple.
But it suffers horribly from "just add another feature"
People would lock themselves out from root after Fing up their /etc/sudoers file. Well... wrap vi in a script that runs a linter on /etc/sudoers and it'll try to prevent you from locking yourself out.
Who am I? A complicated philosophical issue. Using Linux standard PAM would be WAY too simple. Lets embed a LDAP client in sudo. I shit you not, you probably think I'm making this up. I'm not.
https://www.sudo.ws/docs/man/1.8.17/sudoers.ldap.man/ [www.sudo.ws]
The corporate security dweebs get VERY excited by being able to do all kinds of logging of the use of the sudo command. Its possible to log the absolute F out of everything.
The best analogy I can come up with from LISP. People think sudo is a tiny little LISP function definition, or an itty bitty little CLOS method or similar, but its really more like an entire macro system trying to rewrite your entire REPL.
Sarcastic comment would be its not GNU-Linux, its Sudo-GNU-Linux. Its got it tentacles pretty deep into the system...
Personally I've always felt if you can't trust people with sudo, you sure as hell can't trust them with a hypercomplicated system like sudo, its maximal security theater at its most dramatic.
(Score: 2) by VLM on Saturday October 04, @02:39PM (3 children)
I blame sudo for that typo (autocorrect gone mad?)
Regardless, hand manipulation of servers, using sudo or su, seems to have gone out of style; edit the Dockerfile and redeploy the microservice or service to the K8S cluster using unit testing and A/B testing. The days of the entire corporate LAN running one ONE shared vax running unix seem pretty far away.
I mostly "do stuff as root" for troubleshooting purposes by exec /bin/sh or similar into a docker container (or the K8S equivalent to get shell) to figure out whats gone wrong not to change anything (usually, except maybe for testing experiments)
(Score: 2) by Dr Spin on Saturday October 04, @03:26PM (2 children)
"The days of the entire corporate LAN running one ONE shared vax running unix seem pretty far away."
Please can we have a VAX-on-a-chip now? Ideally pin-compatible with some AMD processor/mobo. I'm pretty sure DEC
would enjoy a good spin in their grave.
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by VLM on Saturday October 04, @03:47PM (1 child)
You can do that with simh on a raspi but DEC's distant corporate descendants have left us in a situation where its not legally possible to license VMS. Oh its VERY easy to run VMS in a strict technical sense, both the pre- and post- pakgen.c licensing era systems, just not possible legally.
VAXen run BSDs pretty well. Of course you can run BSDs directly on pi bare metal without a VAX in the way.
VMS clustering was decades ahead of its time compared to some systems. I liked the standard VAX CLI, nothing has ever come close to that since, maybe Cisco router CLI, just in terms of depth and consistency.
Subjectively based upon decades of experience with DEC ranging from pdp8 to 11 to tops10 to VMS, DECs biggest enemy was themselves. Their licensing department usually seemed to think they're in charge of destroying an enemy company by any means necessary, without realizing that enemy company they're destroying was their own company.
(Score: 2) by Dr Spin on Saturday October 04, @07:12PM
I have similar DEC experience to you, and I agree about the licencing dept.
I wrote device drivers for SCSI tape drives and weird propriety hard disk interfaces. (VMS and System V).
I Emailed Ken Olsen twice - the first time to tell him to split hardware from software, and sell them separately,
The second time - to tell him to licence VMS for the 486 (or maybe Pentium?).
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by KritonK on Saturday October 04, @08:52AM
It's good to know that a manufacturer of locks [cisa.com] is expanding into computer security!
(Score: 1) by _-iNT13- on Sunday October 05, @09:41PM
Been fixed. [debian.org] Moved on...