Update dependency composer/composer to ^2.10.2 [SECURITY]#999
Open
renovate[bot] wants to merge 1 commit into
Open
Update dependency composer/composer to ^2.10.2 [SECURITY]#999renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
| datasource | package | from | to | | ---------- | ----------------- | ----- | ------ | | packagist | composer/composer | 2.9.8 | 2.10.2 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^2.9.8→^2.10.2Composer: Arbitrary file write outside vendor via malicious transitive package name
CVE-2026-59948 / GHSA-499r-g7pc-vmp9
More information
Details
Summary
A maliciously crafted package, published on an untrusted third party repository other than Packagist.org or Private Packagist, can cause Composer to write files outside the
vendor/directory and outside your project, with attacker-controlled content, during a normalinstallorupdatethrough using an invalid package name, which was not correctly validated by Composer.This is an arbitrary file write that can be used to execute code outside the Composer project's context in which you expected the package code to execute (for example by writing shell startup files, SSH
authorized_keys, or a cron entry). It is a supply-chain issue: it requires a malicious or compromised package to be present in the dependency graph, it is not otherwise remotely exploitable against a machine.The fix makes Composer validate every package produced by dependency resolution before anything is written to
composer.lockor installed, and abort with a security error if a package name is not a validvendor/packagename.Am I affected?
You may be affected if you install packages from an untrusted third party repository, which does not sufficiently validate package names. Packagist.org and Private Packagist are safe, as they validate package names correctly.
Patched versions
Fixed in 2.2.29 and 2.10.2. Composer 1.x is also affected and you should move to a safe 2.x release.
Workarounds
Do not use untrusted package repositories. If you have to, mirror them through an internal repository like Private Packagist.
Severity
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Composer: URL-embedded HTTP-Basic username leaks to verbose logs (GitHub PAT exposure)
CVE-2026-59947 / GHSA-g6xq-892h-64w3
More information
Details
Summary
When Composer is run with -vvv (debug verbosity), it could print a credential that was embedded directly in a repository or package URL, but not as a password, to its debug output. Composer already masked the password portion of such URLs, but the username portion was shown in clear text. Because GitHub and several other services support placing an access token in the username position of a URL (for example https://[token]@github.com/owner/repo), a token used that way could end up written to the verbose log in full.
This is an information disclosure issue. The credential is only ever exposed to whoever can already read Composer's debug output.
Am I affected?
You are potentially affected only if all of the following apply:
repositoriesentry in composer.json, in a package dist/source URL - rather than being supplied through auth.json or the COMPOSER_AUTH environment variable.https://TOKEN@host/…). A normalusername:password@hostpair where the username is an ordinary account name did not expose the password, that was already masked.If you keep credentials in auth.json or environment variables, or you never run Composer at debug verbosity, you were not exposed.
The most realistic exposure is the documented pattern of embedding a GitHub Personal Access Token in a URL's username position on a machine (often CI) that captures verbose output.
Patched versions
The username is now masked the same way the password already was, so an embedded token no longer appears in verbose output (a short, non-secret prefix may be shown to aid debugging, but never the full value).
Fixed in Composer 2.10.2 and the 2.2.29.
Workarounds
There is no configuration setting that prevents outputting credentials while keeping normal behavior.
If you cannot upgrade right away, you can reduce exposure by:
Severity
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Composer: Path traversal in package bin field lets dependencies chmod arbitrary host files
CVE-2026-59946 / GHSA-gjfg-22fp-rrxx
More information
Details
Summary
A Composer package declares its executables in the
binfield of itscomposer.json. When Composer installs a package, it processes eachbinentry and changes the file mode of the corresponding file so it is executable.If a
binentry contains..path segments, it can resolve to a path outside the package's own install directory. A malicious package can use this to make Composer runchmodagainst a file that already exists elsewhere on the machine. The resulting mode is world-readable and world-executable (0755 under the common umask of 022). This happens when the package is installed, e.g. duringcomposer install,composer update, andcomposer require. Any dependency can trigger it, including a transitive dependency several levels deep.The vulnerability changes file permissions only, and does not read, modify, or execute the contents of the target file, and it is not remote code execution. The impact is to confidentiality: a file with deliberately restrictive permissions, such as a private key at mode 0600, can be made readable by other users on the same host.
Am I affected?
We reviewed packagist.org data and found no evidence that any published package exploited this vulnerability. If you install packages only from packagist.org, you are not affected by any known exploitation.
You are potentially affected if all of the following are true:
.envfiles,~/.aws/credentials, and.netrc.The most likely way to be affected is to add or update a dependency that is malicious or has been compromised, then run an install on a machine that holds sensitive, permission-restricted files.
Two points to note:
--no-scripts,--no-plugins, and anallow-pluginsallow-list do not prevent this. The permission change happens during normal binary installation, outside the plugin and script trust model.sudo composer install), any file on the system can be affected, including system credential stores.Patched versions
The fix makes Composer reject any package whose binary entry contains a
..path segment. During install/update the operation aborts before any file permission is changed, and the same check now also applies when a package is published to Packagist.org, so such packages are refused upstream.Fixed in 2.2.29 (2.2 LTS line) and 2.10.2 (current 2.x line). Composer 1.x is end of life and will not be patched. 1.x users should upgrade to a patched 2.x release.
Workarounds
Upgrading to a patched release is the only complete fix. There is no configuration option that disables the vulnerable behavior.
Severity
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
composer/composer (composer/composer)
v2.10.2Compare Source
auditcommand to output the audit result to stdout (#12904)v2.10.1Compare Source
source-fallbackalso disabling fallbacks to dist install when source is the preferred install method (#12888)v2.10.0Compare Source
source-fallbackconfig option as a temporary way to restore the old behavior, but if you need this talk to us as we plan to remove it entirely in 2.11 (#12885)auditconsumers, the exit code is now always 0 (success) or 1 if anything failed the audit (#12881)auditcommand returning a success code when the vendor dir was not present (#12880)Configuration
📅 Schedule: (in timezone UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
Read more about the use of Renovate Bot within
ocramius/*projects.