The entire point of the Open Relay Protocol is a verifiable security guarantee: the rendezvous board stays blind, and devices remain in control of their own secrets. We take reports against that guarantee seriously.

Please do not report security vulnerabilities through public GitHub issues, pull requests, or discussions.

Instead, report them privately by one of the following:

• Email contact@openrelayprotocol.com with the details below, or
• Use GitHub's private vulnerability reporting ("Report a vulnerability" under the repository's Security tab).

If you wish to encrypt your report, ask for a current PGP key at the address above before sending sensitive details.

To help us assess and reproduce the issue quickly, please include:

• A clear description of the vulnerability and the invariant it breaks (e.g. board blindness, signature verification, replay protection, address non-leakage).
• The component and version/commit affected (core/, client/, or board/).
• Step-by-step reproduction, ideally as a failing test or a minimal script.
• The impact you believe it has, and any suggested remediation.

Please do not include real private keys, real user data, or live credentials in your report. A reproduction using freshly generated test keys is always sufficient.

• We will acknowledge your report within 5 business days.
• We will keep you informed as we investigate and work on a fix.
• We will credit you for the discovery once a fix is released, unless you ask to remain anonymous.
• We ask that you give us a reasonable window to release a fix before any public disclosure (coordinated disclosure). We aim to resolve confirmed, high-severity issues within 90 days.

In scope: anything that undermines a protocol invariant as described in TEN-COMMANDMENTS.md and SPEC.md — for example a way to make the board observe plaintext, SDP/ICE, or private keys; to forge or replay a signed record; to bypass abuse mitigation; or to leak a raw host address.

Out of scope: issues in third-party dependencies (please report those upstream), denial-of-service that requires resources beyond a normal client, and operational misconfiguration of a deployed board (e.g. running it without TLS, or exposing the loopback port). Note that the inner message layer is intentionally static-key with no forward secrecy (SPEC §9.3) — this is a documented design decision, not a vulnerability.

ORP is pre-1.0. Security fixes are applied to the main branch. Until a tagged release exists, treat the latest commit on main as the supported version.