Quoted tilde in PATH is a security risk
Original: The tilde in your PATH may not be your HOME
Why This Matters
Misconfigured PATH is a classic local privilege escalation and supply-chain vector.
Using '~/.local/bin' inside quotes in shell config files does not expand to $HOME—it literally adds '~/.local/bin' relative to the current directory, creating a path hijacking risk.
A subtle shell behavior can silently introduce a local-directory entry into your PATH. When you write export PATH="$PATH:~/.local/bin/" in .bashrc or .zshrc, the tilde is not expanded to your home directory—because tilde expansion only happens in unquoted contexts. Bash docs are explicit: tilde expansion in variable assignments fires after '=' and after each ':', but only when unquoted.
The result is that ~/.local/bin becomes ./~/.local/bin—a path relative to wherever you launch a shell. Any binary placed there gets picked up and executed. The blog post demonstrates this concretely: a small C binary compiled into ./~/.local/bin/ and named 'kek' runs without issue when PATH is set with the quoted tilde.
The fix is simple: replace ~ with $HOME. The unquoted form export PATH=$PATH:~/.local/bin technically works in Bash and Zsh, but a stray space breaks the assignment and the tilde stops expanding—making it fragile. The issue was first spotted via the nono sandbox tool, which flags PATH entries the sandbox can write to. You can audit your own setup by running: echo "$PATH" | tr ':' '\n' | grep '~'