Composer 2.11.2 Fixes Command Execution and Credential Exposure Flaws

Maintainers of the PHP dependency manager Composer released version 2.11.2 on 10 November 2026, addressing a high-severity flaw that could allow command execution when attackers control certain dependency metadata. The update also addresses malicious ZIP archive extraction, repository credential exposure and several other security weaknesses. A separate release, Composer 2.2.32, provides security fixes for the long-term support branch.

The vulnerabilities affect the tooling used to install and update PHP applications, including Drupal projects. The command-execution flaw is particularly relevant to continuous integration (CI) environments that install dependencies from unreviewed pull requests or restore untrusted package metadata from caches. The published advisories identify specific conditions for exploitation and do not establish that Drupal installations have been compromised.

Crafted Lock Files Could Trigger Command Execution

The security advisory GHSA-jhfp-4ppm-crmm identifies a vulnerability affecting Composer 2.10.0 through 2.11.1, but not the Composer 2.2 long-term support branch. The flaw allowed the transport-options.prevent_url_access_callable setting to be loaded from composer.lock or vendor/composer/installed.json, potentially triggering arbitrary command execution during dependency downloads.

Exploitation requires an attacker to influence one of those metadata files, for example through a pull request modifying the lock file or a compromised CI cache. According to the advisory, the attack does not require malicious package scripts or plugins to execute. Disabling those mechanisms using --no-scripts and --no-plugins does not prevent this attack path. The vulnerability carries a CVSS score of 8.8 and is fixed in Composer 2.11.2. The separate Composer 2.2 LTS release does not address this flaw because that branch is not affected.

Archive Extraction and Repository Credentials Also Affected

A second advisory, GHSA-w6hj-6587-3jh5, addresses arbitrary file writes caused by specially crafted ZIP archives. When archive extraction falls back from the system unzip utility to PHP's ZipArchive, malicious symbolic-link entries could cause files to be written outside the intended package directory. Overwriting an application entry point or another executable file could subsequently lead to code execution.

The high-severity vulnerability, rated 8.8 under CVSS, affects Composer 1.0.0 through 2.2.31 on the older branch and Composer 2.3.0 through 2.11.1 on the newer branch. Exploitation requires an attacker-controlled distribution archive and an environment containing both the unzip command and PHP ZIP extension, with extraction falling back to ZipArchive. Composer identifies untrusted repositories and distribution mirrors as relevant attack paths, while describing typical installations using trusted Packagist packages as unlikely to encounter malicious archives of this kind. The fixes are available in versions 2.11.2 and 2.2.32.

The third advisory, GHSA-x82q-x274-r6pq, concerns the disclosure of inline repository credentials. Composer 2.11.0, 2.11.1 and 2.2.31 could send secret-bearing HTTP headers to an attacker-controlled distribution mirror referenced in manipulated dependency metadata. Exploitation requires a repository configured with inline authentication headers and attacker influence over composer.lock or vendor/composer/installed.json. The vulnerability carries a moderate CVSS score of 6.5 and does not involve command execution or file modification.

Further Fixes Address Authentication and Configuration

Composer 2.11.2 includes additional security corrections beyond the three newly published Composer advisories. One prevents Authorization and Cookie headers supplied in request options from being forwarded when a download redirects to another origin. Another restricts the configuration values accepted from a project's auth.json file and the COMPOSER_AUTH environment variable, preventing non-authentication settings from overriding ordinary Composer configuration. The update also prevents a project's composer.json from changing the Composer home directory used to locate global configuration and plugins.

The release additionally improves blocked-IP checks and cancellation of rejected downloads. It also updates the bundled symfony/filesystem component to address a separately disclosed Symfony path-handling vulnerability. Updating Composer's bundled component does not automatically update Symfony dependencies installed within a Drupal project.

The Composer 2.2.32 release includes fixes for malicious archive extraction, repository credential disclosure, cross-origin redirect headers and unsafe configuration handling. The command-execution vulnerability and certain other corrections listed for Composer 2.11.2 do not apply to the LTS release.

What Drupal Development Teams Should Check

Drupal development teams should verify the Composer executable used on developer workstations, inside containers and in automated deployment pipelines. Running composer --version identifies the installed release. Teams using a self-managed Composer installation can update it with composer self-update --stable, while installations managed through operating-system packages or container images may require a package or image update.

Version compatibility also matters. Drupal's published Composer requirements specify version 2.3.6 or higher for Drupal 10 and 2.7.0 or higher for Drupal 11. Composer 2.2.32 LTS falls below both requirements and should not be treated as an interchangeable replacement for Composer 2.11.2 in those environments.

Teams running Composer against untrusted pull-request branches should review changes to composer.lock, control access to package repositories and examine whether CI caches can introduce manipulated installed-package metadata. Build jobs handling untrusted contributions should also be separated from repository credentials and deployment privileges wherever possible. Running composer audit can help identify vulnerable project dependencies, but it does not replace checking the Composer executable itself; an unaffected project lock file does not establish that the installed Composer binary is patched.

Updating Composer is also distinct from running composer update against a Drupal project, which can change resolved dependencies and the lock file. The official Composer download page provides the patched releases, while the security advisories document affected versions and exploitation requirements. These disclosures concern the Composer tool and dependency-installation environments; they are not newly disclosed vulnerabilities in Drupal core. The advisories do not establish exploitation against Drupal projects.