CVE-2026-85013: Environment-modules: command injection in environment-modules bash completion via malicious module names containing shell metacharacters

Published May 4, 2026
·
Updated

A flaw was found in environment-modules. A local attacker can exploit this vulnerability by placing a maliciously named modulefile in a location visible to the victim's MODULEPATH. When the victim uses Bash completion for module or ml commands, the malicious module name, containing shell metacharacters, is evaluated as a command. This can lead to arbitrary command execution in the completing user's shell, impacting their confidentiality, integrity, and availability.

Other sources

AIONLYREPORT package: environment-modules-5.6.1-2.el10 ------ Summary: Command Injection in Bash Completion via Malicious Module Names: attacker-controlled module names can reach Bash compgen -W during completion and execute command substitutions in the completing user's shell. Requirements to exploit: A local attacker must be able to place a maliciously named modulefile in a location that becomes visible in the victim's MODULEPATH, and the victim must use Bash completion for module or ml and trigger completion on affected subcommands. Component affected: environment-modules-5.6.1-2.el10, Bash completion in init/bashcompletion.in (modulecomgenwordsandfiles, moduleavail, modulespider, and related call sites), with module names originating from filesystem entries in tcl/modfind.tcl.in Version affected: environment-modules-5.6.1-2.el10 when Bash completion for module/ml is installed and used, and completion is performed against attacker-influenced module names Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - 7.3 (HIGH) AV:L - The attacker needs local access to place or expose a malicious module name through a searched module path. AC:L - The payload is a straightforward malicious filename using command substitution syntax. PR:L - The attacker needs low privileges sufficient to create or influence a module entry visible to the victim. UI:R - The victim must trigger shell completion, for example by pressing TAB. S:U - The impact is within the victim user's shell context rather than crossing a privilege boundary. C:H - Arbitrary commands in the victim shell can read the victim's accessible data. I:H - Arbitrary commands in the victim shell can modify the victim's files and shell state. A:H - Arbitrary commands in the victim shell can disrupt the victim session or delete accessible data. Impact: Moderate. Successful exploitation can execute arbitrary commands as the completing user, which can substantially affect that user's confidentiality, integrity, and availability. However, exploitation is conditional on a local attacker being able to influence module names presented through MODULEPATH, Bash completion being in use, and the victim actively triggering completion. This fits Red Hat's Moderate classification because the impact can be serious but reachability is configuration- and workflow-dependent rather than broadly and easily exploitable. Embargo: no Reason: The issue is locally exploitable, requires user interaction, and depends on attacker-influenced module search paths. Disabling the affected completion path or avoiding untrusted module paths provides practical mitigation, so immediate coordinated public remediation is more appropriate than embargo handling. Acknowledgement: Aisle Research Vulnerability Details: The Bash completion helper passes untrusted completion candidates to compgen -W, and Bash performs shell-like parsing of the supplied word list. When a module name contains command substitution syntax such as $(...), that syntax is evaluated during completion rather than treated as inert text. The vulnerable completion path is: bash init/bashcompletion.in modulecomgenwordsandfiles() { ... for val in $(compgen -W "$1" – "$2"); do ... done } ... avail) modulecomgenwordsandfiles "@compavailopts@ $(moduleavail "$cur")" "$cur";;

The module names are derived from filesystem entries without filtering shell metacharacters before they are stored and later emitted through module avail: tcl tcl/modfind.tcl.in set eltlist [glob -nocomplain -directory $dir ] ... set modulename [getModuleNameFromModulepath $element $dir] ... set modlist($modulename) [list modulefile $mtime $element]

Based on the available evidence, the issue is confirmed for environment-modules-5.6.1-2.el10. A broader affected version range was not established here, so this report scopes the finding to the scanned SRPM package. Steps to reproduce: 1. Load the completion script: bash source init/bashcompletion.in 2. Stub module so that module avail returns a malicious module name: bash rm -f /tmp/modulecompletionrepopathpoc module() { [ "$1" = avail ] && printf '%s\n' '$(touch /tmp/modulecompletionrepopathpoc)'; } 3. Trigger the affected completion path directly: bash COMPWORDS=(module avail "") COMPCWORD=2 module module "" avail 4. Verify the side effect: bash test -f /tmp/modulecompletionrepopathpoc && echo "Vulnerable" Optional end-to-end setup using a real module filename: bash mkdir -p /tmp/modpoc printf '#%%Module\n' > '/tmp/modpoc/$(touch /tmp/modulecompletionpoc)' module use /tmp/modpoc then trigger module avail <TAB> in an interactive Bash session with this completion loaded

