- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 0
- 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, 5 excluded.
Web 1
- https://github.com/lsh123/xmlsec
Products and areas 11
- All six crypto backend adapters, openssl, nss, gnutls, mscng, gcrypt and mscrypto, including any place a check enforced in one is absent in another
- Certificate and chain validation across every backend, including how a certificate embedded in a KeyInfo element is treated
- Key management: the key manager, the key store, certificate handling and the trust decision about which key is permitted to have signed a given document
- Reference resolution: same-document references, external references, the URI handling around them and the network or filesystem access any of it can trigger
- The algorithm allowlisting and restriction machinery, where an application asks for a limited set and gets a wider one
- The KeyInfo processing path, which reads attacker-supplied material and decides what to do with it before verification completes
- The published policy asks for vulnerabilities through GitHub's private reporting tool and scopes support by version and backend rather than by component, so the whole xmlsec tree is the target across all six backends
- The transform implementations in full, covering the canonicalisation algorithms, XPath and XSLT transforms, base64 and every other transform a document can request
- The XML Digital Signature implementation: signature verification, reference processing, the transform chain and the canonicalisation applied before a digest is taken
- The XML Encryption implementation, covering decryption, the key wrapping algorithms and the handling of encrypted key structures
- The xmlsec1 command line tool, which processes documents supplied by someone else
Out of scope (5)
- An application's decision to accept a signature xmlsec correctly reported as covering only part of the document
- Defects in a consuming SAML or document signing implementation rather than in xmlsec itself
- Defects in libxml2 or libxslt rather than in xmlsec, which belong upstream with those projects
- Findings against releases and backends outside the published five-year support matrix
- Weaknesses in the XML Signature specification itself rather than in this implementation of it, unless xmlsec has a safer option it fails to apply
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 through GitHub's private vulnerability reporting tool on lsh123/xmlsec , which SECURITY.md instructs and which is enabled on the repository
-
Name the crypto backend. xmlsec supports openssl, nss, gnutls, mscng, gcrypt and mscrypto, and a defect frequently exists in only one of the six
-
Check the published support matrix before reporting against an old release.
-
Say whether the defect is in xmlsec or in libxml2 underneath it.
-
Give the consuming stack you reproduced through where you can, whether SAML, XAdES or a document signature
-
Agree the timeline explicitly in the report.
Not accepted
-
Defects in libxml2 or libxslt rather than in xmlsec
-
Defects in a consuming SAML or document signing implementation rather than in xmlsec itself
-
Findings against releases and backends outside the published five-year support matrix
-
Weaknesses in the XML Signature specification itself rather than in this implementation of it
-
An application's decision to accept a signature xmlsec correctly reported as covering only part of the document
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.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
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 Latest advisories Loading the feed Overview xmlsec implements XML Digital Signature and XML Encryption, and it is the code that actually verifies a signature in SAML SSO stacks, XAdES and eIDAS document signing, LibreOffice document signatures and a range of government and health data exchanges. A signature verification bypass here is an authentication bypass: a SAML assertion that verifies is an identity the relying party accepts. The library supports six crypto backends and publishes a five-year support matrix across them, so old versions stay in production a long time. No reward exists anywhere for a finding in it. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for vulnerabilities through GitHub's private reporting tool and scopes support by version and backend rather than by component, so the whole xmlsec tree is the target across all six backends The XML Digital Signature implementation: signature verification, reference processing, the transform chain and the canonicalisation applied before a digest is taken The transform implementations in full, covering the canonicalisation algorithms, XPath and XSLT transforms, base64 and every other transform a document can request Reference resolution: same-document references, external references, the URI handling around them and the network or filesystem access any of it can trigger The XML Encryption implementation, covering decryption, the key wrapping algorithms and the handling of encrypted key structures Key management: the key manager, the key store, certificate handling and the trust decision about which key is permitted to have signed a given document Certificate and chain validation across every backend, including how a certificate embedded in a KeyInfo element is treated The KeyInfo processing path, which reads attacker-supplied material and decides what to do with it before verification completes All six crypto backend adapters, openssl, nss, gnutls, mscng, gcrypt and mscrypto, including any place a check enforced in one is absent in another The xmlsec1 command line tool, which processes documents supplied by someone else The algorithm allowlisting and restriction machinery, where an application asks for a limited set and gets a wider one Out of scope Defects in libxml2 or libxslt rather than in xmlsec, which belong upstream with those projects Defects in a consuming SAML or document signing implementation rather than in xmlsec itself Findings against releases and backends outside the published five-year support matrix Weaknesses in the XML Signature specification itself rather than in this implementation of it, unless xmlsec has a safer option it fails to apply An application's decision to accept a signature xmlsec correctly reported as covering only part of the document Most-valued findings Any path where a document verifies with a signature it should not have. This is the entire severity ceiling of the project, because in a SAML stack that is an authentication bypass against whatever the relying party protects Signature wrapping and reference resolution defects, where the material that was signed and the material the application then reads are not the same thing Transform chain defects, particularly in canonicalisation or in the XPath and XSLT transforms, since a transform that behaves differently at verification time than at signing time breaks the whole guarantee External reference handling that reaches the network or the filesystem during verification, which is both an information disclosure and a server-side request forgery primitive in a component processing untrusted documents Key selection and trust defects where a certificate or key supplied inside the document itself ends up being accepted as the signer Algorithm restriction bypass, where an application that limited the permitted algorithms finds a weaker one accepted anyway Memory corruption anywhere in the C code reached from a document, since every consumer of this library feeds it structure controlled by whoever sent the document Backend divergence, where a check enforced under openssl is missing under gnutls or nss, because deployments pick a backend for packaging reasons rather than security ones 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 GitHub's private vulnerability reporting tool on lsh123/xmlsec , which SECURITY.md instructs and which is enabled on the repository Name the crypto backend. xmlsec supports openssl, nss, gnutls, mscng, gcrypt and mscrypto, and a defect frequently exists in only one of the six Check the published support matrix before reporting against an old release. The project documents a five-year window per backend, which is unusually generous and unusually specific Say whether the defect is in xmlsec or in libxml2 underneath it. libxml2 is a separate project and a parser bug belongs upstream, though a report that clarifies which is which is still valuable Give the consuming stack you reproduced through where you can, whether SAML, XAdES or a document signature, because the exploitability of a verification defect depends on what the caller does with the answer The project offers no reward, so there is nothing to negotiate on payment Disclosure Coordinated through GitHub private vulnerability reporting on lsh123/xmlsec . The repository publishes no advisories of its own; historically these findings have travelled through distribution security trackers instead, so plan for the distributions to be part of the coordination rather than an afterthought. The published five-year support matrix means backports across several branches are likely, which lengthens the window. Agree the timeline explicitly in the report. 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