Reporting a vulnerability

Status of this build

WeftKit is pre-GA. It has not completed external security review, penetration testing, or privacy assessment. Do not use it with production credentials or regulated data — use synthetic test accounts only. We would rather say this here than have you discover it later.

How to report

Email security@weftkit.com. Please do not open a public issue, and do not include live credentials or customer data in a report.

We do not yet publish a PGP key. Rather than list one that does not resolve, we ask you to request a secure channel in your first message; a key will be published at /.well-known/security.txt before public distribution.

Useful reports usually include:

• the affected version or commit;
• the environment — operating system, browser, and AI provider;
• reproduction steps, with what you observed and what you expected;
• a proof of concept, if you have one.

If a report involves a third party’s systems, please confirm you were authorized to test them.

What to expect

• Acknowledgement within 3 business days. If you do not hear back, assume the mail went astray and send it again rather than assuming it was ignored.
• An initial assessment within 10 business days, saying whether we consider it a vulnerability and roughly what we intend to do.
• Coordinated disclosure. We will agree a date with you. Our default is 90 days from the report, or the day a fix ships, whichever comes first. If we need longer we will explain why rather than let the date pass quietly.
• Credit in the changelog and advisory, unless you would rather not be named.

For issues that warrant one we will request a CVE and publish an advisory. Where a defect has exposed user data, we will say so directly to affected users, describe what was exposed, and say what we have changed — not only publish an advisory and leave people to match it to themselves.

In scope

• The desktop application and its native core, worker, and updater.
• Handling of secrets, evidence artifacts, and the local database.
• The browser automation boundary, including sandbox and egress controls.
• This website.

Out of scope

• Findings that require an attacker who already has administrator access to the user’s machine. The application is local-first and does not claim to defend against that.
• Vulnerabilities in AI providers, target sites you point the tool at, or third-party CLI agents you configure. Please report those to their owners.
• Missing hardening headers or best-practice scanner output on this marketing site, absent a demonstrated impact.
• Denial of service through resource exhaustion on your own machine.

Known gaps

Some limitations are already known and do not need reporting — though a report that shows one is worse than we describe is genuinely useful. In this build, authentication is an account-entry layer rather than a data-security boundary: local mode and signed-in mode open the same machine-local data. Evidence encryption at rest is available but off by default. There is no tenancy, SSO, or role-based access control.