Security

Security

Security is a brand promise for Crumbless, not a checkbox. The product is designed around defense-in-depth (data outside the web root by default, PHP boot guards, web-server-specific protection, installer self-test), the Hub is gated by IP allowlist + admin-role + auth + 2FA, and every license-verify response is signed with Ed25519 so installs reject any response a network adversary tampers with.

This page is for the moment something does go wrong — how to tell us, and what to expect when you do.

Reporting a vulnerability

Email security@crumbless.eu with:

  • A description of the issue and the impact you think it has
  • Steps to reproduce, or a proof-of-concept if you have one
  • The version of Crumbless you tested against (the build’s git short-SHA or release tag is ideal)
  • Whether you’d like public credit when we publish the fix

We respond within two business days for an initial acknowledgement, and within fourteen days with a triage outcome (confirmed / not reproducible / known / out of scope). For confirmed issues we agree on a disclosure timeline with you before the fix ships.

If you find a critical vulnerability — remote code execution, auth bypass, persistent license-signing key compromise — please mark the email subject with [CRITICAL]. We monitor that prefix more aggressively.

Scope

In scope:

  • The customer-installable Crumbless product (this repository, latest released version)
  • The Crumbless Hub: crumbless.eu, account.crumbless.eu, api.crumbless.eu, admin.crumbless.eu
  • The license-verify protocol (canonicalization, signature verification, key handling)

Out of scope:

  • Third-party services we depend on (Lemon Squeezy, Postmark, Hetzner, Cloudflare, jsDelivr) — report directly to them
  • Self-hosted instances of Crumbless on customer infrastructure that we don’t operate (we can advise but the customer is the responsible party)
  • Issues that require physical access to a customer’s server
  • Theoretical timing attacks against constant-time comparisons that have no practical exploitation path
  • Tabnabbing on outbound target=_blank links (rel="noopener" is in place where it matters)

Safe-harbour

We won’t pursue legal action against good-faith security research that:

  • Stays within the scope above
  • Doesn’t access, modify, or destroy customer data
  • Doesn’t degrade availability for other users
  • Gives us reasonable time to fix before public disclosure

If you’re unsure whether your research crosses a line, ask first. We’d rather discuss it than have you sit on a finding.

What we publish

When a fix ships:

  • The Changelog lists every release with its date and a description of what changed
  • Security-relevant fixes are marked with Security: and link to a CVE if one was assigned
  • For critical issues we send a notification to all customers with a registered license, in addition to the public changelog entry

Disclosure of the company

This site and the Crumbless product are operated by NEXTGENWEBS, S.L., based in Paterna, Valencia (Spain). For non-security correspondence, see the Legal notice and Contact pages.