- Top reward
- $10,000
- Top severity paid
- Critical
- Assets in scope
- 8
- Public CVEs
- 11
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $10,000
- 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 |
|
$10,000 |
| High |
|
$10,000 from $500 |
| Medium |
|
$10,000 from $500 |
| Low |
|
$500 |
- 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
8 assets you may test, 7 excluded.
Web 1
- https://www.intel.com/content/www/us/en/developer/tools/cryptography-primitives-library/overview.html
Products and areas 7
- Intel accepts security issues in open-source projects it solely maintains, and this one is an Intel-branded product living in Intel's own GitHub organisation with its own developer-tools product page, so it sits on the in-scope side of that line. Software is Tier 3 at $500 to $10,000, and the whole of intel/cryptography-primitives is the target.
- The big-number and modular-arithmetic layer that every public-key operation is built on
- The multi-buffer crypto_mb library and the accelerated paths it runs across several sessions at once
- The optimised assembly itself, across every CPU dispatch path the library can select at run time, including its constant-time and side-channel behaviour
- The public API surface: parameter and length validation, context handling, the buffer contracts callers are told to honour, and post-quantum primitives as they land in the tree
- The public-key side: RSA, DSA and Diffie-Hellman, ECC over both the NIST curves and SM2, together with key generation, signing and verification
- The symmetric side: AES and its modes including GCM, SM4, and the hash and MAC families the library ships across SHA-1, SHA-2, SHA-3, SM3 and HMAC
Out of scope (7)
- Anything already publicly disclosed or previously reported to Intel
- Defects in OpenSSL or in any other caller that merely links this library, unless the root cause is in this code
- End-of-life and pre-release product versions
- Intel's live out-of-scope table on Intigriti lists Intel-maintained open-source projects as out of scope and sends reporters to the project maintainer, which contradicts the scope section admitting projects Intel solely maintains. Confirm eligibility with Intel before committing time.
- Intel's own IT infrastructure, which sits in the programme's "No bounty" tier, plus open and prototyping platforms and reports that amount to exposed credentials
- Open-source projects Intel merely contributes to rather than solely maintains, which belong with the upstream maintainer
- Reports that arrive without instructions demonstrating exploitation on an impacted Intel platform
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 first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards.
-
Include instructions that demonstrate exploitation on an impacted Intel platform: a report without them is not eligible
-
Send the report to Intel first and discuss it with nobody Intel has not authorised, video proof-of-concept included
-
The finding must not have been publicly disclosed or previously reported by anyone else
-
Intel's Product Category table grades open-source software as "Maybe" for bounty rather than "Yes", so make the case that this is an Intel-branded product Intel solely maintains
-
Do not open a regular GitHub issue: the repository's SECURITY.md states plainly that no security vulnerability should be reported as a regular issue in the repository
-
End-of-life and pre-release versions are out of scope for bounty rewards
Not accepted
-
Open-source projects Intel merely contributes to rather than solely maintains, which belong with the upstream maintainer
-
Defects in OpenSSL or in any other caller that merely links this library, unless the root cause is in this code
-
Anything already publicly disclosed or previously reported to Intel
-
Reports that arrive without instructions demonstrating exploitation on an impacted Intel platform
-
End-of-life and pre-release product versions
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 11 CVEs. 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 sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical, CVSS 9.0-10.0 (Software, Tier 3: the $100,000 headline is Tier 1 hardware) │ Up to $10,000 │ Up to $11,000 High and Medium, CVSS 4.0-8.9 (Intel publishes Tier 3 as a range, not a per-band figure) │ $500 - $10,000 │ $625 - $11,000 Low, CVSS 0.1-3.9 │ $500 │ $625 Submit a vulnerability CVE history 0 Last 12 months 11 Lifetime Info disclosure 40 % Memory safety 30 % Parsing/validation 20 % Auth bypass 5 % Latest advisories Loading the feed Overview This is the crypto acceleration layer Intel ships for its own platforms: AES and AES-GCM, RSA, ECC, SHA-2 and SHA-3, the Chinese SM2/SM3/SM4 suite, and the multi-buffer crypto_mb paths, all in optimised assembly. It is consumed by Intel's OpenSSL engine and provider integrations, by performance-sensitive server TLS termination, by confidential-computing stacks, and by database and storage vendors linking it for AES-NI and multi-buffer throughput, which means a very large share of x86 server-side bulk encryption executes this code even where the calling application believes it is just using OpenSSL. A constant-time regression here is a practical key-recovery risk in a multi-tenant environment. NVD holds eleven CVEs against the library, though Intel publishes many of its defects as INTEL-SA advisories that do not map cleanly to that CPE, so treat eleven as a floor. Intel pays through Intigriti on Tier 3, up to $10,000 for a critical finding with a $500 floor, and sorona.xyz adds 1.25× on top of whatever Intel awards, up to $1,000 more, plus a complexity bonus of up to $1,000. In scope Intel accepts security issues in open-source projects it solely maintains, and this one is an Intel-branded product living in Intel's own GitHub organisation with its own developer-tools product page, so it sits on the in-scope side of that line. Software is Tier 3 at $500 to $10,000, and the whole of intel/cryptography-primitives is the target. The symmetric side: AES and its modes including GCM, SM4, and the hash and MAC families the library ships across SHA-1, SHA-2, SHA-3, SM3 and HMAC The public-key side: RSA, DSA and Diffie-Hellman, ECC over both the NIST curves and SM2, together with key generation, signing and verification The big-number and modular-arithmetic layer that every public-key operation is built on The multi-buffer crypto_mb library and the accelerated paths it runs across several sessions at once The optimised assembly itself, across every CPU dispatch path the library can select at run time, including its constant-time and side-channel behaviour The public API surface: parameter and length validation, context handling, the buffer contracts callers are told to honour, and post-quantum primitives as they land in the tree Out of scope Open-source projects Intel merely contributes to rather than solely maintains, which belong with the upstream maintainer Defects in OpenSSL or in any other caller that merely links this library, unless the root cause is in this code Anything already publicly disclosed or previously reported to Intel Reports that arrive without instructions demonstrating exploitation on an impacted Intel platform End-of-life and pre-release product versions Intel's own IT infrastructure, which sits in the programme's "No bounty" tier, plus open and prototyping platforms and reports that amount to exposed credentials Intel's live out-of-scope table on Intigriti lists Intel-maintained open-source projects as out of scope and sends reporters to the project maintainer, which contradicts the scope section admitting projects Intel solely maintains. Confirm eligibility with Intel before committing time. Most-valued findings A constant-time violation or side channel in the optimised assembly that recovers key material from a co-resident process: the dominant class here at 40% of expected findings, and the one that justifies the top of the ladder Carry, reduction or modular-exponentiation errors in the big-number code that leak private-key bits or produce forgeable signatures Memory corruption in the multi-buffer crypto_mb paths, where several independent sessions share one buffer layout Input-validation failures on lengths, curve parameters or key material that let a caller drive the library out of bounds Any of these shown against Intel's OpenSSL engine or provider integration, since that is how most callers actually reach this code Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Include instructions that demonstrate exploitation on an impacted Intel platform: a report without them is not eligible Send the report to Intel first and discuss it with nobody Intel has not authorised, video proof-of-concept included The finding must not have been publicly disclosed or previously reported by anyone else Intel's Product Category table grades open-source software as "Maybe" for bounty rather than "Yes", so make the case that this is an Intel-branded product Intel solely maintains Do not open a regular GitHub issue: the repository's SECURITY.md states plainly that no security vulnerability should be reported as a regular issue in the repository End-of-life and pre-release versions are out of scope for bounty rewards Disclosure Coordinated by Intel PSIRT under Intel's published coordinated-disclosure practice: Intel triages, fixes, and publishes an INTEL-SA advisory crediting the researcher. Intel controls the timing and its non-disclosure clause runs until Intel gives written consent, so sorona.xyz holds the finding until Intel has published. 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