Skip to content

Security: iamomm-hack/MatchMesh

Security

SECURITY.md

Security Policy

Supported version

Security fixes are applied to the current RC/main branch. No older release line is currently maintained.

Reporting a vulnerability

Do not open a public issue containing secrets, exploit steps, wallet data, or a working proof of concept. Use the repository host's private vulnerability-reporting feature and include affected commit, impact, reproduction, and suggested mitigation. If private reporting is unavailable, contact a maintainer privately before disclosure.

Please allow maintainers time to confirm and remediate before public disclosure. This project does not currently offer a bug bounty.

RC1 security posture

RC1 includes startup environment validation, structured error redaction, body and request limits, Redis-backed IP rate limiting, provider timeouts/retries/circuit breaking, account-wallet binding, x402 HMAC challenges, challenge expiration, persistent nonce replay protection, duplicate-settlement constraints, defensive API headers, and append-only audit/usage history.

RC1 is not ready for an unauthenticated public production deployment:

  • Wallet connection requests accounts in the browser but does not send a signed authentication challenge to the server.
  • Browser session data is stored in local storage and is not a secure server session.
  • x402, CCTP, and LLM providers are mock implementations.
  • The included signing secret, database password, receiver, and provider-key placeholders are development values.
  • No WAF, distributed tracing backend, secret manager, backup policy, or incident-response integration is included.
  • MCP identity headers are appropriate only behind a trusted authentication edge.

Before public deployment, add signed wallet authentication and server-side authorization, rotate all secrets, enforce TLS, restrict database/Redis network exposure, configure a production secret manager, review allowed origins and proxy trust, add dependency/container scanning, test restore procedures, and commission an independent security review.

Secret handling

  • Never commit .env, provider keys, private keys, payment proofs, database dumps, or real wallet secrets.
  • Treat X402_SIGNING_SECRET, DATABASE_URL, REDIS_URL, and provider credentials as secrets.
  • Use at least 32 random bytes for the x402 signing secret and rotate it through a controlled process.
  • Logs must not contain raw authorization material or secrets.
  • The application must never request a wallet private key or seed phrase.

There aren't any published security advisories