Vulnerability Disclosure Policy

Effective 2026-11-15

We want to hear about security problems in Kubi. This policy explains how to report one, what you may test, how we respond, and the legal protection we give to good-faith research. It is the vulnerability disclosure policy that section 13.2 of our Terms of Service refers to. The short version below is a plain summary; the numbered sections are the policy.

The short version

• Email security@trykubi.com. A person reads every report.
• Test only with your own Account and your own Screens. Never touch other customers' Screens or data, never attack anything from a Screen, and no denial of service or social engineering.
• Prove the problem, then stop and tell us. If you see someone else's data, stop at once.
• We aim to reply within 3 business days and keep you updated until it's fixed.
• Give us 90 days, or until the fix is out, before you publish.
• Research that follows this policy is authorized, and we won't take legal action over it.
• There's no paid bounty yet. With your permission, we'll thank you by name on this page.
• Abuse by a Kubi customer, such as spam or attacks coming from our IP addresses, goes to abuse@trykubi.com instead.

1. About this policy

1.1 This policy is published by Arthur Katcher, doing business as Kubi ("Kubi", "we" or "us"). It covers security vulnerabilities in the systems and software listed in section 3. Words such as Account, Screen, Agent and Service mean what our Terms of Service say they mean.

1.2 If you have a Kubi Account, the Terms still apply to it. For research done under this policy, this policy takes priority over the Terms to the extent section 7.3 says.

1.3 Some reports belong somewhere else:

• Abuse by another customer, such as spam, scanning, scraping or attacks coming from a Kubi IP address: abuse@trykubi.com (Terms 7.1). Our IP addresses carry our customers' traffic, so this is an abuse report, not a vulnerability in Kubi.
• A Kubi API key you found in public, or an Account you think someone else has got into: security@trykubi.com (Terms 3.3).
• A vulnerability in a customer's own product that runs on Kubi: contact that customer.
• Help and billing: support@trykubi.com.

2. How to report

2.1 Email security@trykubi.com. For a vulnerability in our SDK, you can also use GitHub's private vulnerability reporting at SDK repository URL. Please don't report vulnerabilities in public issues, discussions or pull requests.

2.2 A good report includes:

1. the affected system, URL or API endpoint, or the SDK package and version;
2. the steps to reproduce it, with a short proof of concept;
3. the boundary you crossed: the access you started with (none, an API key, your own Screen) and what you reached (another Account, another Screen, the host, our infrastructure);
4. the impact as you see it;
5. the email address of the Account you tested with and the IDs of the Screens you used; and
6. whether you want public credit, and under what name.

2.3 Send the least data needed. Leave out passwords, keys and other people's data, and redact logs and screenshots before you attach them.

2.4 Write in English if you can. Send one report per vulnerability, unless you chain several to show the impact.

2.5 We close reports from scanners or AI tools that nobody has checked by hand and that come without a working proof. They're welcome once you've confirmed them.

3. Scope

3.1 These systems are in scope:

3.2 The findings that matter most cross a boundary: from your Screen to the host or to another customer's Screen, from your Account into someone else's, or from outside into our infrastructure, secrets or backups.

3.3 These are out of scope. Please don't test them:

1. other customers' Accounts, Screens and data, the software they run and the websites their Agents visit;
2. services run by our providers, such as Ikoula, Stripe, Resend, Grafana Labs, and sign-in with GitHub or Google. Report problems there to the provider under its own policy;
3. denial of service, load tests and traffic floods against anything shared;
4. social engineering or phishing of Kubi, our providers or our customers, and physical attacks; and
5. any system not listed in section 3.1.

trust.trykubi.com runs on Probo, an open-source project that we host ourselves. If a flaw is in Probo's own code, we pass it to its maintainers with your permission (section 5.6).

3.4 The following aren't vulnerabilities, unless you show an impact beyond your own Account or Screen:

