Environment-variable command injection enables arbitrary code execution in GNU Bash

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid 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, aka "ShellShock." NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

• GNU Bash: Releases through and including 4.3 are recorded as affected.
• Arista EOS: NVD lists affected intervals from 4.9.0 through before 4.9.12, 4.10.0 through before 4.10.9, 4.11.0 through before 4.11.11, 4.12.0 through before 4.12.9, 4.13.0 through before 4.13.9, and 4.14.0 through before 4.14.4f.
• Oracle Linux: Versions 4, 5, and 6 are recorded as affected.
• QNAP QTS: Versions before 4.1.1 are recorded as affected; the record also contains separate affected entries for 4.1.1 and 4.1.1 build 0927.
• Mageia: 3.0 and 4.0 are affected. SUSE and openSUSE: SUSE Studio Onsite 1.3, openSUSE 12.3, 13.1, and 13.2, Linux Enterprise Desktop 11 and 12, Linux Enterprise Server 10 SP3, 10 SP4, 11 SP1, 11 SP2, 11 SP3, and 12, and Linux Enterprise Software Development Kit 11 and 12 are recorded as affected.
• Debian: Debian Linux 7.0 is affected.
• Red Hat: The record includes Gluster Storage Server for on-premise 2.1, Virtualization 3.4, Enterprise Linux branches 4.0 through 7.0, Desktop branches 5.0 through 7.0, Server branches 5.0 through 7.0, Workstation branches 5.0 through 7.0, Scientific Computing 6.0 and 7.0, and EUS, AUS, TUS, RHUI, IBM z Systems, and Power variants with the versions listed in the structured record.
• IBM: InfoSphere Guardium Database Activity Monitoring 8.2, 9.0, and 9.1; PureApplication System with wildcard entries and 2.0.0.0; QRadar Risk Manager 7.1.0; QRadar Security Information and Event Manager 7.1.0, 7.1.1, and 7.1.2; and QRadar Vulnerability Manager 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.6, and 7.2.8 are recorded as affected.
• Several entries are package, build, or wildcard CPE records and do not provide a fixed boundary. The status of parallel or later branches must not be inferred without vendor confirmation.

GNU Bash processes trailing text after function definitions when importing functions from environment variable values. If an attacker can cause a service or client to set a crafted environment variable and then invoke Bash, that trailing text can be executed as arbitrary commands.

The documented attack paths include the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in Apache HTTP Server, scripts run by DHCP clients, and other cases where environment data crosses a privilege boundary before Bash is executed. Actual reachability depends on whether the product invokes Bash, how environment variables are propagated, and the privileges of the calling process.

This is OS command injection leading to arbitrary code execution. If Bash runs with higher privileges than the source of the input, attacker-controlled code may execute in the context of that process and potentially cross a privilege boundary. The precise implementation and call path for each appliance, distribution, or integrated product are not fully established by the record.

• Reachability: Remote exploitation is possible when an attacker can control or influence an environment variable before a service or client invokes Bash. The record identifies indirect paths through SSH, CGI, and DHCP; other paths depend on deployment.
• Authentication and interaction: The network vector in the record models a case requiring no prior privileges and no user interaction, but individual products can impose additional conditions. A public exploit record describes a product-specific path that required an authenticated user to reach SSH processing of environment variables.
• Complexity: The record characterizes exploitation as low complexity.
• Public exploitation status: The record marks the vulnerability as known exploited and as having a public exploit. This does not establish that every affected product or configuration has the same reachability.
• The initial remediation was incomplete, so applying an early Bash update does not by itself prove that a system is protected.

The vulnerability allows arbitrary code execution in the context of Bash or the process that invokes Bash. Through a suitable network path, an attacker may obtain the privileges of an SSH service, web service, DHCP script, or other caller; the actual privilege level depends on configuration and is not automatically administrative.

If the process can access sensitive data or important system functions, consequences could include reading data, changing files and configuration, altering service behavior, establishing persistence, or causing an outage. Some product paths may require authentication or other product-specific conditions, so the unauthenticated network model should not be applied to every deployment. Sandboxing, container boundaries, account permissions, or product isolation may limit impact, but the record does not establish those limits for each affected product.

• SSH services, web CGI handlers, DHCP clients, and other components can become entry points for remote code execution if they pass crafted environment data into Bash.
• If code runs with the privileges of a service or administrative account, an attacker could expose data, modify configuration, alter applications, or disrupt service operation.
• Appliances and packaged products may require a separate firmware or product update because updating the operating system's Bash package may not update an embedded copy.
• Because the record confirms exploitation and a public exploit, organizations should prioritize inventory, path analysis, and vendor-specific remediation rather than wait for signs of compromise.

1. Apply the vendor update first. Update Bash or the firmware, image, and product release that contains Bash according to each vendor's guidance. A patch is available according to the record, but no single fixed release applies to every distribution and appliance.
2. For Arista EOS, use the recorded branch boundaries as version checks: 4.9.12, 4.10.9, 4.11.11, 4.12.9, 4.13.9, and 4.14.4f. Confirm with the vendor that the corresponding update is deployed for the correct branch and model.
3. For Oracle Linux, Red Hat, SUSE, Debian, QNAP, Mageia, IBM, and other integrated products, follow the relevant vendor erratum and verify the package or firmware revision. Do not assume that updating the operating system's Bash package also updates a product-embedded copy.
4. If immediate patching is not possible, temporarily reduce paths that allow untrusted data to enter Bash's environment, especially through SSH, CGI, DHCP clients, and integrations crossing a privilege boundary. This is temporary exposure reduction, not a patch replacement.
5. Revalidate after updating because the record states that the initial fix was incorrect. Applying the first update or checking one host is not evidence that an entire fleet is remediated.

1. Inventory Bash across servers, images, appliances, and integrated products, including copies not managed directly by the operating system.
2. Compare installed packages or firmware with vendor advisories and distribution backport status. Do not rely only on the shell's displayed version because vendors may backport the fix.
3. Identify services that can pass attacker-controlled data into the environment of a Bash process, especially OpenSSH sshd with ForceCommand, Apache mod_cgi or mod_cgid, DHCP client scripts, and integrations that cross a privilege boundary.
4. As a precaution, review process-creation telemetry for unexpected children of sshd, Apache CGI workers, or DHCP client processes. This is a defensive review signal, not a confirmed product-independent IOC.
5. Review unexpected changes to accounts, configuration, files, and services on systems that ran affected Bash builds. The available evidence does not establish one universal IOC for all products.