CVE-2026-85013: Environment-modules: command injection in environment-modules bash completion via malicious module names containing shell metacharacters
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 5.3.2-1 - Upgrade
Upgrade
debian/modulesto a version that resolves this vulnerability.Fixed in 5.6.1-3 - Upgrade
Upgrade
debian/modulesto a version that resolves this vulnerability.Fixed in 5.7.0-1 - 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 - 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
Frequently Asked Questions
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.
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.
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.
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.