CVE-2026-68519

Summary

In Glances 4.5.5 the --disable-config-exec flag was extended (GHSA-3vwc-qwhc-3mj7) to stop secure_popen() from interpreting the shell operators &&, | and > in AMP command values taken from the configuration file. The hardening was not applied to the on-alert action command path, which reads its command lines from the same configuration file. As a result, with --disable-config-exec enabled, a configured alert action that contains > (file redirection), && (chaining) or | (pipe) still has those operators interpreted, allowing arbitrary file write / command chaining at the privilege of the glances process when the alert triggers.

Affected code

glances/actions.py (Glances 4.5.5, latest):

ret = secure_popen(cmd_full)        # line 111 — no allow_operators=, defaults to True

By contrast the AMP modules were fixed:

# glances/amps/default/__init__.py:69
self.set_result(secure_popen(res, allow_operators=self.allow_operators()).rstrip())
# glances/amps/systemv/__init__.py:60
res = secure_popen(self.get('service_cmd'), allow_operators=self.allow_operators())

PoC (benign)

glances.conf:

[cpu]
user_critical=1
user_critical_action=echo MARKER > /tmp/poc_marker

Run glances --disable-config-exec and generate CPU load. When the cpu user alert reaches CRITICAL, /tmp/poc_marker is created — i.e. the > operator was interpreted despite --disable-config-exec. The same > in an [amp_*] command value is correctly not interpreted.

Impact

Arbitrary file write (>), command chaining (&&) and pipe (|) from config-defined alert actions, contrary to the guarantee of --disable-config-exec. Trust boundary = the glances configuration file.

Suggested fix

Pass allow_operators=not args.disable_config_exec from GlancesActions.run() into secure_popen() (GlancesActions already holds args).

Credit

Reported via responsible-disclosure incomplete-fix measurement study.

Summary

In Glances 4.5.5 the --disable-config-exec flag was extended (GHSA-3vwc-qwhc-3mj7) to stop secure_popen() from interpreting the shell operators &&, | and > in AMP command values taken from the configuration file. The hardening was not applied to the on-alert action command path, which reads its command lines from the same configuration file. As a result, with --disable-config-exec enabled, a configured alert action that contains > (file redirection), && (chaining) or | (pipe) still has those operators interpreted, allowing arbitrary file write / command chaining at the privilege of the glances process when the alert triggers.

Affected code

glances/actions.py (Glances 4.5.5, latest):

ret = secure_popen(cmd_full)        # line 111 — no allow_operators=, defaults to True

By contrast the AMP modules were fixed:

# glances/amps/default/__init__.py:69
self.set_result(secure_popen(res, allow_operators=self.allow_operators()).rstrip())
# glances/amps/systemv/__init__.py:60
res = secure_popen(self.get('service_cmd'), allow_operators=self.allow_operators())

PoC (benign)

glances.conf:

[cpu]
user_critical=1
user_critical_action=echo MARKER > /tmp/poc_marker

Run glances --disable-config-exec and generate CPU load. When the cpu user alert reaches CRITICAL, /tmp/poc_marker is created — i.e. the > operator was interpreted despite --disable-config-exec. The same > in an [amp_*] command value is correctly not interpreted.

Impact

Arbitrary file write (>), command chaining (&&) and pipe (|) from config-defined alert actions, contrary to the guarantee of --disable-config-exec. Trust boundary = the glances configuration file.

Suggested fix

Pass allow_operators=not args.disable_config_exec from GlancesActions.run() into secure_popen() (GlancesActions already holds args).

Credit

Reported via responsible-disclosure incomplete-fix measurement study.

Glances is an open-source system cross-platform monitoring tool. Prior to 4.5.6, GlancesActions.run() in glances/actions.py ignores --disable-config-exec for on-alert action commands and invokes secure_popen() with shell operators enabled, allowing configured redirection, command chaining, or pipes to execute when an alert triggers. This issue is fixed in 4.5.6.

These are all security issues fixed in the glances-common-4.5.6-1.1 package on the GA media of openSUSE Tumbleweed.