Git hosting service operated by Vigilis at pawprint.vigilis.online
This policy applies to the git hosting service itself — the Forgejo web
application, its API, and the SSH git endpoint on port 2222. It
describes how to report a security problem in the service and what you can
expect from us in return.
If you found a problem in the content of a repository hosted here
(an application, a library, someone's project), please use that project's own
security policy where one exists. This page covers the hosting platform
itself.
Report security vulnerabilities privately by email to
security@vigilis.nl.
Please do not open a public issue and do not disclose publicly until we have
had a reasonable opportunity to address the problem.
Reporting a vulnerability
If you would like to encrypt your report, say so in a short first email and
we will arrange a key. To help us triage quickly, please include as much of the
following as you can:
A clear description of the issue and the impact you believe it has.
The exact URL, endpoint, or SSH interaction involved.
Step-by-step instructions to reproduce it, with a minimal proof-of-concept.
Any relevant request/response captures, logs, or screenshots.
The date and time (with timezone) of your testing and the source IP address
you tested from, so we can correlate it with our logs.
What to expect from us
Acknowledgement of your report as quickly as we reasonably
can, normally within a few working days.
An honest assessment: whether we can reproduce it, how we
rate the severity, and what we intend to do.
A fix developed under coordinated (responsible) disclosure,
and a note to you when it is deployed.
Credit for the discovery if you want it — tell us how you
would like to be named, or that you would rather stay anonymous.
We do not run a paid bug-bounty programme; reports are handled on a good-faith
basis.
Scope
In scope — the hosting service and everything we operate to run it:
The Forgejo web application (authentication, session handling, access
control between users and organisations, CSRF/XSS, SSRF, injection, and
similar application-level flaws).
The HTTPS API and the SSH git endpoint (port 2222).
Server, container, and infrastructure configuration that exposes user data
or allows unauthorised access.
Isolation between repositories and between accounts (e.g. reading a private
repository you should not have access to).
Out of scope:
Vulnerabilities in the code hosted inside individual repositories —
report those to the relevant project.
Denial-of-service, volumetric, or brute-force / rate-limit testing. Please
do not run load or stress tests against the service.
Findings without a realistic security impact (missing hardening headers with
no exploitable consequence, version banners, self-XSS, clickjacking on pages
with no sensitive state, automated-scanner output without a working
proof-of-concept).
Social engineering, phishing, or physical attacks against Vigilis, its staff,
or its infrastructure.
Attacks that require a compromised device, a rooted/jailbroken client, or a
privileged position you already hold.
If you are unsure whether something is in scope, email us and ask before testing.
Rules of engagement (safe harbour)
We support good-faith security research and will not pursue or support legal
action against researchers who:
Make a genuine effort to avoid privacy violations, data destruction, and
interruption or degradation of the service.
Only interact with accounts they own or have explicit permission to test,
and do not access, modify, or retain other users' data. If you accidentally
encounter data belonging to someone else, stop, do not save it, and tell us
in your report.
Do not exfiltrate data beyond the minimum needed to demonstrate the issue.
Report the problem promptly and give us a reasonable time to remediate before
any public disclosure.
Do not use the finding for any purpose other than the report.
Acting in good faith and within these rules, you should not expect us to treat
your research as a violation of our acceptable-use terms.
Supported version
We run a currently supported release of Forgejo and apply security updates as
they become available. Security fixes are applied to the running service; there
is no support commitment for older, unpatched deployments.