Ansible Lightspeed CVE-2026-44191

Exploitation requires the victim to open, in VS Code with the Ansible/Lightspeed extension installed, a workspace where the attacker controls the ansible.executionEnvironment.containerOptions or ansible.executionEnvironment.volumeMounts settings (typically via a repository-supplied .vscode/settings.json) and where the execution-environment feature is in use; the injected shell separators are then processed automatically when the Language Server initializes or manually when a playbook is executed. Limiting factors: the attack is local (AV:L) and needs user interaction (UI:R) - the victim must open the malicious project/playbook; it does not work against a user who never opens attacker-controlled workspaces, who runs the editor in Workspace Trust/Restricted Mode that suppresses workspace settings, or who does not have the execution-environment settings honored. Impact is bounded to the privileges of the VS Code user (S:U), not automatic root.

Signals are largely consistent and point to a genuine but interaction-gated developer-workstation risk rather than a mass-exploitable server flaw. The CVSS vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H gives full C/I/A impact but requires local vector and user interaction (UI:R), which caps the base score at 7.8. PR:N is accurate in the sense that the attacker needs no account on the victim system - the payload is delivered via a crafted workspace - but exploitation absolutely depends on the victim opening that workspace/playbook. No EPSS score, KEV entry, POC, or SSVC decision data was provided in the input, so probabilistic and exploitation-status signals cannot be weighed; this is a data gap, not evidence of low risk. The practical danger is elevated by the 'triggered automatically during Language Server initialization' behavior: unlike many UI:R flaws that need an explicit build/run action, merely opening a malicious folder may suffice, narrowing the gap between UI:R and zero-click. Overall this is a real priority for organizations where developers routinely clone untrusted Ansible repositories, and lower priority for locked-down or single-tenant developer environments.

An attacker publishes an innocuous-looking Ansible role or playbook repository whose .vscode/settings.json sets ansible.executionEnvironment.containerOptions to a value containing shell separators and an appended payload (e.g., a reverse shell). A developer clones and opens the repo in VS Code; during Ansible Language Server initialization the crafted option is concatenated into a container command and the injected commands execute as that user. No public POC is identified at time of analysis, but the AV:L/AC:L profile makes reliable exploitation straightforward once the victim opens the project.