CVE-2026-73505

This vulnerability in Oh My Posh stems from a fundamental tension: the template system that makes the tool extensible is also the attack surface that enables command injection. The issue arises because setStyle() passes pt.Path — raw, attacker-controlled directory names — into a template rendering context that includes "cmd" in its function map. When a user navigates to a directory with a maliciously crafted name, that name gets rendered through the template engine, and the "cmd" function executes the embedded commands. This isn't a novel vulnerability — it's the same pattern that's plagued PHP ERB, Jinja2 with custom filters calling os.system, and numerous Go-based web frameworks. What makes this instance distinctive is the blast radius: the trigger is filesystem traversal, meaning every directory a user has ever navigated into, every directory in a cloned repository, every extracted archive, and every container volume mount becomes a potential exploitation vector. The attack surface compounds transitively and persists across sessions, software upgrades, and version control history. The fix options are well-established — scoped function maps, sandboxed renderers, or sanitization at the injection point. Without visibility into the specific commit, I can't determine which approach Oh My Posh chose. What matters most is whether they treated this as a one-off patch or recognized it as a durable security boundary requiring explicit documentation for future contributors. The broader lesson: any codebase rendering templates against filesystem-derived data must classify filesystem state as untrusted input in its threat model. This isn't just about Oh My Posh — it's about every tool that crosses the same boundary and assumes the local filesystem is a trusted environment.

Reviewed through automated stages and approved by a human before publication.