- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 8
- 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 14 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 14 days
The policy commits to a response within two weeks and offers no reward, so there is nothing to negotiate on payment
- 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://github.com/OpenSC/OpenSC
Products and areas 11
- Every card driver shipped in the tree, covering the national eID drivers, PIV and CAC, the OpenPGP card and the long tail of vendor-specific drivers, whether or not any of them has ever carried an advisory
- Key material handling, covering the key objects the module exposes, the operations performed on card and anything that could leak a key or a key attribute
- PIN handling in full: entry, verification, retry counters, the PIN pad reader paths and anything that could disclose or bypass a PIN
- The APDU layer and the response parsing underneath the drivers, including the TLV and compact TLV handling and the GET RESPONSE chaining
- The certificate and cryptographic object handling that turns card contents into something an application will trust
- The command line tools, pkcs11-tool, pkcs15-tool, opensc-tool, opensc-explorer and the rest, which parse card data and files supplied by someone else
- The minidriver and the platform integration layers where OpenSC plugs into an operating system's own smartcard stack
- The PKCS#11 module, which is the interface every consuming application talks to, including the object model, session handling and the login and logout paths
- The PKCS#15 layer and the file and object structures it reads from a card
- The policy states what it counts as a security issue and that list is the declared scope: memory safety defects, authentication and authorization bypass, cryptographic weakness, key or PIN disclosure, privilege escalation and remote code execution
- The reader layer and the PC/SC interaction, including how OpenSC behaves against a reader or a card that responds outside the specification
Out of scope (5)
- Attacks requiring invasive physical access to a card, such as fault injection or decapping
- Bundling several unrelated issues into one report, which the policy's one-advisory-per-issue rule rules out
- Defects in a card's own firmware or applet rather than in OpenSC's handling of it
- Defects in PC/SC-lite, in a reader driver, or in a consuming application rather than in OpenSC
- 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.
While testing
-
Submit through sorona.xyz.
-
Report through the Report a vulnerability flow on OpenSC/OpenSC
-
One advisory per issue.
-
Name the card and the driver.
-
Say whether the finding needs a hostile card or only hostile data from a legitimate one.
-
Hold the detail until the advisories are public.
Not accepted
-
Defects in a card's own firmware or applet rather than in OpenSC's handling of it
-
Defects in PC/SC-lite, in a reader driver, or in a consuming application rather than in OpenSC
-
Attacks requiring invasive physical access to a card, such as fault injection or decapping
-
Weaknesses in a standardised algorithm rather than in this implementation of it
-
Bundling several unrelated issues into one report
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.
Sorona credits this project with 8 CVEs, 4 of them recent. The individual records appear here after the next sync.
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 8 Lifetime Memory safety 55 % Authentication / PIN handling 20 % Cryptographic weakness 15 % Denial of service 10 % Latest advisories Loading the feed Overview OpenSC is the middleware between a smartcard and the operating system. It is the PKCS#11 stack behind national eID rollouts across Europe, PIV and CAC deployments, OpenPGP cards and a range of YubiKey paths, and it parses data arriving from a card an attacker may have manufactured. CVE-2025-66215 is the reference point: a stack buffer overflow write in the Oberthur card driver, reached by a card responding with values the driver trusted. Four such bugs landed on a single day in March 2026. The project publishes a detailed disclosure policy with a two-week response commitment and no money behind it. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy states what it counts as a security issue and that list is the declared scope: memory safety defects, authentication and authorization bypass, cryptographic weakness, key or PIN disclosure, privilege escalation and remote code execution The PKCS#11 module, which is the interface every consuming application talks to, including the object model, session handling and the login and logout paths Every card driver shipped in the tree, covering the national eID drivers, PIV and CAC, the OpenPGP card and the long tail of vendor-specific drivers, whether or not any of them has ever carried an advisory The APDU layer and the response parsing underneath the drivers, including the TLV and compact TLV handling and the GET RESPONSE chaining The PKCS#15 layer and the file and object structures it reads from a card PIN handling in full: entry, verification, retry counters, the PIN pad reader paths and anything that could disclose or bypass a PIN Key material handling, covering the key objects the module exposes, the operations performed on card and anything that could leak a key or a key attribute The command line tools, pkcs11-tool , pkcs15-tool , opensc-tool , opensc-explorer and the rest, which parse card data and files supplied by someone else The minidriver and the platform integration layers where OpenSC plugs into an operating system's own smartcard stack The reader layer and the PC/SC interaction, including how OpenSC behaves against a reader or a card that responds outside the specification The certificate and cryptographic object handling that turns card contents into something an application will trust Out of scope Defects in a card's own firmware or applet rather than in OpenSC's handling of it Defects in PC/SC-lite, in a reader driver, or in a consuming application rather than in OpenSC Attacks requiring invasive physical access to a card, such as fault injection or decapping Weaknesses in a standardised algorithm rather than in this implementation of it Bundling several unrelated issues into one report, which the policy's one-advisory-per-issue rule rules out Most-valued findings Memory corruption in a card driver reached by a card response. This is the dominant class here by a wide margin: CVE-2025-66215 and CVE-2025-49010 were both stack buffer overflow writes, one in the Oberthur driver and one in GET RESPONSE handling Out-of-bounds reads and pointer defects in the TLV parsing layer, the shape CVE-2025-66038 took in sc_compacttlv_find_tag , since every driver above it depends on that code being correct Anything a hostile card can drive. OpenSC sits between an unauthenticated reader and the operating system, so a card an attacker manufactured is a realistic and fully in-scope attacker position PIN disclosure or PIN verification bypass, named explicitly in the project's own list of what counts as a security issue Key material disclosure, or an operation that performs a cryptographic action the PIN state should have blocked Authentication and authorization bypass in the PKCS#11 session model, where an application receives an authenticated session it did not earn Defects in the national eID drivers specifically, because those deployments are the highest-consequence users of this library and the drivers receive far less external review than the core 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 through the Report a vulnerability flow on OpenSC/OpenSC , which the policy names first and which is enabled on the repository Named maintainer addresses are the documented alternative, for frankmorgner, deengert and jakuje, where a GitHub advisory is not workable for you One advisory per issue. The policy is explicit about this because each advisory carries its own CVE assignment, so do not bundle unrelated findings Name the card and the driver. OpenSC carries dozens of card-specific drivers and a defect in one usually does not exist in the others, so a bare reproduction without the card profile is not actionable Say whether the finding needs a hostile card or only hostile data from a legitimate one. Both count, and the threat model is very different between them The policy commits to a response within two weeks and offers no reward, so there is nothing to negotiate on payment Disclosure Coordinated through the GitHub advisory flow with a documented two-week response commitment, published as a GitHub Security Advisory with a CVE per issue. The March 2026 pattern is what to expect: four advisories out on the same day, batched into a release. OpenSC ships in every Linux distribution and inside eID client packages that national authorities distribute, so the practical exposure runs well past the upstream release. Hold the detail until the advisories are public. 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