This policy applies to every repository in the Kornia organisation that does not publish its own SECURITY.md.

Please do not report security vulnerabilities in public issues, pull requests or Discord. A public report tells everyone about the problem before a fix exists, including people who will use it.

Report privately in one of two ways:

1. GitHub private vulnerability reporting — preferred. Open the repository's Security tab and choose Report a vulnerability. This creates a private advisory that only the maintainers can see, and lets us credit you when it is published.
2. Email — hello@kornia.org, if private reporting is not enabled on the repository in question.

Please include:

• which repository and version (or commit) is affected
• what an attacker can do with the issue
• steps to reproduce, ideally a minimal example
• any suggested fix or mitigation you already have

• We aim to acknowledge a report within 7 days.
• If we accept the report, we will tell you our intended fix and the release it will land in, and we will keep you updated while we work on it.
• If we decline it, we will explain why. Disagreement is fine — say so and we will look again.
• We will credit you in the published advisory unless you ask us not to.

Kornia is maintained by volunteers. We will be honest with you about timelines rather than quietly let a report sit.

Security fixes are applied to the latest released version of each project. We do not backport fixes to older release lines. If you depend on an older version, the fix will be to upgrade.

In scope: code in repositories under the kornia organisation.

Out of scope, because we do not control them:

• vulnerabilities in third-party dependencies — report those upstream, though we do want to know if we are shipping a vulnerable version so we can bump it
• the kornia.org website hosting (GitHub Pages) and other third-party infrastructure
• issues that require an attacker to already have local access to a machine running Kornia software

Several Kornia projects load model weights and serialised data. Loading a file from an untrusted source can execute arbitrary code — this is a property of the underlying formats, not a bug we can patch away. Treat model weights like executables: only load files you trust. If you find a path where we load untrusted data without that being obvious to the caller, that is a real vulnerability and we want to hear about it.