Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft malicious Ansible repo with poisoned .vscode settings
-
DeliveryVictim clones and opens workspace in VS Code
-
ExploitLanguage Server init reads containerOptions/volumeMounts
-
ExecutionShell separators inject attacker commands
-
PersistArbitrary code executes as VS Code user
-
ImpactSystem compromise
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization OS command sanitization, avoid shell exec
MITRE ATT&CK
2 techniques across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 22, 2026
Local code execution in the Visual Studio Code Ansible (Lightspeed) extension lets a malicious project run arbitrary shell commands on a developer's machine by abusing the ansible.executionEnvironment.containerOptions and volumeMounts settings, which fail to sanitize shell separators (CWE-78). Because these are workspace-scoped settings, simply opening a booby-trapped repository can auto-trigger execution during Language Server initialization, yielding code execution as the VS Code user. No public exploit has been identified at time of analysis, and the flaw is not listed in CISA KEV; CVSS is 7.8 (High).
RemediationAI
Update the Visual Studio Code Ansible/Ansible Lightspeed extension to the fixed release once available and monitor the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-44191 and Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=2466761 for the exact patched version, which is not stated in the available data (no vendor-released fix version independently confirmed). As compensating controls until patched: avoid opening untrusted Ansible repositories in VS Code, and use VS Code Workspace Trust / Restricted Mode so that workspace-supplied settings are not applied automatically (trade-off: some language features are disabled in untrusted folders). Explicitly review or strip ansible.executionEnvironment.containerOptions and ansible.executionEnvironment.volumeMounts from any cloned project's .vscode/settings.json before trusting it, and where execution environments are not needed, disable the execution-environment feature entirely (trade-off: loss of containerized playbook runs). Pin trusted configuration at the user/global scope and prevent workspace overrides where the editor supports it.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerable component is Red Hat's Ansible extension for Visual Studio Code, which integrates the Ansible Language Server and the Lightspeed AI assistant. To run playbooks inside container-based 'execution environments', the extension reads the ansible.executionEnvironment.containerOptions and ansible.executionEnvironment.volumeMounts configuration values and passes them into a container runtime command line (e.g., podman/docker invocation). The root cause is CWE-78 (OS Command Injection): user/workspace-supplied option strings are concatenated into a shell command without neutralizing metacharacters such as ; | && $() , so an attacker who controls those settings can append additional shell commands. Because VS Code honors workspace-level settings (.vscode/settings.json), the attacker-controlled value travels with a repository rather than requiring access to the victim's global config. The CPE data maps this to Red Hat Ansible Automation Platform 2 packaging (cpe:2.3:a:red_hat:red_hat_ansible_automation_platform_2), reflecting Red Hat's distribution of the extension/language server component.
Know when Red Hat Ansible Automation Platform 2 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Attacker needs no account (payload delivered via workspace, PR:N) but victim must open the malicious project locally (AV:L, UI:R); full C/I/A as arbitrary code runs with the user's privileges (S:U).
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in the Visual Studio Code Ansible Lightspeed extension. This command injection vulnerability (CWE-78) arises from improper handling of the ansible.executionEnvironment.containerOptions and ansible.executionEnvironment.volumeMounts settings, allowing an attacker to inject shell separators. This can be triggered automatically during Language Server initialization or manually when executing a playbook. Successful exploitation leads to remote code execution (RCE) on the victim's machine with the privileges of the Visual Studio Code user, potentially resulting in a complete system compromise.
Executive ViewAI
The VS Code Ansible Lightspeed extension contains a local code execution vulnerability (CVE-2026-44191, CVSS 7.8) that executes arbitrary shell commands when developers open repositories with malicious workspace settings. No public exploit has been identified at time of analysis. Developer machines are high-value targets holding source code, credentials, and cloud access; compromise enables credential theft, intellectual property exfiltration, and supply chain attacks against your organization.
No vendor-released patch identified at time of analysis. Interim mitigations: uninstall or disable the Ansible Lightspeed extension; block workspace-scoped execution environment settings via policy; deploy endpoint detection and response (EDR) to monitor malicious process execution from VS Code; mandate code review before opening external repositories; use containerized development environments with restricted host access; implement file integrity monitoring on developer workstations.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
OS command injection occurs when an application passes unsanitized user input directly into system shell commands.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Affected Products (CPE)CVE.org
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated o
Authenticated users who hold permission to create or modify a project within a single organization can execute arbitrary
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 bec
Credential disclosure in Red Hat Ansible Automation Platform 2.5 and 2.6 allows any authenticated user to retrieve plain
Server-side request forgery in the Red Hat Ansible Automation Platform 2 Controller's HashiCorp Vault credential plugin
Privilege escalation in Red Hat Ansible Automation Platform 2 (built on the AWX upstream project) lets an authenticated
Arbitrary file write in pulpcore's FilesystemExport feature allows an authenticated administrator to escape the intended
Symlink-following file overwrite on the Ansible control node is possible in ansible-core when a user runs `ansible-galax
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an auth
An authenticated automation-controller administrator in Red Hat Ansible Automation Platform 2 can turn the administrator
Jinja2 template injection in Ansible Operator Plugins (CWE-1336) lets an authenticated Kubernetes user who can create or
Missing object-level authorization in the JobTemplate copy endpoint (CopyAPIView) of AWX and Red Hat Ansible Automation
EUVD-2026-47655
GHSA-63fx-4hcp-68gg
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB