Reporting and disclosure

Three different things can be wrong, and each is told to somebody different: a defect in Wasit itself comes to us, a defect Wasit finds in your service goes to its operator, and a defect in an upstream SDK goes to its maintainers. The first two are always reported privately. For an upstream open-source SDK, a defect that is exploitable goes to its maintainers privately, through their own security policy; a non-exploitable conformance defect goes to their public issue tracker, where they already triage bugs. Every upstream report Wasit has filed so far is of the second kind.

Reporting a vulnerability in Wasit

Report privately first. Do not open a public issue for a security problem.

Email contact@usewasit.dev with:

• What the problem is and what an attacker could do with it
• Steps to reproduce, ideally against the bundled fixture servers
• The versions involved (@wasit-dev/core, Node, and the relevant SDK versions)

You should get an acknowledgement within 72 hours. If a fix is warranted, it will be released before public discussion of the details, and you will be credited unless you prefer otherwise.

Things that are in scope: key material leaking into output, logs, or MCP tool arguments; a destructive check running without both required opt-ins; a check that reports PASS without actually verifying what its pass criteria in CHECKS.md claim.

Things that are not: the fact that some checks spend money, or that the tool will run against a target you were not authorised to test. Both are documented above and are properties of the tool working as designed.

Findings about services Wasit tests

When Wasit finds a conformance defect in somebody else's service:

• The operator is told privately first, with enough detail to reproduce it.
• A reasonable window is given to respond before anything is published.
• Aggregate results may be published — how many services were tested and what classes of defect appeared — but no individual service is named without its operator's written permission.
• A defect that is exploitable, rather than merely non-conformant, is treated as a vulnerability disclosure rather than a test result, and is not published on a timetable of ours.

A FAIL from Wasit is a statement about a specific check against a specific target at a specific moment. It is not a security assessment. See design/scope-boundary.md for what a passing result does and does not mean.

Findings in upstream SDKs

Defects found in the official SDKs during development are documented in findings/upstream-sdk.md and reported to their maintainers — three so far, filed as stellar-mpp-sdk#66, #67 and #70. Those are protocol, packaging and developer-experience defects rather than exploitable vulnerabilities; anything exploitable would go to the maintainers privately and would not appear in that file until it was resolved.