← All documents

Security

Version of 12 August 2026.

Report a vulnerability to support@forgejo.dc-analytic.com, with "security" in the subject line. The machine-readable version of this page is at /.well-known/security.txt.

What we promise you

• A reply from a person within one business day, not an automated ticket number.
• An assessment, and a fix or a reason. Critical issues contained the same day and fixed within seven; high within thirty; anything we decide not to fix comes with an explanation, in words, to you.
• Credit, in the name you choose, if you want it.
• No legal action for good-faith research that stays within the scope below. This page is the authorisation; you do not need to ask first.

We do not pay bounties. Saying so here is fairer than letting you find out after the work.

What we ask of you

• Test only against your own instance and your own account. Sign up if you need one.
• Stop as soon as you have proved a thing is possible. Do not read, copy, modify or delete another customer's data — a single record is enough to demonstrate access, and there is no need for a second.
• No denial of service, no load testing, no spam, no social engineering of us or of our suppliers, and nothing physical.
• Give us a reasonable time to fix it before publishing. Ninety days is the normal ceiling; if a fix lands sooner, publish sooner.
• If you come across another customer's data by accident, tell us and delete your copy.

In scope

The customer portal, the platform's own API, the provisioning and backup machinery, the hosts, and the isolation between instances. The findings we most want, in order:

1. Anything that reaches another customer's instance, or the platform's own systems, from inside an instance.
2. Anything that escapes a virtual machine onto its host.
3. Anything that reads the backup repositories or their keys.
4. Authentication or authorisation bypass in the portal or the API.
5. Anything that obtains a certificate for a name the platform does not serve.

Out of scope

• Forgejo itself. Report bugs in the forge software to the Forgejo project, whose disclosure process is theirs. If a Forgejo issue is made worse by how we run it, that part is ours and we want to hear it.
• What a site administrator can do to their own instance. You get administrative rights on your own forge, and that includes running code inside it. It is not an escalation; it is the product. Getting out of that machine is very much in scope.
• Missing headers, cookie flags on cookies that carry nothing, TLS configuration opinions, and scanner output with no demonstrated impact.
• Rate-limiting complaints without a demonstrated abuse path.
• Anything requiring an already-compromised device or a rooted browser.

How the platform is built to fail safely

Useful context if you are looking, and useful assurance if you are buying:

• Every customer gets a virtual machine with its own kernel, not an account on a shared application. A tenant cannot reach another tenant, the host, the platform's own systems, or the provider's metadata service. That is not an assertion about configuration: it is proved by a suite in which the tenants themselves run the probes and the answers are read back from outside.
• Site administration is deliberately yours, which includes code execution inside your own instance. That is precisely why the machine boundary exists: what you can do has to stop at your own edge.
• SSH is end to end. The platform's relay copies bytes between your client and your instance's own SSH server. It holds no key, terminates no session, and is not in a position to read or alter anything.
• Certificates are gated. A certificate is only ever issued for a name that a paying instance has proved it controls.
• Backups are encrypted before they leave the host, in two repositories with separate credentials, and the keys are not held by the storage providers.
• Secrets are per instance. Nothing is shared between customers, and instance SSH host keys are generated by the platform so that a restored instance keeps its identity.

An external penetration test is planned within three months of launch, and we will publish a summary of it. Until that exists, this page describes design rather than an independent assessment, and we would rather you knew which one you were reading.

If it affects you

Where a vulnerability could have exposed customer data, we tell affected customers whether or not anybody reached it, with what happened, what was involved, and what we have done. Where personal data is breached, we notify the supervisory authority within 72 hours — see the privacy policy.