GitRiver security

Where to report a vulnerability

security@gitriver.ru

Write to this address rather than to public issues or discussions: until a fix is out, a description of the vulnerability is a ready-made set of instructions for an attacker, and GitRiver installations are not all updated on the same day.

If you need an encrypted channel, say so in a first message without any details of the finding — we will agree on a method and continue there.

What to include

The fuller the report, the faster the answer. Whatever you have is enough:

• the GitRiver version and how it was installed (package, image, docker compose, chart);
• what happens and why it matters — which data or actions become available;
• how to reproduce it: requests, steps in the interface, a minimal example;
• if you have one, a guess at the cause.

A request: please do not test findings against installations that are not yours. Bring up your own — docker compose up is described in installation.md. Denial of service, password guessing and mass mailing against someone else’s installation is not research as far as we are concerned.

Response times

What	Within
Acknowledgement that the report arrived	3 business days
Assessment, a «vulnerability / not a vulnerability» decision and a fix plan	10 business days
Coordinated public disclosure	90 calendar days from the report

The clock starts at your message, not at our reply. If 90 days turn out not to be enough, we will say so in advance and explain why, rather than present you with it on the last day. If we stay silent longer than promised, you are free to disclose the finding yourself: the obligation here is ours, not yours.

How disclosure goes

1. You report the finding to the address above.
2. We acknowledge it and open a private issue.
3. We assess it: reproduce it, establish the affected versions and the severity.
4. We prepare a fix and, where needed, a workaround for those who cannot update right away.
5. We release a version containing the fix.
6. We publish a description: what it was, which versions are affected, what to do. We credit the researcher by name — unless you ask us not to.

Steps 5 and 6 are in that order on purpose: the description comes out once there is something to update to.

Supported versions

Security fixes are released for the current minor version. The previous minor version receives fixes for critical vulnerabilities only — for six months from the release date of the version that succeeded it.

Version	Released	Security fixes
1.1.x	2026-09-25	yes — current
1.0.x	2026-03-29	critical only, until 2027-03-25 (six months from the 1.1.0 release)
below 1.0	—	no

The date in the table follows from the rule above rather than being set separately: when 1.2.0 comes out, 1.1.x gets its six months from that date and 1.0.x stops being supported.

Older versions are not patched: the working answer there is to update, not to wait for a patch to something long since replaced.

What we treat as a vulnerability

Bypassing or weakening something that is stated to be a protection. For example:

• access to someone else’s private repository, issue, pull request, package or image; bypassing member permissions or branch protection;
• running someone else’s code on the server, reading or writing files outside the directories set aside for it;
• session hijacking, token forgery, bypassing two-factor authentication, escalation to administrator;
• leaking secrets: CI variables, access tokens, signing keys, connection passwords;
• server-side requests into the internal network to a user-supplied address (SSRF) that bypass validation;
• script injection into the interface, bypassing the CSP;
• denial of service from a disproportionately small request — a bomb inside an archive, parsing a document without a limit, a request that allocates memory in proportion to the data.

Not a vulnerability in itself:

• a missing header or setting with no demonstrated consequence (a scanner said «header X is absent» — that is not a finding; show what breaks because of it);
• actions by the installation’s administrator: they can already do everything, including arbitrary HTML in the footer and running CI jobs. The boundary is obtaining administrator rights, not an administrator using them;
• running arbitrary code inside a CI job: a job is someone else’s code, run deliberately. The vulnerability is a job escaping the limits set for it — to other jobs’ data, to the host, to other repositories’ secrets;
• dependency vulnerabilities without a demonstrated path to exploiting them in GitRiver (the third-party code in this delivery is listed in THIRD-PARTY-NOTICES.md next to this file);
• password guessing against an installation where the administrator has removed the request rate limit.

What has already been checked

Our own code review against the OWASP ASVS list, level L2. The report is available on request — write to the address above. It also states what the review does not cover.

No independent external audit has been carried out so far. Once there is one, a summary will appear in the same report.

There is no bounty programme

We do not currently pay for findings, and we will not promise to until we can. What we can offer is credit — in the description of the fix and in this file.