- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- 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
14 assets you may test, 5 excluded.
Web 1
- https://web.mit.edu/kerberos
Products and areas 13
- Cross-realm trust: referral handling, transited path validation and the checks that decide whether a ticket from another realm is honoured
- The ASN.1 encoder and decoder underneath all of it, which processes attacker-supplied structure before anything has been authenticated
- The client library and the credential cache implementations, covering the file, keyring, memory and DIR caches and their permission models
- The crypto layer krb5 ships, including the encryption types it still supports and the checksum implementations
- The GSS-API implementation and the SPNEGO mechanism, which is the acceptor side every service links against
- The kadmin service and its protocol, the password change service, and the administrative authorization rules in kadm5.acl
- The KDB backends, covering the DB2 store and the LDAP backend, including how a hostile database entry is interpreted
- The KDC itself: the AS and TGS exchanges, the pre-authentication mechanisms, the ticket issuance path and everything it parses from an unauthenticated requester
- The keytab handling and the key material stored in it, along with the tools that create and manipulate keytabs
- The kpropd replication path, which accepts a database dump over the network
- The PAC and authorization data handling, including signature verification on the structures that carry group membership across a realm
- The PKINIT module and its certificate validation, which is the bridge between a smartcard or a certificate and a Kerberos ticket
- The project documents a single security contact for security problems with MIT Kerberos and draws no boundary narrower than that, so the whole krb5 tree is the target
Out of scope (5)
- A realm administrator's deliberate policy choice, such as permitting a weak encryption type or a permissive kadm5.acl entry
- Distribution packaging and distro-specific patches rather than upstream krb5
- Heimdal, Active Directory and other Kerberos implementations, which have their own maintainers; Heimdal is a separate entry here
- Password guessing against a correctly functioning KDC, which is a policy question rather than a defect
- Third-party plugins and out-of-tree KDB or pre-authentication modules
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 by PGP-encrypted email to the address on the policy page , the contact documented in the tree at doc/resources.rst
-
GitHub private vulnerability reporting is switched off on krb5/krb5 , so email is the only private channel and the advisory button is not an option here
-
Do not read the public advisory index at web.mit.edu as a sign the process is dead. It has not been updated since 2015, and advisories now travel through krbdev and the distribution security teams
-
Say which side the defect is on. The KDC, the client libraries, the GSS-API acceptor and the kadmin service are separate trust positions and the severity differs enormously between them
-
Name the database backend and the realm configuration. Behaviour differs between the DB2 backend, the LDAP backend and a cross-realm setup, and a finding may only exist in one
-
MIT runs no bounty for krb5, so there is no reward to negotiate
Not accepted
-
A realm administrator's deliberate policy choice, such as permitting a weak encryption type or a permissive kadm5.acl entry
-
Password guessing against a correctly functioning KDC, which is a policy question rather than a defect
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 MIT Kerberos is the reference implementation of Kerberos 5 and the KDC most Unix realms actually run. It ships in every major Linux distribution, carries enterprise single sign-on, and is a hard dependency of NFSv4, Samba and a long tail of middleware that talks to Active Directory. A defect in the KDC or in GSS-API acceptance is a domain-wide authentication defect, since a forged ticket is valid everywhere the realm is trusted. MIT runs no bounty and the security contact is a PGP-encrypted mailing list at the lab. sorona.xyz pays you directly on qualified, reproduced findings. In scope The project documents a single security contact for security problems with MIT Kerberos and draws no boundary narrower than that, so the whole krb5 tree is the target The KDC itself: the AS and TGS exchanges, the pre-authentication mechanisms, the ticket issuance path and everything it parses from an unauthenticated requester The PAC and authorization data handling, including signature verification on the structures that carry group membership across a realm Cross-realm trust: referral handling, transited path validation and the checks that decide whether a ticket from another realm is honoured The client library and the credential cache implementations, covering the file, keyring, memory and DIR caches and their permission models The GSS-API implementation and the SPNEGO mechanism, which is the acceptor side every service links against The keytab handling and the key material stored in it, along with the tools that create and manipulate keytabs The kadmin service and its protocol, the password change service, and the administrative authorization rules in kadm5.acl The KDB backends, covering the DB2 store and the LDAP backend, including how a hostile database entry is interpreted The crypto layer krb5 ships, including the encryption types it still supports and the checksum implementations The kpropd replication path, which accepts a database dump over the network The ASN.1 encoder and decoder underneath all of it, which processes attacker-supplied structure before anything has been authenticated The PKINIT module and its certificate validation, which is the bridge between a smartcard or a certificate and a Kerberos ticket Out of scope Heimdal, Active Directory and other Kerberos implementations, which have their own maintainers; Heimdal is a separate entry here A realm administrator's deliberate policy choice, such as permitting a weak encryption type or a permissive kadm5.acl entry Distribution packaging and distro-specific patches rather than upstream krb5 Password guessing against a correctly functioning KDC, which is a policy question rather than a defect Third-party plugins and out-of-tree KDB or pre-authentication modules Most-valued findings Anything that yields a ticket or a service authentication without the corresponding key. That is the top of the severity scale here, because a forged ticket is accepted by every service in the realm at once Authorization data and PAC handling defects, particularly signature verification that can be skipped or satisfied with the wrong key, since that structure decides what groups a principal appears to belong to Cross-realm defects in referral or transited path handling, where a ticket from a realm you control becomes acceptable in one you do not Memory corruption reachable from a pre-authentication payload or from any KDC request, since the KDC parses that input while unauthenticated and runs privileged ASN.1 decoder defects, which sit underneath every protocol message and are reached before any authentication has happened Credential cache defects that let one local user read or substitute another's tickets, a realistic path from an unprivileged shell to a service account PKINIT certificate validation failures, which turn a certificate the KDC should reject into a full Kerberos identity kadmin and kpropd defects, where an administrative interface or a replication feed is reachable by someone who should not hold that role 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 by PGP-encrypted email to [email protected] , the contact documented in the tree at doc/resources.rst GitHub private vulnerability reporting is switched off on krb5/krb5 , so email is the only private channel and the advisory button is not an option here Do not read the public advisory index at web.mit.edu as a sign the process is dead. It has not been updated since 2015, and advisories now travel through krbdev and the distribution security teams Say which side the defect is on. The KDC, the client libraries, the GSS-API acceptor and the kadmin service are separate trust positions and the severity differs enormously between them Name the database backend and the realm configuration. Behaviour differs between the DB2 backend, the LDAP backend and a cross-realm setup, and a finding may only exist in one MIT runs no bounty for krb5, so there is no reward to negotiate Disclosure Coordinated by email with the krb5 core security team, who publish MITKRB5-SA advisory notes and hand fixes to the distribution security teams rather than filing GitHub advisories. That routing sets the timing: every major distribution ships krb5 and they coordinate their updates together, so the practical embargo is set by that lockstep rather than by a published day count. Hold the detail until the advisory note and the distribution updates are 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