A flaw was found in the bash functionality that evaluates specially formatted environment variables passed to it from another environment. An attacker could use this feature to override or bypass restrictions to the environment to execute shell commands before restrictions have been applied. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
Acknowledgements:
Red Hat would like to thank Stephane Chazelas for reporting this issue.
The path autocompletion feature in Bash 4.4 allows local users to gain privileges via a crafted filename starting with a " (double quote) character and a command substitution metacharacter.
GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of environment variables, which allows remote attackers to write to files or possibly have unknown other impact via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the modcgi and modcgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271.
A security flaw was found in bash, which could be exploited remotely via applications which parse untrusted user scripts via bash. This flaw is different from CVE-2014-6277, CVE-2014-7169 and CVE-2014-7186.
(1) bash before 1.14.7, and (2) tcsh 6.05 allow local users to gain privileges via directory names that contain shell metacharacters ( back-tick), which can cause the commands enclosed in the directory name to be executed when the shell expands filenames using the \w option in the PS1 variable.
The prompt parsing in bash allows a local user to execute commands as another user by creating a directory with the name of the command to execute.
Bash before 4.4 allows local users to execute arbitrary commands with root privileges via crafted SHELLOPTS and PS4 environment variables.
A vulnerability was found in popd. It can be tricked to free a user supplied address in the following way:
$ popd +-111111
This could be used to bypass restricted shells (rsh) on some environments to cause use-after-free.
References:
http://seclists.org/oss-sec/2016/q4/445
Subject: [oss-security] Follow-up: rbash escape via history built-ins
In my earlier message I described how history -w can overwrite startup files in $HOME, breaking confinement in restricted bash.
To add one clarification: even if administrators place users in an unwritable subdirectory (e.g., $HOME/restricted), symlinks from that directory back into writable $HOME files (such as .profile) can re-expose the same vulnerability. This means that simply making the working directory unwritable is insufficient if symlinks escape into writable locations.
Recommendation: Restricted environments should ensure $HOME itself is unwritable, or that the non-writable directory lacks symlinks into writable paths. This complements the earlier advice about history-writing built-ins.
-- RelunSec
On Tue, Jan 27, 2026 at 3:33 PM cyber security <cs7778503 () gmail com> wrote: Summary: Restricted Bash (rbash) blocks output redirection to prevent file modification. However, history-writing built-ins (history -w, history -a) can overwrite startup files such as .profile if the restricted user is left in $HOME. This allows PATH resets and escape from confinement.
Steps to reproduce: 1. Start rbash in $HOME with writable .profile. 2. Run: history -w .profile 3. On next login, .profile is sourced, PATH is reset, confinement is broken.
Discussion: The Bash manual notes administrators must configure restricted environments carefully (unwritable $HOME, different working directory, restricted PATH). However, this particular escape vector is not documented in common guides (e.g., https://0xffsec.com/handbook/shells/restricted-shells/).
Recommendation: While consistent with current design, administrators should be aware that history-writing built-ins can modify files in the current directory. Restricted environments should ensure $HOME is unwritable or place users in a safe subdirectory.
References: GNU Bash manual: https://www.gnu.org/software/bash/manual/htmlnode/The-Restricted-Shell.html
-- RelunSec
Summary: Restricted Bash (rbash) blocks output redirection to prevent file modification. However, history-writing built-ins (history -w, history -a) can overwrite startup files such as .profile if the restricted user is left in $HOME. This allows PATH resets and escape from confinement.
Steps to reproduce: 1. Start rbash in $HOME with writable .profile. 2. Run: history -w .profile 3. On next login, .profile is sourced, PATH is reset, confinement is broken.
Discussion: The Bash manual notes administrators must configure restricted environments carefully (unwritable $HOME, different working directory, restricted PATH). However, this particular escape vector is not documented in common guides (e.g., https://0xffsec.com/handbook/shells/restricted-shells/).
Recommendation: While consistent with current design, administrators should be aware that history-writing built-ins can modify files in the current directory. Restricted environments should ensure $HOME is unwritable or place users in a safe subdirectory.
References: GNU Bash manual: https://www.gnu.org/software/bash/manual/htmlnode/The-Restricted-Shell.html
-- RelunSec
A flaw was found in the bash package, where a heap-buffer overflow can occur in valid parametertransform. This issue may lead to memory problems.
An issue was discovered in disableprivmode in shell.c in GNU Bash through 5.0 patch 11. By default, if Bash is run with its effective UID not equal to its real UID, it will drop privileges by setting its effective UID to its real UID. However, it does so incorrectly. On Linux and other systems that support "saved UID" functionality, the saved UID is not dropped. An attacker with command execution in the shell can use "enable -f" for runtime loading of a new builtin, which can be a shared object that calls setuid() and therefore regains privileges. However, binaries running with an effective UID of 0 are unaffected.
Bash could allow a remote authenticated attacker to execute arbitrary commands on the system, caused by the failure to prevent the shell user from modifying BASHCMDS in the rbash. By modifying BASHCMDS, an attacker could exploit this vulnerability to execute arbitrary commands on the system with the permissions of the shell.
A heap-based buffer overflow exists in GNU Bash before 4.3 when wide characters, not supported by the current locale set in the LCCTYPE environment variable, are printed through the echo built-in function. A local attacker, who can provide data to print through the "echo -e" built-in function, may use this flaw to crash a script or execute code with the privileges of the bash process. This occurs because ansicstr() in lib/sh/strtrans.c mishandles u32cconv().
A vulnerability was found in a way bash expands the $HOSTNAME. Injecting the hostname with malicious code would cause it to run each time bash expanded \h in the prompt string.
References:
http://seclists.org/oss-sec/2016/q3/528
Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1507025
The /etc/profile.d/60alias.sh script in the Mandriva bash package for Bash 2.05b, 3.0, 3.2, 3.2.48, and 4.0 enables the --show-control-chars option in LSOPTIONS, which allows local users to send escape sequences to terminal emulators, or hide the existence of a file, via a crafted filename.
Stack-based buffer overflow in lib/sh/eaccess.c in GNU Bash before 4.2 patch 33 might allow local users to bypass intended restricted shell access via a long filename in /dev/fd, which is not properly handled when expanding the /dev/fd prefix.
The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the "redirstack" issue.
Off-by-one error in the readtokenword function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "wordlineno" issue.
GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code or cause a denial of service (uninitialized memory access, and untrusted-pointer read and write operations) via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the modcgi and modcgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169.
A security flaw was found in bash, which could be exploited remotely via applications which parse untrusted user scripts via bash. This flaw is different from CVE-2014-6277, CVE-2014-7169 and CVE-2014-7186.
A vulnerability was found in a way bash expands the $HOSTNAME. Injecting the hostname with malicious code would cause it to run each time bash expanded \h in the prompt string.
References:
http://seclists.org/oss-sec/2016/q3/528
Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1507025