//Vulnerability Disclosure

Last updated September 22, 2026

Vulnerability Disclosure Policy

If you have found a security vulnerability in UpliftOS, we want to hear about it, and this document is our commitment to how we will treat you when you tell us.

Report to [email protected]. You do not need permission first, and you do not need to know whether the issue is serious.

1. Our Commitment to You

If you make a good-faith effort to follow this policy, then for research within the scope in Section 2:

  • We will not pursue legal action against you, and we will not report you to law enforcement, for the research itself.
  • We will not ask your employer to discipline you.
  • If a third party brings action against you over research that was within this policy, we will make it known that your work was authorized under it.
  • We will treat you as a partner, not as an intruder.

This is an authorization, and it is the point of the document. Testing computer systems without authorization can be a criminal matter in many places; within the scope below, you have ours.

The authorization is limited to what this policy covers. It does not extend to conduct outside Section 2, and it cannot authorize anything we have no right to authorize — which is Section 3.

2. What Is in Scope

In scope: upliftos.ai, and the subdomains we operate for our own applications and APIs. If you are not certain whether a host is ours, ask us before testing it.

In scope as a class: authentication and session handling, access control and tenant isolation, injection, deserialisation, server-side request forgery, business-logic flaws, exposed credentials and secrets, insecure defaults in what we ship, and anything that lets one organization reach another organization's data. Cross-tenant access is the finding we most want to receive.

Out of scope, and please do not:

  • Denial of service, load testing, or volumetric attacks of any kind. We will not authorize a test whose method is to degrade the service for other people.
  • Social engineering of our staff, our customers, or our vendors; phishing; pretexting.
  • Physical attempts against our offices or our people.
  • Attacks on our third-party providers. Their programs govern their systems.
  • Accessing, modifying, downloading or retaining another person's data. If you find a way to reach data that is not yours, stop, record just enough to demonstrate it, and report it. Do not enumerate, and do not keep it.
  • Destructive testing — deleting data, altering records, or leaving persistent artefacts on systems that are not yours.
  • Findings with no security consequence: missing headers with no demonstrable impact, version disclosure, reports generated by a scanner with nothing shown to follow from them, or issues in software we do not run.

3. Customer Applications Are Not Ours to Authorize

Organizations build and run their own applications on UpliftOS, and those applications are theirs. We do not own them, we do not own the data in them, and we cannot give you permission to test them.

Nothing in this policy authorizes testing a customer's application, its data, or a customer-operated domain, even where it runs on our infrastructure. If you want to test one, the organization that owns it is the only party who can authorize you, and you should approach them.

If you believe a vulnerability in our platform is exposed through a customer's application, report it to us and describe it in platform terms. Do not go further into their application to prove the point.

4. How to Report

Send to [email protected], and include what you would want to receive:

  • What the issue is, and what an attacker gets from it.
  • Where — the URL, the endpoint, the parameter.
  • How to reproduce it, step by step. A short proof of concept beats a long description.
  • Anything that helps us judge severity.

Report in any language you are comfortable in. One issue per report, where you can.

Please do not disclose publicly until we have had a chance to fix it. We are not going to name a fixed number of days and then treat it as a deadline that protects us. What we will do is keep you told: if a fix is taking a long time, you will know why, and we will agree timing with you rather than asking you to wait indefinitely.

5. What We Will Do

  • Acknowledge your report. A person will reply.
  • Tell you what we concluded — whether we reproduced it, how we rated it, and what we are doing.
  • Tell you when it is fixed, and give you the chance to verify the fix.
  • Credit you if you would like to be credited, and stay quiet about you if you would prefer that.

On rewards, plainly: we do not run a published bounty with a fixed schedule of payments. Where a report is materially valuable we will discuss recognition with you directly. We would rather say that than advertise a program and then negotiate down from it.

6. If You Are a Customer

If you find a vulnerability in your own application built on UpliftOS, that is a support matter rather than a disclosure — reach us at [email protected], and see the Security Overview.

If you find a vulnerability in our platform while using it, this policy covers you, and your reporting it has no bearing on your account.

7. Incident Notification Is Separate

This policy is about reports coming in. Our obligations when a security incident affects your data — what we tell you and when — are in the Data Processing Addendum and the Security Overview, and they apply whether we found the problem or you did.

8. Changes to This Policy

We will update this policy as our systems and our program change. The authorization in Section 1 applies as it stood when you did the research, so a later change does not retroactively withdraw it from work already done in good faith.

[email protected] · our machine-readable pointer to this policy lives at /.well-known/security.txt.

9. Related Documents