this post was submitted on 23 Feb 2026
154 points (98.1% liked)

Selfhosted

56856 readers
946 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

I set up a quick demonstration to show risks of curl|bash and how a bad-actor could potentially hide a malicious script that appears safe.

It's nothing new or groundbreaking, but I figure it never hurts to have another reminder.

top 50 comments
sorted by: hot top controversial new old
[–] Buddahriffic@lemmy.world 2 points 6 hours ago

An alternative that will avoid the user agent trick is to curl | cat, which just prints the result of the first command to the console. curl >> filename.sh will write it to a script file that you can review and then mark executable and run if you deem it safe, which is safer than doing a curl | cat followed by a curl | bash (because it's still possible for the 2nd curl to return a different set of commands).

You can control the user agent with curl and spoof a browser's user agent for one fetch, then a second fetch using the normal curl user agent and compare the results to detect malicious urls in an automated way.

A command line analyzer tool would be nice for people who aren't as familiar with the commands (and to defeat obfuscation) and arguments, though I believe the problem is NP, so it won't likely ever be completely foolproof. Though maybe it can be if it is run in a sandbox to see what it does instead of just analyzed.

[–] neidu3@sh.itjust.works 0 points 4 hours ago* (last edited 4 hours ago)

Running arbitrary text from the internet through an interpreter.. what could possibly go wrong.

I need to set up a website with

fork while 1

...Just so I can (try to) convince people to

curl | perl

it

...rhyme intended.

[–] MehBlah@lemmy.world 5 points 11 hours ago

Never have I ever piped curl to bash.

[–] ikidd@lemmy.world 7 points 14 hours ago (1 children)

Oh, people will keep using it no matter how much you warn them.

Proxmox-helper-scripts is a perfect example. They'll agree with you until that site comes up, and then its "it'll never, ever get hacked and subverted, nope, can't happen, impossible".

Wankers.

[–] corsicanguppy@lemmy.ca 1 points 12 hours ago* (last edited 12 hours ago)

I was looking at that very thing last night.

But then I realized, "why can't immich just create usable packages like we had before?" and moped back out.

But, for a moment, I was sure a little inspection and testing would make the Internet equivalent of NYC MTA coin-sucking magically safe. It looked so eeeeasy.

[–] It_Is1_24PM@lemmy.world 2 points 10 hours ago

I never thought about opening it in a browser. I always used curl to download such a script and view it where it was supposed to be run.

[–] xylogx@lemmy.world 10 points 16 hours ago (4 children)

Yes this has risks. At the same time anytime you run any piece of software you are facing the same risks, especially if that software is updated from the internet. Take a look at the NIST docs in software supply chain risks.

[–] Nibodhika@lemmy.world 2 points 9 hours ago (1 children)

But those are two very different things, I can very easily give you a one liner using curl|bash that will compromise your system, to get the same level of compromise through a proper authenticated channel such as apt/pacman/etc you would need to compromise either their private keys and attack before they notice and change them or stick malicious code in an official package, either of those is orders of magnitude more difficult than writing a simple bash script.

[–] xylogx@lemmy.world 1 points 8 hours ago

I would feel more comfortable running curl bash from a trusted provider than doing apt get from an unknown software repo. What you are trying to do is establish trust in your supply chain, the delivery vehicle is less important.

[–] ShortN0te@lemmy.ml 8 points 15 hours ago (11 children)

Not completely correct. A lot of updaters work with signatures to verify that what was downloaded is signed by the correct key.

With bash curl there is no such check in place.

So strictly speeking it is not the same.

load more comments (11 replies)
[–] axx@slrpnk.net 2 points 12 hours ago

This is a bit like saying crossing the street blindfolded while juggling chainsaws and crossing the street on a pedestrian crossing while the light is red for cars both carry risk. Sure. One's a terrible idea though.

load more comments (1 replies)
[–] krispyavuz@lemmy.world 6 points 18 hours ago (2 children)

Curl bash is no different than running an sh script you dont know manually…

[–] K3can@lemmy.radio 6 points 17 hours ago

True, but this is specifically about scripts you think you know, and how curl bash might trick you into running a different script entirely.

[–] axx@slrpnk.net 1 points 12 hours ago

No, it is different, as it adds an entire layer of indirection and unknown to the mix, increasing the risk in the process.

[–] sturmblast@lemmy.world 2 points 14 hours ago

You mean blindly running code is bad? /s

[–] osanna@thebrainbin.org 57 points 1 day ago (9 children)

you’d have to be mad to willingly pipe a script to bash without checking it. holy shit

[–] Dave@lemmy.nz 19 points 1 day ago (3 children)

Is it different from running a bash script you downloaded without checking it? E.g. the installer that you get with GOG games?

Genuine question, I'm no expert.

[–] axx@slrpnk.net 2 points 12 hours ago (1 children)
[–] Dave@lemmy.nz 1 points 11 hours ago

That's an interesting proof of concept, but I don't think it shows it's different. That's a server side attack, whoever has control of the server could just have the script download a malicious binary instead and you wouldn't be able to tell from the script.

[–] surewhynotlem@lemmy.world 4 points 17 hours ago

It's really only about trusting the source. Your operating system surely has thousands of scripts that you've never read and never checked. And wouldn't have time to. And people don't complain about that.

But it's really bad practice to run random things from random sites. So the practice of downloading a script and running it is frowned upon. Mostly as a way of maintaining good security hygiene.

[–] osanna@thebrainbin.org 12 points 23 hours ago (1 children)

I have no problems with running scripts from the internet, AFTER you check them. Do NOT blindly run a script you found on the internet. As others have said download them, then check them, then and only then run them if they're safe. NEVER pipe to bash, ever.

[–] Dave@lemmy.nz 11 points 23 hours ago (1 children)

Ok but not everyone has that skill. And anyway, how is this different to running a binary where you can't check the code?

[–] osanna@thebrainbin.org 9 points 23 hours ago (1 children)

it's exactly the same. Don't run binaries you don't trust fully. But i get what you mean. miley_cyrus_nude.jpg.exe is probably gonna end badly.

[–] Dave@lemmy.nz 8 points 23 hours ago (3 children)

Yeah I get that, but I would install docker, cloudflared, etc by piping a convenience script to bash without hesitation. I've already decided to install their binary, I don't see why the install script is any higher risk.

I know it's a controversial thing for everyone to make their own call on, I just don't think the risk for a bash script is any higher than a binary.

[–] moonpiedumplings@programming.dev 6 points 21 hours ago* (last edited 21 hours ago) (1 children)

I won't lie, I use curl | bash as well, but I do dislike it for two reasons:

Firstly, it is much, much easier to compromise the website hosting than the binary itself, usually. Distributed binaries are usually signed by multiple keys from multiple servers, resulting in them being highly resistant to tampering. Reproducible builds (two users compiling a program get the same output) make it trivial to detect tampering as well.

On the other hand, websites hosting infrastructure is generally nowhere near as secure. It's typically one or two VPS's, and there is no signature or verification that the content is "official". So even if I'm not tampering with the binary, I can still tamper with the bash script to add extra goodies to it.

On the other hand (but not really relevant to what OP is talking about), just because I trust someone to give me a binary in a mature programming language they have experience writing in, doesn't mean I trust them to give me a script in a language known for footguns. A steam bug in their bash script once deleted a user's home directory. There have also been issues with AUR packages, which are basically bash scripts, breaking people's systems as well. When it comes to user/community created scripts, I mostly trust them to not be malicious, and I am more fearful of a bug or mistake screwing things up. But at the same time, I have little confidence in my ability to spot these bugs.

Generally, I only make an exception for running bash installers if the program being installed is a "platform" that I can use to install more software. K3s (Kubernetes distro), or the Nix package manager are examples. If I can install something via Nix or Docker then it's going to be installed via there and not installed via curl | bash. Not every developer under the sun should be given the privilege of running a bash script on my system.

As a sidenote, docker doesn't recommend their install script anymore. All the instructions have been removed from the website, and they recommend adding their own repo's instead. Personally, I prefer to get it from the distro's repositories, as usually that's the simplest and fastest way to install docker nowadays.

load more comments (1 replies)
load more comments (2 replies)
[–] wildbus8979@sh.itjust.works 30 points 1 day ago (8 children)

And you better inspect and execute a downloaded copy, because a malicious actor can serve a different file for curl/wget than to your browser

load more comments (8 replies)
[–] jtrek@startrek.website 17 points 1 day ago (1 children)

Most developers I've looked at would happily just paste the curl|bash thing into the terminal.

I often would skim the script in the browser, but a. This post shows that's not fool proof and b. a sufficiently sophisticated malicious script would fool a casual read

load more comments (1 replies)
[–] cecilkorik@piefed.ca 20 points 1 day ago

And it's wild how much even that has been absolutely normalized by all these shitty lazy developers and platforms. Vibe coding it just going to make it worse. All these programs that look nice on the surface and are just slop on the inside. It's going to be a mess.

[–] BluescreenOfDeath@lemmy.world 18 points 1 day ago (3 children)

The post is specifically about how you can serve a totally different script than the one you inspect. If you use curl to fetch the script via terminal, the webserver can send a different script to a browser based on the UserAgent.

And whether or not you think someone would be mad to do it, it's still a widespread practice. The article mentions that piping curl straight to bash is already standard procedure for Proxmox helper scripts. But don't take anyone's word for it, check it out:

https://community-scripts.github.io/ProxmoxVE/

It's also the recommended method for PiHole:

https://docs.pi-hole.net/main/basic-install/

load more comments (3 replies)
load more comments (4 replies)
[–] quick_snail@feddit.nl 2 points 15 hours ago (1 children)

a more cautious user might first paste the url into the address bar of their web browser to see what the script looks like before running it.

Wow, I never thought anyone would be that dumb.

Why wouldn't they just wget it, read it, and then execute it?

[–] axx@slrpnk.net 5 points 12 hours ago* (last edited 12 hours ago)

Oh the example in the article is the nice version if this attack.

Checking the script as downloaded by wget or curl and then piping curl to bash is still a terrible idea, as you have no guarantee you'll get the same script in both cases:

[–] quick_snail@feddit.nl 2 points 15 hours ago (1 children)

Anytime I see a project that had this in their install instructions, I don't use that project.

It shows how dumb the devs are

[–] axx@slrpnk.net 2 points 12 hours ago

Yes, this is the correct approach from a security perspective.

[–] oeLLph@feddit.org 1 points 14 hours ago (1 children)

@K3can@lemmy.radio love the early 2000s stylesheet/color theme of your blog 🙂

[–] K3can@lemmy.radio 1 points 13 hours ago

Thanks! I like to keep things simple. The colors are based on Counter Strike 1.6. 😁

And if you're into the classic styling, my homepage is a direct homage to my old 2000s sites.

load more comments
view more: next ›