- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 11
- Public CVEs
- 14
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
11 assets you may test, 6 excluded.
Web 1
- https://getcomposer.org
Products and areas 10
- Archive download and extraction for zip and tar distributions, including path handling on unpack
- Credential and token handling in auth.json and COMPOSER_AUTH, plus the OAuth flows for GitHub, GitLab and Bitbucket
- Dependency resolution end to end: the solver, constraint handling and everything that decides which version of which package an install lands on
- Integrity and authenticity checking on downloaded artefacts, plus the composer.lock format and what a lock entry is taken to guarantee on a later install
- Package metadata handling, covering every field Composer reads out of a composer.json or out of a repository's JSON, whichever repository served it
- Script and plugin execution: scripts entries, composer-plugin packages and custom installers, all of which run with the privileges of the build
- The autoloader generator and everything it writes into vendor/
- The HTTP layer, TLS verification and proxy handling, and the self-update path with the signature checks on a replacement binary
- The published policy asks for anything with security implications to go privately to [email protected], and draws no line narrower than the Composer codebase itself
- The VCS drivers, including Git, Mercurial, Subversion, Fossil and Perforce, and every place a repository-supplied value reaches a process invocation
Out of scope (6)
- Libraries Composer depends on, unless Composer's own use of one is what makes the defect reachable
- Malicious packages published to Packagist, which is registry abuse rather than a defect in Composer
- packagist.org as a service and Private Packagist as a product, unless the defect is in how Composer handles what they return
- PHP the language and its interpreter, a separate project under separate governance with its own reporting path
- Public reports: the policy asks explicitly for private reporting and treats anything else as a disclosure failure
- Third-party Composer plugins that are not part of the composer/composer tree
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz.
-
Send the report privately to the address on the policy page , the address the security policy names.
-
Do not report publicly.
-
Include the composer.json , the composer.lock and the repository entry, plus the exact command.
-
Say which VCS driver was involved and whether the package came from Packagist or from a custom repository
Not accepted
-
PHP the language and its interpreter
-
packagist.org as a service and Private Packagist as a product
-
Malicious packages published to Packagist
-
Third-party Composer plugins that are not part of the composer/composer tree
-
Public reports
-
Libraries Composer depends on
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-40261 | Composer is a dependency manager for PHP. Versions 1.0 through 2.2.26 and 2.3 through 2.9.5 contain a command injection vulnerability in the Perforce::syncCodeBase() method, which appends the $sourceReference parameter to a shell command without proper escaping, and additionally in the Perforce::generateP4Command() method as in GHSA-wg36-wvj6-r67p / CVE-2026-40176, which interpolates user-supplied | High 8.8 | 15 Apr 2026 |
| CVE-2026-40176 | Composer is a dependency manager for PHP. Versions 1.0 through 2.2.26 and 2.3 through 2.9.5 contain a command injection vulnerability in the Perforce::generateP4Command() method, which constructs shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping. An attacker can inject arbitrary commands through these values in a malicious com | High 7.8 | 15 Apr 2026 |
| CVE-2025-67746 | Composer is a dependency manager for PHP. In versions on the 2.x branch prior to 2.2.26 and 2.9.3, attackers controlling remote sources that Composer downloads from might in some way inject ANSI control characters in the terminal output of various Composer commands, causing mangled output and potentially leading to confusion or DoS of the terminal application. There is no proven exploit and this h | Low 1.3 | 30 Dec 2025 |
| CVE-2024-24821 | Composer is a dependency Manager for the PHP language. In affected versions several files within the local working directory are included during the invocation of Composer and in the context of the executing user. As such, under certain conditions arbitrary code execution may lead to local privilege escalation, provide lateral user movement or malicious code execution when Composer is invoked with | High 8.8 | 9 Feb 2024 |
| CVE-2023-43655 | Composer is a dependency manager for PHP. Users publishing a composer.phar to a public web-accessible server where the composer.phar can be executed as a php file may be subject to a remote code execution vulnerability if PHP also has `register_argc_argv` enabled in php.ini. Versions 2.6.4, 2.2.22 and 1.10.27 patch this vulnerability. Users are advised to upgrade. Users unable to upgrade should ma | Medium 6.4 | 29 Sep 2023 |
| CVE-2015-8371 | Composer before 2016-02-10 allows cache poisoning from other projects built on the same host. This results in attacker-controlled code entering a server-side build process. The issue occurs because of the way that dist packages are cached. The cache key is derived from the package name, the dist type, and certain other data from the package repository (which may simply be a commit hash, and thus c | High 8.8 | 21 Sep 2023 |
| CVE-2022-24828 | Composer is a dependency manager for the PHP programming language. Integrators using Composer code to call `VcsDriver::getFileContent` can have a code injection vulnerability if the user can control the `$file` or `$identifier` argument. This leads to a vulnerability on packagist.org for example where the composer.json's `readme` field can be used as a vector for injecting parameters into hg/Mercu | High 8.3 | 13 Apr 2022 |
| CVE-2021-41116 | Composer is an open source dependency manager for the PHP language. In affected versions windows users running Composer to install untrusted dependencies are subject to command injection and should upgrade their composer version. Other OSs and WSL are not affected. The issue has been resolved in composer versions 1.10.23 and 2.1.9. There are no workarounds for this issue. | High 8.2 | 5 Oct 2021 |
| CVE-2021-29472 | Composer is a dependency manager for PHP. URLs for Mercurial repositories in the root composer.json and package source download URLs are not sanitized correctly. Specifically crafted URL values allow code to be executed in the HgDriver if hg/Mercurial is installed on the system. The impact to Composer users directly is limited as the composer.json file is typically under their own control and sour | High 8.8 | 27 Apr 2021 |
| CVE-2020-15145 | In Composer-Setup for Windows before version 6.0.0, if the developer's computer is shared with other users, a local attacker may be able to exploit the following scenarios. 1. A local regular user may modify the existing `C:\ProgramData\ComposerSetup\bin\composer.bat` in order to get elevated command execution when composer is run by an administrator. 2. A local regular user may create a specially | Medium 6.7 | 14 Aug 2020 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 7 Last 12 months 14 Lifetime Command execution 45 % Parsing/validation 25 % Credential exposure 20 % Integrity bypass 10 % Latest advisories Loading the feed Overview Composer resolves and installs the dependencies of essentially every modern PHP application, so it runs behind Laravel, Symfony, Drupal and Magento deployments and the large slice of the web those still serve. It executes during deploys and in CI with the privileges of the build. The class that has hurt this project before is registry to remote code execution: package metadata or a VCS URL reaching shell execution while an install runs, so one poisoned entry executes on every machine that pulls it. No platform carries a Composer program and Packagist runs none either, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for anything with security implications to go privately to [email protected] , and draws no line narrower than the Composer codebase itself Dependency resolution end to end: the solver, constraint handling and everything that decides which version of which package an install lands on Package metadata handling, covering every field Composer reads out of a composer.json or out of a repository's JSON, whichever repository served it The VCS drivers, including Git, Mercurial, Subversion, Fossil and Perforce, and every place a repository-supplied value reaches a process invocation Archive download and extraction for zip and tar distributions, including path handling on unpack Integrity and authenticity checking on downloaded artefacts, plus the composer.lock format and what a lock entry is taken to guarantee on a later install Script and plugin execution: scripts entries, composer-plugin packages and custom installers, all of which run with the privileges of the build The autoloader generator and everything it writes into vendor/ Credential and token handling in auth.json and COMPOSER_AUTH , plus the OAuth flows for GitHub, GitLab and Bitbucket The HTTP layer, TLS verification and proxy handling, and the self-update path with the signature checks on a replacement binary Out of scope PHP the language and its interpreter, a separate project under separate governance with its own reporting path packagist.org as a service and Private Packagist as a product, unless the defect is in how Composer handles what they return Malicious packages published to Packagist, which is registry abuse rather than a defect in Composer Third-party Composer plugins that are not part of the composer/composer tree Public reports: the policy asks explicitly for private reporting and treats anything else as a disclosure failure Libraries Composer depends on, unless Composer's own use of one is what makes the defect reachable Most-valued findings Anything that gets from package metadata or a repository URL to command execution during an install or update. This is the shape of the worst findings in Composer's history: the registry says something, Composer hands it to a shell, and every pipeline that installs the package runs it VCS driver handling where a branch name, a tag, a reference or a repository URL reaches an argument list or a shell without being neutralised Extraction defects that write outside the target directory, which on a deploy host means writing into the running application tree Integrity gaps where the artefact installed differs from what the lock file pinned, since the lock is the only thing a reviewer checks Credential handling that sends an auth token to a host other than the one it was configured for, because Composer holds private repository tokens on every CI runner it touches Plugin and script execution that fires earlier or more broadly than the user asked for, since plugin code runs before any of the application's own review gates Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send the report privately to [email protected] , the address the security policy names. GitHub private vulnerability reporting on composer/composer is enabled as a second private route Do not report publicly. The policy says so in as many words, and a public issue against a package manager is a working exploit aimed at every deploy pipeline that runs it Composer is governed separately from PHP itself. A defect in the interpreter belongs to the PHP project and has a different, paid, home Include the composer.json , the composer.lock and the repository entry, plus the exact command. The severe findings here turn on what a package or a repository declares rather than on an unusual build Say which VCS driver was involved and whether the package came from Packagist or from a custom repository, since the driver layer is where metadata meets process invocation There is no bounty on any platform and no reward terms to accept Disclosure Coordinated privately with the maintainers through [email protected] , with fixes shipped as a release and written up as a GitHub Security Advisory. The policy sets no response target and no day count, so agree the embargo in the thread. PHP applications update Composer itself slowly and pin it in CI images, so downstream deserves a release cycle before any writeup. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability