Security
Report it privately. We'll fix it before details go public.
Found a vulnerability in a @pleach/*package? Here's how to reach us and what happens next.
How to report
Email a description of the issue to:
getpleach@protonmail.comInclude the affected package and version, the impact, and repro steps if you have them. Proof-of-concept code helps but is optional. Don't include real customer data.
What to expect
- AcknowledgementWithin two business days. Pleach is a small project — no paid-program SLA, but reports get a real response from a human.
- TriageWe'll let you know whether the report is a security issue, a non-security bug, or a hardening recommendation we'd like to track separately.
- Fix & disclosureFor confirmed issues: patch, coordinate a release, publish an advisory. We'll credit you in the advisory — tell us how you'd like to be named.
- BountyNo paid bug-bounty program today. Reports get a real response, not a payout.
Scope
In scope: any @pleach/* package on npm, source repositories under github.com/pleachhq, and this site (getpleach.com).
Out of scope: applications built on Pleach belong to their vendors; incidents on third-party platforms (npm, GitHub, Vercel) belong to those platforms.
Deployment shape
The runtime runs in your environment, against your keys and storage — no phone-home, no license check, no account. See the trust posture for the full picture.
Air-gapped operation, on-prem provider endpoints, and sub-tenant routing at scale are roadmap, not shipped. Procurement teams evaluating regulated environments can ask getpleach@protonmail.com for current state.
A few things to avoid
- — Publishing before a patch ships — that gives attackers a head start over users.
- — Testing against production systems you don't own. A local environment or private test account is safer.
- — Exfiltrating or altering data. Stop at proof of access — that's enough to confirm the finding.
General (non-security) bug reports belong on GitHub issues.