Curl isn't the problem they're describing. The remote can assume you're running it in a terminal (especially since the user agent string indicates you're using curl) and can send malicious escape sequences in the body, which will be interpreted by your terminal emulator in most cases.

This is true of any program that prints output directly from a remote host / untrusted source.

In the event your terminal emulator has a vulnerability or allows you to run arbitrary commands (this is a feature of some emulators), the site can target that functionality for users of that emulator and wreak havoc.

I maintain a lot of ANSI escape related code. These exploits have always been theorized, but I've not once heard about this being exploited in the wild. It's certainly possible. Not very probable. Refer to your threat model, as always.

is there way to “sanitize” the curl output such that escaping is disabled?

another commenter mentioned the threats of graphics, but this seems more concerning, esp. in an elevated shell. maybe pipe curl to a text file and inspect before running?

Don't use a terminal emulator, or yes redirect to a file. But that means you'll need to know what the escapes do, and they look cryptic to the layperson. Also, inspect with an editor that replaces non-printing with some other character (like vim, unlike cat) otherwise it's just as bad as letting curl output.

And even then, this is probably not a threat you need to worry about.

No it isn't, or it's at least not the problematic part. curl is just the messenger, and on outputting things to a terminal you can use escape codes, and other things, to do some funky stuff like changing colors or making text blink.

If the terminal has a bug w.r.t. something it processes one could leverage that, but they'd probably need to know which terminal and maybe even which shell you're using; so maybe don't let curl/wget but also `cat` of a downloaded file output directly to the terminal if it isn't a trusted origin or if it looks/feels shady.