Mitigation: Until a fix is available, avoid enabling Bash completion for module and ml in environments where untrusted users can influence MODULEPATH, and do not include attacker-writable module directories in shared search paths for other users. Where practical, remove or disable the affected completion script. Proposed Fix: Replace use of compgen -W for untrusted module-name lists with line-oriented filtering that does not evaluate shell syntax from completion candidates. diff diff --git a/init/bashcompletion.in b/init/bashcompletion.in @@ modulecomgenwordsandfiles() { local k=0 local setnospace=1 + local val do not append space to word completed if it is a directory (ends with /)

for val in $(compgen -W "$1" – "$2"); do + # Avoid compgen -W on untrusted module names (it evaluates shell syntax). + while IFS= read -r val; do + [ -z "$val" ] && continue + [[ "$val" == "$2" ]] || continue if [ $setnospace -eq 1 ] && [ "${val: -1:1}" = '/' ]; then

Bash >=4.0 is required for compopt type compopt &>/dev/null && compopt -o nospace setnospace=0 fi COMPREPLY[k++]="$val"

done + done <<< "$1" }

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat

Environment-modules: command injection in environment-modules bash completion via malicious module names containing shell metacharacters

— Microsoft

Affected Software

6 affected componentsFixes available
environment-modules=5.6.1-2.el10
Microsoft azl3 environment-modules 5.3.1-1<5.3.2-1
5.3.2-1
debian/modules*
debian/modules*
debian/modules<5.6.1-3
5.6.1-3
debian/modules<=5.2.0-1, <=5.5.0-1
5.7.0-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 5.3.2-1
  2. Upgrade

    Upgrade debian/modules to a version that resolves this vulnerability.

    Fixed in 5.6.1-3
  3. Upgrade

    Upgrade debian/modules to a version that resolves this vulnerability.

    Fixed in 5.7.0-1
  4. Configuration

    Until a fix is available, modify/replace the Bash completion helper in init/bash_completion.in (_module_comgen_words_and_files, call sites for module avail) so it does not pass untrusted module-name strings to compgen -W; instead use a safe mechanism that does not evaluate module-name shell metacharacters during completion.

    environment-modules (Bash completion: init/bash_completion.in _module_comgen_words_and_files / module avail completion) Bash completion candidates generation = Replace use of compgen -W for untrusted module-name lists
  5. Compensating control

    Do not include attacker-writable module search paths in MODULEPATH. Where practical, remove or disable the affected completion path or avoid untrusted module paths so that untrusted module names cannot be reached by the bash completion for module/ml.

Event History

May 4, 2026
Data Sourced
via Red Hat·03:55 PM
DescriptionSeverityAffected Software
Sep 15, 2026
CVE Published
via MITRE·03:08 PM
Data Sourced
via MITRE·03:08 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·04:17 PM
DescriptionSeverityWeakness
Data Sourced
via OSV·04:17 PM
DescriptionSeverityAffected Software
Exploit Published
via CISA·05:20 PM
Oct 13, 2026
Data Sourced
via Microsoft·08:15 AM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who can exploit this issue?

A local attacker who can place a maliciously named modulefile in a directory visible through another user's MODULEPATH can target that user. Exploitation occurs in the context of the user who triggers completion, so the attacker does not need to directly execute commands as the victim.

2

What user action triggers the command execution?

The victim must use Bash completion for the module or ml command and trigger completion on an affected subcommand. The malicious module name is evaluated during completion and can execute commands in the completing user's shell.

3

Are systems affected by default?

The available information does not establish whether the vulnerable Bash completion behavior is enabled by default. Exploitation requires both a malicious modulefile visible in MODULEPATH and use of Bash completion.

4

How can I determine whether users may already be exposed?

Review directories that can become visible in users' MODULEPATH for modulefiles with names containing shell metacharacters. Also identify users or shell initialization configurations that enable Bash completion for module or ml commands.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203