- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 16
- 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.
- Replies within 2 days
- As the policy promises.
- 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 |
- Response
-
Within 2 days
its policy asks for reports through a GitHub advisory with a 48-hour acknowledgement
- 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, 5 excluded.
Web 1
- https://cryptography.io
Products and areas 11
- Key and certificate serialisation in every format the library reads or writes, including PEM, DER, PKCS#8, PKCS#12 and the OpenSSH key formats
- The asymmetric implementations and the parameter and point validation around them, spanning RSA, DSA, the elliptic curve families, Ed25519 and X25519
- The build and release tooling that produces the wheels, where a supply chain defect reaches every consumer at once
- The Fernet recipe layer, which is the high-level API most application code actually calls
- The hazmat primitive layer, covering the ciphers and their modes, AEAD tag verification, the hash and MAC families, and the key derivation functions
- The OpenSSL binding surface, covering error handling, memory ownership and every place a return value from the C library is interpreted
- The OpenSSL build vendored into the published binary wheels, since a defect in it ships to anyone who installed from PyPI
- The published policy asks for any suspected security issue in the library through the GitHub advisory channel and draws no boundary narrower than the project itself, so the whole tree is the target
- The Rust extension and the boundary between it and the Python layer, where a check enforced on one side may be absent on the other
- The two-factor primitives, TOTP and HOTP, and their verification behaviour
- The x509 module in full: certificate and CSR parsing, chain building, path validation, name constraints, SAN handling, CRL and OCSP
Out of scope (5)
- Caller misuse of the hazmat layer, which is documented as requiring the caller to know what they are doing
- Defects in a consuming library such as Ansible, Paramiko or PyOpenSSL rather than in this project
- Findings against releases outside the project's supported window
- OpenSSL defects reported against a system OpenSSL the user chose to link, which belong upstream with the OpenSSL project
- Weaknesses in a standardised algorithm rather than in this implementation of it
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report privately at github.com/pyca/cryptography/security/advisories/new, the channel the documentation names; private vulnerability reporting is enabled on the repository
-
Say whether the defect is in this project's Python and Rust code or in the OpenSSL it links against.
-
Name the installation path. A wheel from PyPI carries a statically linked OpenSSL, while a distribution package links the system one, and a finding may only exist in one of those
-
Give the version of the Rust extension in play.
-
Hold the detail until the advisory and the release are both out.
Not accepted
-
Defects in a consuming library such as Ansible, Paramiko or PyOpenSSL rather than in this project
-
Caller misuse of the hazmat layer, which is documented as requiring the caller to know what they are doing
-
Weaknesses in a standardised algorithm rather than in this implementation of it
-
OpenSSL defects reported against a system OpenSSL the user chose to link, which belong upstream with the OpenSSL project
-
Findings against releases outside the project's supported window
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-2018-10903 | A flaw was found in python-cryptography versions between >=1.9.0 and <2.3. The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause | High 7.5 | 30 Jul 2018 |
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 4 Last 12 months 16 Lifetime Cryptographic validation 32 % Certificate validation 28 % Memory safety 24 % Bundled OpenSSL 16 % Latest advisories Loading the feed Overview pyca/cryptography is the library almost every Python program uses when it touches a certificate, a JWT or a TLS connection. It sits under Ansible, Paramiko, PyOpenSSL and the cloud SDKs, so it arrives as a transitive dependency in build pipelines that never chose it. CVE-2026-26007 is the reference point: missing SECT curve validation left the library open to a subgroup attack against keys it was supposed to protect. The project is funded by grants and one-off audits and has never run a bounty, and its policy asks for reports through a GitHub advisory with a 48-hour acknowledgement. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for any suspected security issue in the library through the GitHub advisory channel and draws no boundary narrower than the project itself, so the whole tree is the target The x509 module in full: certificate and CSR parsing, chain building, path validation, name constraints, SAN handling, CRL and OCSP The hazmat primitive layer, covering the ciphers and their modes, AEAD tag verification, the hash and MAC families, and the key derivation functions The asymmetric implementations and the parameter and point validation around them, spanning RSA, DSA, the elliptic curve families, Ed25519 and X25519 Key and certificate serialisation in every format the library reads or writes, including PEM, DER, PKCS#8, PKCS#12 and the OpenSSH key formats The Fernet recipe layer, which is the high-level API most application code actually calls The Rust extension and the boundary between it and the Python layer, where a check enforced on one side may be absent on the other The OpenSSL binding surface, covering error handling, memory ownership and every place a return value from the C library is interpreted The OpenSSL build vendored into the published binary wheels, since a defect in it ships to anyone who installed from PyPI The two-factor primitives, TOTP and HOTP, and their verification behaviour The build and release tooling that produces the wheels, where a supply chain defect reaches every consumer at once Out of scope Defects in a consuming library such as Ansible, Paramiko or PyOpenSSL rather than in this project Caller misuse of the hazmat layer, which is documented as requiring the caller to know what they are doing Weaknesses in a standardised algorithm rather than in this implementation of it OpenSSL defects reported against a system OpenSSL the user chose to link, which belong upstream with the OpenSSL project Findings against releases outside the project's supported window Most-valued findings Missing validation on cryptographic inputs, the highest-severity class this project has produced. CVE-2026-26007 skipped SECT curve validation and opened a subgroup attack, meaning a peer-supplied point could extract information about a private key Certificate validation that accepts a chain it should reject. CVE-2026-34073 bypassed name constraints through wildcard SANs, which turns a constrained intermediate into an unconstrained one Memory corruption in the binding or the Rust extension reachable from Python-level input, the shape CVE-2026-39892 took with non-contiguous buffers. This is a memory safety bug in a language most callers assume protects them from one Anything in the wheel build that ships a vulnerable or misconfigured OpenSSL, the class CVE-2026-34180 fell into, since the wheel is how the overwhelming majority of users get this library Parsing defects in the serialisation formats, particularly PKCS#12 and the OpenSSH key formats, where the input frequently arrives from somewhere untrusted Divergence between the Rust and Python implementations of the same check, since only one of the two paths tends to receive close review Anything that lets a Fernet token be forged or decrypted without the key, because Fernet is the API used by developers who chose it precisely to avoid handling primitives 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. Report privately at github.com/pyca/cryptography/security/advisories/new, the channel the documentation names; private vulnerability reporting is enabled on the repository The policy lives in the documentation at cryptography.io rather than in a SECURITY.md, so GitHub's security tab will tell you there is no policy. There is one, and it commits to acknowledging a report within 48 hours Say whether the defect is in this project's Python and Rust code or in the OpenSSL it links against. Both are reportable here, because the binary wheels ship OpenSSL inside them Name the installation path. A wheel from PyPI carries a statically linked OpenSSL, while a distribution package links the system one, and a finding may only exist in one of those Give the version of the Rust extension in play. A large part of the x509 and serialisation surface moved into Rust and behaves differently from the older binding code The project is grant and audit funded and pays nothing for a report, so there is no reward to negotiate Disclosure Coordinated through GitHub private vulnerability reporting and published as a GitHub Security Advisory alongside a release on PyPI. Sixteen advisories over the project's life with four in the last year makes this an active and practised pipeline. The awkward part of the embargo is downstream: this package is pinned in an enormous number of lockfiles, so a fix reaching PyPI does not mean a fix reaching users. Hold the detail until the advisory and the release are both out. 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