macOS 26.4 Brings New Terminal Security Feature to Stop Malicious Commands

General News
1

macOS 26.4 is now out, and with it comes a new feature in the Terminal app to help prevent malicious commands pasted into the terminal from running.

This is a companion discussion topic for the original entry at https://www.privacyguides.org/news/2026/04/02/macos-26-4-brings-new-terminal-security-feature-to-stop-malicious-commands
2

I’ve seen potentially dangerous commands like this published online for installing apps/packages, sometimes by software vendors who should know better.

# curl https://somedomain.com/xyz/blahblahblah/install.sh | sh
1 Like
3

Yeah definitely using curl for installing apps is questionable.

4

What it’s dangerous about installing with curl? Legit question, I simply don’t know and would like to - either a link or an explanation would be appreciated.

5

Anything can be done on your machine essentially. It’s much better to use package managers to install apps.

6

Alright, but I guess it’s still fine to trust installing package managers themselves with curl? Like Homebrew and Pixi are primarily installed with curl.

7

For people here who do not understand the command, curl downloads data from a URL, and | means pipe the data that comes from curl (the left command) into the shell interpreter (the right command), most commonly sh or bash. A variant of this is sh -c "$(curl ...)" which essentially does the same thing. Another variant is using wget in place of curl.

In commands floating around on the internet, the server the URL refers to could be malicious.

The risk is higher if

  • The shell interpreter command is prefixed with sudo or the script asks for root privileges.
  • The command comes from an untrusted source, thus may have been modified by whoever published it.
  • The URL is non-TLS, enabling MITM attacks that modify the downloaded script in transit.
  • The URL is an untrustworthy source.

If the source is a malicious server, the server can do nasty things on the system that runs the script. Worse, the server can deliver different payloads to different clients. For instance, with respect to running a downloaded script, it is possible for the server to detect the script is being piped into and is being run by a shell interpreter, and if it is not being run, deliver a benign payload to avoid detection of malicious intent to fool anyone who attempts to inspect the script.

Before installing or running anything, it is important to verify the download; the best practice is verifying the cryptographic signature of it created by the provider of the download. However when a downloaded shell script is piped directly into a shell, there is no such opportunity. I think it is bad practice when software vendors instruct users to pipe a script into a shell. The server is capable of delivering different scripts to different clients, thus is capable of selectively delivering malicious scripts to certain clients, for instance when coerced into being malicious.

Another issue is what happens when the server connection is severed. The script will start running even before it is fully downloaded. The result is a script that runs half way, possibly leaving the system in an intermediate state, for instance if it was trying to install something.

It is safer, but not necessarily safe, to download the entire script first and verify it before running it. When installing something, much better is use a package manager.

2 Likes