Glances: `--disable-config-exec` does not cover on-alert action commands (incomplete fix of CVE-2026-53925)

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.