Unfortunately, there's a lot of gotchas in Bash like this. A lot of them are documented here: https://mywiki.wooledge.org/BashPitfalls, including the `test -v` case, which is #61. Some more code execution pitfalls are documented here: https://mywiki.wooledge.org/BashProgramming/05?action=show&r... including the `-eq` part (under Arithmetic Expansion).

Basically, the -v case was by design, so for `-v 'hash[$key]'`, "$key is expanded before the array subscript evaluation, and then the whole array plus expanded index is evaluated in a second pass". "Newer versions of bash (5.0 and higher) have a assoc_expand_once option which will suppress the multiple evaluations"

Note that the `-v` case doesn't really work the way one may infer from reading the OP:

> $ key='$(cat /etc/passwd > /tmp/pwned)'

> $ [[ -v 'x[$key]' ]]

> bash: $(cat /etc/passwd > /tmp/pwned): syntax error: operand expected (error token is "$(cat /etc/passwd > /tmp/pwned)") *

> [[ -v "${x[$key]}" ]]

> bash: $(cat /etc/passwd > /tmp/pwned): syntax error: operand expected (error token is "$(cat /etc/passwd > /tmp/pwned)")

Yuck, I was always instinctively put off by [[, now I finally have some arguments to justify it.

IMO safe shell scripting is kind of dead. I can do it if I really have to, but too many external programs have tricky "convenience" features like interpreting flags after positional parameters, etc.

So many footguns in bash. When do we finally get serious about ditching this language as an industry in the same way we are about memory safety?

What's the fix for those code samples?

Shellcheck currently gives Sample 1 a pass. I hope this is something it can be modified to catch.

I... don't understand. I thought the whole reason for using [[ and breaking posix compatibility was to prevent just this kind of vulnerability. Why would bash do this.