curl | bashYou wouldn't run a stranger's code without reading it. Yet every second developer docs page ends with this command.
This is the command in question:
It downloads a shell script from the internet and immediately executes it. You have no idea what runs. Neither does your team. Neither does your audit log.
The pipe is live. Bash receives and executes lines as they arrive. If your connection drops mid-script, you get partial execution — commands ran, cleanup didn't.
A server can detect curl's User-Agent or response-read timing and serve different content to a pipe than to a browser. Verifying the script in your browser doesn't mean you ran that script.
No checksum, no signature. You're trusting DNS, TLS, the CDN, and the origin server simultaneously. A compromised CDN or BGP hijack serves you malware — silently.
The URL is live and mutable. The script changes without notice. There is no record of what exactly executed on your machine — only that something did.
sudo and it's game over
curl ... | sudo bash hands root access to whoever controls that URL at that moment. This pattern appears in real published docs. Often.
Real install scripts, analyzed in June 2026. These are not hypothetical threats.
dev branch on GitHub — no tags, no version pinning. The script changes with every commit. What ran yesterday is not what runs today.
rm -rf ~/.hermes/, system-level traces remain.
mi-fds.com). No public git history, no checksum. You're trusting an opaque proprietary distribution system with no way to verify what you got.
The boring option is usually the right one. Package managers handle integrity, updates, and uninstallation.
One extra step. Gives you a chance to read the script and keeps a local copy for future reference.
If you must pipe — record what ran so you can audit or undo later.
bash -x traces top-level commands only. Subprocesses and sourced scripts won't appear in the log.
If the project publishes a SHA-256 hash, verify it before running. Non-negotiable on production machines.