- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 5
- 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
12 assets you may test, 6 excluded.
Web 1
- https://python-poetry.org
Products and areas 11
- Credential handling in full: poetry config storage, the keyring integration, environment-variable credentials and the tokens poetry publish uses
- poetry build and poetry publish, including the metadata they generate and the credentials they carry
- poetry.lock handling, covering the format, the hashes it records and what a lock entry is taken to guarantee on a later install
- Poetry publishes no policy and no scope statement. The private reporting channel takes vulnerabilities in Poetry's own code, and nothing narrower than that has ever been written down
- Source and index configuration, covering multiple sources, source priorities and how Poetry chooses between a private index and PyPI
- The dependency resolver and everything that decides which version of which package is installed
- The HTTP and artefact caches, and anything that lets one install seed content a later install trusts
- The plugin system and poetry self add, which install third-party code into the environment Poetry itself runs from
- The repository client: metadata fetching, the simple and JSON index APIs, redirect handling and TLS verification
- Virtual environment creation and the paths, scripts and entry points Poetry writes into it
- Wheel and source distribution download, extraction and file placement, including path handling on unpack
Out of scope (6)
- Executing a source distribution's build code, which is what installing an sdist means in Python packaging
- Malicious packages published to PyPI, which is registry abuse rather than a Poetry defect
- pip, setuptools and the rest of the packaging stack Poetry sits on top of
- poetry-core, the build backend, which is a separate repository with its own release cycle
- PyPI itself and the Warehouse codebase behind it
- Third-party Poetry plugins that are not maintained under the python-poetry organisation
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.
-
Use GitHub private vulnerability reporting on python-poetry/poetry , the report button on the repository's security tab, confirmed enabled through the GitHub API
-
Write the report to stand entirely on its own
-
Poetry, poetry-core and the installer are separate repositories under the same organisation. Say which one the defect lives in
-
Include the pyproject.toml , the poetry.lock and the source configuration, since resolution and index handling carry most of the real surface
Not accepted
-
Malicious packages published to PyPI, which is registry abuse rather than a Poetry defect
-
Executing a source distribution's build code, which is what installing an sdist means in Python packaging
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-34591 | Poetry is a dependency manager for Python. From version 1.4.0 to before version 2.3.3, a crafted wheel can contain ../ paths that Poetry writes to disk without containment checks, allowing arbitrary file write with the privileges of the Poetry process. It is reachable from untrusted package artifacts during normal install flows. (Normally, installing a malicious wheel is not sufficient for executi | High 7.1 | 2 Apr 2026 |
| CVE-2022-42966 | An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the cleo PyPI package, when an attacker is able to supply arbitrary input to the Table.set_rows method | Medium 5.9 | 9 Nov 2022 |
| CVE-2022-36069 | Poetry is a dependency manager for Python. When handling dependencies that come from a Git repository instead of a registry, Poetry uses various commands, such as `git clone`. These commands are constructed using user input (e.g. the repository URL). When building the commands, Poetry correctly avoids Command Injection vulnerabilities by passing an array of arguments instead of a command string. H | High 7.3 | 7 Sep 2022 |
| CVE-2022-36070 | Poetry is a dependency manager for Python. To handle dependencies that come from a Git repository, Poetry executes various commands, e.g. `git config`. These commands are being executed using the executable’s name and not its absolute path. This can lead to the execution of untrusted code due to the way Windows resolves executable names to paths. Unlike Linux-based operating systems, Windows searc | High 7.3 | 7 Sep 2022 |
| CVE-2022-26184 | Poetry v1.1.9 and below was discovered to contain an untrusted search path which causes the application to behave in unexpected ways when users execute Poetry commands in a directory containing malicious content. This vulnerability occurs when the application is ran on Windows OS. | Critical 9.8 | 21 Mar 2022 |
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 2 Last 12 months 4 Lifetime Dependency confusion 35 % Credential exposure 25 % Parsing/validation 25 % Path handling 15 % Latest advisories Loading the feed Overview Poetry manages dependencies and packaging for a very large share of existing Python projects, running in developer environments and on CI with the privileges of the build. Its resolver decides which artefact from which index ends up installed, so the class that costs most is index confusion: a package served by the public registry when the operator meant it to come from a private one, which is the mechanism behind real corporate compromises. Poetry publishes no security policy at all, though private vulnerability reporting on the repository is enabled and working. There is no company behind it and no money anywhere, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Poetry publishes no policy and no scope statement. The private reporting channel takes vulnerabilities in Poetry's own code, and nothing narrower than that has ever been written down The dependency resolver and everything that decides which version of which package is installed Source and index configuration, covering multiple sources, source priorities and how Poetry chooses between a private index and PyPI The repository client: metadata fetching, the simple and JSON index APIs, redirect handling and TLS verification poetry.lock handling, covering the format, the hashes it records and what a lock entry is taken to guarantee on a later install Wheel and source distribution download, extraction and file placement, including path handling on unpack Credential handling in full: poetry config storage, the keyring integration, environment-variable credentials and the tokens poetry publish uses The HTTP and artefact caches, and anything that lets one install seed content a later install trusts Virtual environment creation and the paths, scripts and entry points Poetry writes into it The plugin system and poetry self add , which install third-party code into the environment Poetry itself runs from poetry build and poetry publish , including the metadata they generate and the credentials they carry Out of scope poetry-core, the build backend, which is a separate repository with its own release cycle pip, setuptools and the rest of the packaging stack Poetry sits on top of Malicious packages published to PyPI, which is registry abuse rather than a Poetry defect PyPI itself and the Warehouse codebase behind it Third-party Poetry plugins that are not maintained under the python-poetry organisation Executing a source distribution's build code, which is what installing an sdist means in Python packaging Most-valued findings Dependency confusion between a configured private source and PyPI, in either direction. The research names index and URL resolution first for this project, and the class has a real-world compromise record behind it Credential handling that writes a token somewhere readable, keeps it after it should be gone, or sends it to a host other than the one it was configured for. Poetry holds publishing tokens and private-index credentials on CI runners Lockfile defects where the artefact installed differs from what the lock pinned, or where a hash mismatch is tolerated rather than fatal Extraction paths that write outside the target directory during an install, which on CI runs as whatever the pipeline runs as Cache poisoning, where one install seeds an artefact a later install accepts without rechecking it Anything in poetry self add or the plugin loader that gets third-party code into Poetry's own environment more easily than the user intended, since that code then runs on every subsequent command 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. Use GitHub private vulnerability reporting on python-poetry/poetry , the report button on the repository's security tab, confirmed enabled through the GitHub API There is no SECURITY.md. GitHub's security tab says as much, so expect no scope statement, no response commitment and no published process. Write the report to stand entirely on its own Nobody is paid to triage this. Responsiveness is unproven, so plan for a slower thread than a vendor-backed project would give you Poetry, poetry-core and the installer are separate repositories under the same organisation. Say which one the defect lives in Include the pyproject.toml , the poetry.lock and the source configuration, since resolution and index handling carry most of the real surface There is no bounty and no vendor. This is community maintained with nothing to negotiate Disclosure Coordinated through GitHub private vulnerability reporting, the only channel this project has. With no published policy there is no stated timeline, no triage commitment and no advisory cadence to anchor to, so treat the embargo as something to agree with the maintainers inside the thread. Fixes ship as an ordinary release, and Poetry is pinned into a lot of CI images, so downstream adoption is slower than the release cadence suggests. 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