1. anything you do inside your own Screen with the access it gives you, including admin or root access where your Screen has it;
2. using up the resources of your own Screen, or reading data you put there yourself;
3. limits working as designed, such as closed outgoing email ports, connection and bandwidth caps, rate limits and usage quotas (Terms 6);
4. traffic from a Kubi IP address to someone else's system (send that to abuse@trykubi.com);
5. known CVEs in a Screen's operating system or kernel, unless you show that they break the isolation between Screens or reach the host;
6. missing security headers or cookie flags, opinions on TLS or email settings (SPF, DKIM, DMARC), version banners, clickjacking or CSRF on pages with no sensitive action, and open redirects, without a demonstrated impact; and
7. issues that need an outdated browser, a rooted device or physical access to the victim's device.

3.5 Subdomains and systems we missed. Item 5 of section 3.3 doesn't apply to subdomain takeover: taking over any subdomain of trykubi.com, for example through a DNS record that points to a service we no longer use, is in scope. Prove it with a harmless page that shows your handle, then tell us. If you find a system you think is ours but section 3.1 doesn't list, ask us at security@trykubi.com before you test it. If it is ours, we add it to section 3.1 and handle your report. Our status page, status.trykubi.com, is hosted by Better Stack: report flaws in Better Stack itself to Better Stack.

3.6 Screens from different customers can share a physical server (our security page, section 17.2). Don't test processor side-channel attacks, such as Spectre-type attacks, against our servers, because they can affect other customers. If you have reason to think one works on Kubi, tell us at security@trykubi.com and we'll agree a safe way to show it.

3.7 Versions. The hosted service is updated continuously, so we assess reports against what runs in production. For the SDK (and the CLI, once released), we fix security issues in the latest release and don't backport fixes to older versions. Please test the latest release.

4. Rules for research

4.1 Use only Accounts you created and Screens you started. Sign up with a GitHub or Google account you control and give its email address in your report. Your Account and Screens remain subject to the Terms.

4.2 Mark your traffic: add the header X-Kubi-Research: your-handle to your requests to our API and websites. Keep automated requests to our API and websites under 10 per second. Inside your own Screen, there's no limit.

4.3 Don't:

1. access, change, delete or keep anyone else's data;
2. run denial of service or load tests against shared parts of Kubi;
3. use social engineering, phishing or physical attacks;
4. use a Screen to scan, test or attack anyone else, even someone who has allowed you to test them. This policy authorizes research on Kubi only, so test third parties from your own infrastructure (Terms 6, item 2);
5. move deeper into our systems, keep access after you've proved it, or leave anything behind except the marker file in section 4.4; or
6. ask for money in exchange for not publishing, or threaten to publish.

4.4 Prove it, then stop. We'll work out the full impact ourselves.

4.5 If you see another person's data, stop at once. Don't look further or keep a copy, report it to us within 24 hours, and delete what you have. We may ask you to confirm the deletion.

4.6 Screens used for research are billed like any others. Ask security@trykubi.com for research credits before you start; we decide case by case and may withdraw them. We don't refund other charges from research.

4.7 Our automated systems may slow down or pause a Screen that looks like it's attacking something (Terms 7.2). If that happens during research, tell us and we'll review it.

4.8 If you're not sure something is allowed, ask us at security@trykubi.com before you do it. Asking first always counts in your favor.

5. What we do

5.1 We aim to meet these targets. Reply times are in business days, and a reply means one written by a person, not an automatic one. Fix times are calendar days from when we confirm the vulnerability.

5.2 If we're going to miss a target, we tell you before it passes, with the reason and a new date. If you've heard nothing from us after 5 business days, write again and copy legal@trykubi.com.

5.3 We rate severity by what an attacker could reach across the boundaries in section 3.2, using CVSS as a guide. We tell you our rating and why, and if you disagree, we look again.

5.4 We may switch off or limit a feature while we fix it.

5.5 If a vulnerability exposed customer data, we treat it as a security incident and tell the affected customers as section 4.5 of the Terms and our DPA require.

5.6 If the flaw is in third-party or open-source software we use, we report it to its maintainer. We share your name with them only if you agree.

6. Publishing

6.1 Please keep the details private until we've deployed the fix, or until 90 days after your report, whichever comes first. For a flaw in our SDK (or our CLI, once released), please also wait 30 days after the fixed release so users can update, unless 90 days have already passed since your report.

