Legal

Security Policy

How to report a vulnerability in Unicorn Panel, what happens after you do, and the protection we offer researchers acting in good faith.

Last updated

Reporting a vulnerability

If you believe you have found a security issue in Unicorn Panel or in any of our services, tell us privately at security@unicornpanel.com before telling anyone else.

Please do not use the community forum, public issue trackers, or social media for security reports. A public report puts every operator running the panel at risk until a fix ships.

A useful report usually includes:

  • What the issue is, and what an attacker could achieve with it.
  • The version of the panel, and which component is affected.
  • Steps to reproduce it, ideally with a minimal proof of concept.
  • Any logs, requests, or screenshots that make it easier to confirm.
  • How you would like to be credited, if you want credit.

Reports in any language are welcome, and you do not need to have a fix in mind.

Encrypting your report

If the details are sensitive, encrypt them to our PGP key. An unpatched exploit sitting in plain email is a risk in itself, so we would rather you used it than held the report back.

Our machine-readable contact details are published at /security.txt.

What happens next

We aim to acknowledge a report within 3 business days, and to tell you within 10 business days whether we have reproduced it and how we intend to handle it.

How quickly a fix ships depends on severity. Something that lets one tenant reach another tenant’s data, or an unauthenticated path into the panel, is treated as urgent and gets an out-of-band release. Lower-risk issues are scheduled into a normal release.

We will keep you informed while we work, tell you when the fix is out, and credit you in the release notes unless you would rather stay anonymous. We do not run a fixed bug bounty program, but we may reward a particularly valuable report at our discretion.

Coordinated disclosure

We ask that you give us a reasonable window to investigate and ship a fix before publishing anything. 90 days is our default expectation, and we will usually be much faster than that.

If a fix is taking longer than it should, talk to us rather than waiting in silence. We would rather agree a date with you than be surprised. If an issue is already being exploited in the wild, tell us immediately and we will move at that speed.

Safe harbor

If you research in good faith and follow this policy, we will not pursue or support legal action against you for your research, and we will treat your work as authorized conduct.

To stay within that protection:

  • Test only against our public demo or a Unicorn Panel installation you run yourself. Never against another operator’s panel or their customers’ sites.
  • Do not access, modify, or keep data that is not yours. If you come across someone else’s data, stop and tell us.
  • No denial of service, no volumetric or load testing, and nothing that degrades service for others.
  • No social engineering, phishing, or physical attempts against us, our staff, or our providers.
  • Give us a reasonable disclosure window, as above.

If you are unsure whether something is in bounds, ask first. We would rather answer a question than read an incident report.

Scope

In scope:

  • The Unicorn Panel control panel and its REST API.
  • The unicorn daemon and CLI.
  • The first-party stack: Sleipnir (web), Hermes (mail), Mimir (SQL), and Heimdall (DNS).
  • The panel’s container and tenant isolation model.
  • This website, the update and licensing service, and the community forum.

Out of scope:

  • Installations operated by other people, and the websites their customers host.
  • Third-party engines the panel can orchestrate, such as NGINX, Apache, OpenLiteSpeed, MariaDB, MySQL, and PostgreSQL. Report those upstream, though we are glad to know.
  • Issues that need physical access to a server, or a compromised host or account to begin with.
  • Missing hardening headers, TLS configuration preferences, or scanner output with no demonstrated impact.
  • Denial of service, resource exhaustion, and volumetric attacks.
  • Misconfiguration of a customer’s own DNS, SPF, DKIM, or DMARC records.

How we build for this

Security reports land against a product designed to limit the damage any one of them can do. Every tenant runs in its own rootless container with its own user, ports, and resource limits, so a compromised site is contained rather than shared. API requests are authenticated at the gateway before any handler runs, and cross-server calls use per-server keys with their own scopes.

The panel collects no usage telemetry, so there is no central pool of customer data to breach: what the panel knows stays on your servers. See the Security page for the full picture, and the Privacy Policy for the little that does leave your infrastructure.

Security updates

Security fixes are published on the Releases page, tagged as security items so they are easy to pick out. We describe what was wrong and what an attacker could have done, in enough detail to judge urgency without handing anyone a recipe.

Run the current release. Upgrading is how a fix reaches your servers, and an installation that never upgrades keeps every issue it shipped with.

Contact

Security reports: security@unicornpanel.com. Everything else: the contact form, or Unicorn Labs LLC, 4925 S Broadway Ave, Unit #6070, Wichita, KS 67216, United States.