Now those gpg.fail people made me find similar vulns elsewhere (console control character injection). By "elsewhere" I mean... my own code.
Opinions wanted: should "input can inject console output with ansi and control chars" always be considered a vuln/CVE?
(I'll fix it in any case, I'm just wondering if I should do all the "security release/advisory/request CVE/..." stuff.)

@hanno Generally no. It's expected that processes that output some arbitrary data provided by a third party might output some arbitrary data provided by a third party that you don't like appearing on your terminal.

The vulnerability is in terminal emulators implementing control channel vectors in their data channel. That should not be a thing.

@hanno Not saying it's not a vulnerability but I think you won't be able to score this with CVSS that would make CVE registration weird.

@dalias one may argue that in this case it's not expected that arbitrary data is displayed. (Situation is an error message of the form "Error: value [...] is invalid for this")

@buherator I have requested countless CVEs without doing CVSS and let mitre do that so I can ignore it. I think CVSS is more or less a random number generator (but not a cryptographically secure one).

@hanno I'm bringing this up exactly because when CVSS will be assigned it will either show 0.0 or some really weird non-sense. The former would be likely a better, but still misleading scenario,. My bet is on MITRE publishing some non-sense though.

@buherator I'm totally fine with that.

@hanno I'm speaking of very much a high level general principle here.

@hanno @buherator Fwiw, we don't do CVSS for Firefox CVEs and someone is doing nonsense-CVSS numbers for us. (People downstream look at the nonsense-CVSS and make decisions based on them, which saddens me. But I don't think we should play the cvss game)

@freddy @buherator see, if firefox can do that, I can do that as well 🙂

@hanno if you create a ascii file as output, would it still be vulnerable? As soon as the presentation layer can be modified, the presented contents can, too. (I don´t have a solution, the attacked group here is a naive console user. Security here would include trusted presentation layer, which the CLI obviously is not fully)

@freddy @hanno @buherator This is what the Go team does, too, and we are similarly sad about the made-up scores being taken seriously.

@hanno FTR, the OpenSSL project didn't consider my work on control characters injection in ASN.1 structures to be worth a security advisory cfr https://codeberg.org/wllm-rbnt/hacklu-2025-CLI-ambush

@filippo @freddy @hanno I'll save this thread under "even your vendor doesn't approve CVSS" for future reference

@hanno
I guess it depends in the case...

As a general principle, I'd say that every tool is responsible for ensuring that the output is formatted correctly.

If outputting raw binary data is an expected use-case for the tool, I'd say the sensible thing to do is not output to stdout by default (at least not if stdout is a terminal), but require the user to specify an output file.
If the expected use-case for the tool is to output text data, then the tool should make sure user input reflected in its output is text.

Whether it's a security vulnerability would depend on the user expectations regarding the tool and how easy it would be to confuse an error message with a success message...

@freddy @hanno @buherator OpenSSL and cURL don't do CVSS either.

@hanno @dalias If this is fixed then the input shouldn’t be used in the error message at all. What good does such a message do if the shown input isn‘t used verbatim?

@weizenspreu @dalias I agree, and that's how I plan to fix it.

@oots @hanno Wouldn’t that still be a Terminal issue?

How is stuff like `cat`, `tr`, `base64 -d`, etc. expected to know that STDOUT isn‘t piped into a file?

@weizenspreu @oots yeah I think there's a difference between "tools that are supposed to display arbitrary output from input" (cat/base64/curl/...) and "tools that usually don't do that". my case falls in the latter, so I tend to think "unexpected, and thus it's a vuln".

@hanno As another datapoint, MOTW bypasses worth CVE's at MS (e.g. CVE-2025-24061). It's not the same ofc. as an automatic control is bypassed in such cases, but at the same time users could choose to bypass the control after a warning (which the CVE also bypasses).

@hanno what’s the impact in your specific case? What’s the credible attack vector?

To put another way - what additional information or what access/privilege would the person who is able to control those input characters gain by “exploiting” this?

I’m of the opinion that a user shooting themself in the foot isn’t a CVE. If an attacker punches in bad data and gets that reflected to themselves on the command line, that is not a change in access, nor information, and thus not something that rises to the level of a vulnerability. If an attacker doesn’t learn new information, and doesn’t get privileges they didn’t already have by triggering the bug, then it’s not a vulnerability.

It reminds me of the time someone tried to file a vulnerability report on an image processing CLI tool I was working on, because it would throw an unhandled exception if you tried to open a text file. They claimed it was a DoS.

I replied that if a user wanted to prevent themselves from running the app, they could just choose not to run the app… they didn’t need to open a non-image file and cause the app to quit. We still cleaned up the exception with an improved error message and a more graceful exit, but we certainly didn’t CVE it.