6.2 If we need longer, we'll ask before the 90 days end, explain why and propose a date. We won't ask you to wait just to avoid embarrassment.

6.3 If we never answer your report, you may publish once 90 days have passed, after giving us 14 days' notice at security@trykubi.com.

6.4 Once a fix is out, we publish an advisory in the Trust Center for each vulnerability that affected customers or our SDK (or our CLI, once released): what it was, who was affected, what we did, and what users should do. We credit you there if you want.

6.5 When you publish, leave out other people's data and anything that would help attack a system that isn't fixed yet. We're happy to publish at the same time as you and link to your write-up.

6.6 For a vulnerability in our SDK (or our CLI, once released), we also publish a GitHub security advisory in SDK repository URL and request a CVE ID for it, so dependency tools such as Dependabot and npm audit can warn users. We credit you there if you want.

7. Safe harbor

7.1 If you make a good-faith effort to follow this policy, we consider your research authorized under anti-hacking laws, such as the US Computer Fraud and Abuse Act and similar laws elsewhere. We will not take legal action against you, or report you to law enforcement, for that research, including for accidental good-faith breaches of this policy.

7.2 We will not bring a claim against you for getting around the technical measures that protect the systems in section 3.1, when you do it for research under this policy.

7.3 For research under this policy, we waive items 2 and 3 of section 6 of our Terms and the restriction on probing the Service in section 13.2 of our Terms, to the extent they would prevent that research. Where this policy and the Terms differ about such research, this policy prevails.

7.4 This safe harbor does not cover:

1. activity aimed at other customers' Accounts, Screens, data or End Users, or at third parties reached through our network, for which we keep all our rights;
2. breaches of this policy that are deliberate or not in good faith; or
3. claims by anyone else. We can't authorize testing of systems we don't own, and our providers and customers are not bound by this policy.

If we think a breach was deliberate or not in good faith, we tell you why and hear your side before we act. Asking us first weighs strongly in your favor.

7.5 If a third party takes legal action against you for research that followed this policy, we will make it known that your research was authorized under this policy.

7.6 We will not give your name, email address or other identifying details to a third party without your written permission. After telling you, we may share technical details that don't identify you with an affected provider or maintainer. A court could still order us to disclose information.

7.7 You still need to follow the law that applies to you. This safe harbor is based on the disclose.io safe harbor template.

8. Thanks

8.1 We don't pay bounties at launch. The safe harbor applies all the same.

8.2 With your permission, once an issue is fixed, we list the researcher who reported it below, with the date and the type of issue. The first person to report an issue gets the credit.

Thank you to: no reports yet.

9. EU Cyber Resilience Act

9.1 Where the EU Cyber Resilience Act applies to our SDK, CLI or other software we supply, this policy is our coordinated vulnerability disclosure policy (Article 13(8) and Annex I, Part II, point (5)), and security@trykubi.com is our single point of contact for reporting vulnerabilities (Article 13(17) and Annex I, Part II, point (6)). You can reach it by email or, for the SDK, through GitHub.

9.2 For that software, if we learn that a vulnerability is being actively exploited, or of a severe incident affecting that software's security, we notify it through ENISA's Single Reporting Platform as Article 14 requires from 11 September 2026, and we tell the users affected what they can do (Article 14(8)). We publish fixed vulnerabilities as section 6.4 says (Annex I, Part II, point (4)).

10. Your personal data

10.1 We use your name, email address and report to handle the report, stay in touch with you, credit you if you want, and keep a record of vulnerabilities and fixes. We keep reports for vulnerability record period. Our Privacy Policy explains how we handle personal data and your rights.

11. Changes and contact

11.1 We may update this policy and will change the date at the top when we do. A report is handled under the version in force when you sent it.

11.2 Contact:

Arthur Katcher, doing business as Kubi, postal address

• Security vulnerabilities and leaked keys: security@trykubi.com
• Abuse by Kubi customers: abuse@trykubi.com
• Help and billing: support@trykubi.com
• Privacy: privacy@trykubi.com
• Legal notices: legal@trykubi.com
• Machine-readable contact (RFC 9116): https://trykubi.com/.well-known/security.txt