There are many ways using a shell to exec the sub-command can go wrong. Whether that is unexpected spaces in the command or that the shell reads config files that output unexpected values. We encountered the unexpected output due to a very strange interaction with vault being used in a shell. We ran into this using GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) in a pipe over an ssh connection.

This stemmed from folks setting a default export VAULT_ADDR=https://vault.example.com in their ~/.bashrc, and that somehow when compiled with SSH_SOURCE_BASHRC defined as is apparently the default in some linux distributions, when bash detects it is used in a pipe and that variable is set (as it is when you have ssh'd to a remote host), bash will source ~/.bashrc, overriding the desired VAULT_ADDR. This would happen, for example, with vault list -address https://test-vault.example.com foo | cat. This fails to login because the token_helper returns the token for vault.example.com instead of test-vault.example.com. It is also an issue with updating the VAULT_ADDR in your environment to something other than the default before executing vault.

Expected behavior
Given the existing restriction on using only absolute paths, the token helper commands should be executed directly without involving the shell.

Environment:

• Vault Server Version (retrieve with vault status): 1.18.3
• Vault CLI Version (retrieve with vault version): Vault v1.18.3 (7ae4eca5403bf574f142cd8f987b8d83bafcd1de), built 2024-12-16T14:00:53Z
• Server Operating System/Architecture: x86_64-pc-linux-gnu

Assuming there isn't any existing related work related to this issue, I plan to submit a PR with a fix shortly.