Search order hijacking in a digital signature tool is not a clever zero-day — it's a predictable failure of secure defaults. CVE-2026-8164 affects a digital signature application that resolves executable paths using the system search order rather than fully qualified paths, allowing an attacker with local access to place a malicious binary in a directory the application searches before checking explicit locations. The result is arbitrary code execution under the signing tool's privileges — and if that tool holds active signing keys, the blast radius extends to your entire artifact trust chain.
The CVSS 7.3 is misleading. It captures the technical vector (local code execution) but not the consequence: a compromised signing key means every artifact that key touched is now suspect. That's not a local problem — that's a supply-chain event.
What to check: Audit any software in your signing infrastructure for path resolution that relies on system search order, implicit relative paths, or environment variables. If the application loads external binaries, plugins, or helpers without explicit full-path qualification, the trust boundary is porous. The fix is typically a one-line change (Path.GetFullPath or equivalent), but finding it requires knowing where your signing tool resolves external executables — that's the harder question, and it's not in the CVE.
The uncomfortable truth: search order hijacking has been documented since the early 2000s, and a signing tool was still vulnerable in 2026. This isn't about one negligent vendor — it's about a development ecosystem that makes the insecure approach the path of least resistance. Treat any path resolution in signing infrastructure as a trust boundary decision, not an implementation detail.