Reporting a vulnerability

Wharfbase holds database credentials and talks to the Docker socket (through socket-guard), so security reports get priority over everything else.

Reporting a vulnerability

Please don’t open a public issue. Report privately through either channel:

• Email: [email protected]. Encrypt it with our PGP key if you can (see below).
• GitHub: the repository’s Security → Report a vulnerability form (private vulnerability reporting).

Include what you can:

• the version (the image tag you run);
• how Wharfbase is installed;
• the steps to reproduce;
• what an attacker gains.

A proof of concept against your own instance is welcome. Please don’t test against instances you don’t own.

PGP key: to be published at https://fleeq.net/.well-known/security.txt before v1.0. Fingerprint: (added with the key).

What happens next

• Within 3 working days: we acknowledge your report.
• Within 10 working days: we confirm the issue (or explain why we don’t consider it one), give a severity (CVSS 3.1), and plan a fix.
• Fix: we fix it in the supported versions and publish a GitHub security advisory with a CVE when it qualifies. We credit you, unless you’d rather not be named.

Disclosure: 90 days

We ask you to keep the details private until a fix is released, or for 90 days after your report, whichever comes first.

• If a fix needs longer, we’ll tell you why and agree on a new date with you.
• If an issue is being exploited in the wild, we may both disclose sooner.

Supported versions

Version	Supported
Latest minor release (1.x)	Yes
The minor release before it	Security fixes for 3 months after the next minor release
Older	No: please upgrade (wharfbase upgrade)

Until v1.0, only the latest release gets fixes.

Scope

In scope:

• the Wharfbase server and web UI;
• the CLI (wb);
• socket-guard;
• the agent;
• the install script;
• the official images and compose files.

Especially interesting:

• getting past the socket-guard allowlist;
• writing through a read-only connection;
• reaching Wharfbase’s own files or secrets;
• privilege escalation between roles or across per-database permissions;
• authentication or session flaws;
• injection through filters or consoles.

Out of scope:

• what someone with legitimate access to a database can already do with their own database credentials;
• reports that need a compromised host or Docker daemon;
• missing hardening on a deployment that ignores the documented setup (for example, publishing port 8480 to the internet without TLS);
• denial of service by volume;
• findings from automated scanners without a demonstrated impact.

Safe harbor

We won’t pursue or support legal action against good-faith research that follows this policy. Good faith means:

• you avoid privacy violations, data destruction and service disruption;
• you only interact with your own instances or accounts;
• you give us reasonable time to fix the issue before disclosing it.

How Wharfbase is reviewed

• docs/security/asvs.md records the OWASP ASVS Level 2 review and its findings.
• CI runs:
  • dependency audits (pnpm audit, govulncheck);
  • socket-guard tests with the race detector;
  • property-based fuzz tests.
• A nightly job runs the fuzzers at a million iterations per property.