Security

We take the security of bootload and our customers' workloads seriously. If you believe you've found a vulnerability, we want to hear from you.

Report a vulnerability

Email security@ahoy.bootload.io.

Please include enough detail for us to reproduce the issue — affected endpoint or component, steps, and any proof-of-concept. If you'd like to encrypt your report, ask us for a PGP key in your first message.

We support coordinated disclosure: report privately, give us reasonable time to fix, and we'll keep you updated and credit you (if you wish) once it's resolved.

Safe harbour

We will not pursue or support legal action against researchers who, in good faith:

• test only against their own accounts and resources, never other tenants';
• avoid privacy violations, data destruction, and service degradation (no automated high-volume scanning against production);
• do not access, modify, or retain data that isn't theirs — if you can demonstrate access, stop and report it;
• give us a reasonable window to remediate before any public disclosure.

Testing that stays within these lines is authorised, and we treat it as a contribution, not an attack.

What's in scope

bootload.io, my.bootload.io, admin.bootload.io, the API under /v1, the CLI, and the platform that runs customer workloads. Cross-tenant isolation (compute, network, storage, and billing) is our highest priority — findings there get the fastest response.

Out of scope: volumetric DoS, social engineering, reports from automated scanners without a demonstrated impact, and issues in third-party services we don't operate.

Response targets

• Acknowledgement: within 2 business days.
• Triage + severity: within 5 business days.
• Fix: as fast as the severity warrants — critical cross-tenant issues are same-day where we can.

Rewards

We say thank you in bootload credits — spendable on your own hosting — scaled by the confirmed CVSS 3.1 base score of the issue:

The fine print: rewards are paid as account credits at bootload's discretion, to the first reporter of a unique, in-scope, previously-unknown issue, banded by the severity we confirm on triage. No reward for out-of-scope findings, duplicates, or anything discovered outside the safe-harbour rules above. Cross-tenant isolation findings are our top priority and are always triaged fastest.

Machine-readable policy

Our security.txt (RFC 9116) points here and lists the reporting address.

Advisories

BL-2026-003 — Account-security hardening #2: abuse rate-limiting, 2FA step-up, session & cache handling · Fixed

Several researchers independently probed the account and organization surfaces over one week. We confirmed each finding, scored them, and shipped the fixes in one batch. No cross-tenant isolation was affected, and we found no evidence of abuse. Grouped by theme:

1) Missing rate limits on abuse-prone actions The clearest finding — no rate limit on member invitations — could be used to send a large volume of invitation emails to third parties from our sending domain. CVSS 3.1 5.0 (Medium) AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L (the scope change reflects that the abuse lands on external recipients and our mail reputation). We also confirmed the sibling cases: no rate limit on organization creation, ticket creation/replies, and no per-address cooldown on password-reset and signup-notice emails (an email-bombing vector). Fix: invitations are now de-duplicated per recipient and capped per account; organization and ticket actions are capped per account; and the reset/notice mail paths enforce a per-address cooldown — the last silently, so the response stays identical whether or not an account exists (no user enumeration).

2) Two-factor lifecycle needed step-up authentication Three related findings: enabling 2FA did not require the account password; existing sessions were not invalidated when 2FA was enabled; and account deletion required no second factor (in fact, no server-side confirmation at all). Individually these are below our reward threshold (~4.0–4.6, and they require an already-authenticated session), but together they let a hijacked session entrench itself or destroy the account. Fix: enabling 2FA now re-verifies the account password and revokes every other session; deleting an account now requires the password and — when 2FA is on — a valid second factor.

3) Single-use tokens that weren't Multiple outstanding email-verification tokens stayed valid after the account was verified (~4.0). Fix: a successful verification now burns every other outstanding verification token for that account. (A closely related reset-token issue was fixed earlier — see BL-2026-002 #1.)

4) Unbounded / unsafe name fields Account and organization name fields accepted unbounded input (a resource concern) and URLs that email clients auto-link — turning a name that appears in an invitation from our domain into a potential phishing lure. Outbound mail was already HTML-escaped, so this was not script injection; the residual risk was low (~2.6–3.1). Fix: name fields now reject control characters, over-long input, and embedded URLs.

5) Authenticated pages were cacheable After logging out, the browser Back button could still display previously viewed account pages, because authenticated responses were cacheable (~2.6, requires local access to the browser). Fix: authenticated portal and admin pages now send Cache-Control: no-store, which also disables the browser's back-forward cache — the mechanism that actually exposed the page. Hashed, immutable build assets stay cached.

How we scored the set. All are network-reachable; the abuse findings need only a normal authenticated session, and the 2FA/deletion findings additionally require an already-compromised session, which caps their base scores. The invitation-abuse finding is the only one at or above our 5.0 reward threshold; the rest were genuine improvements we shipped regardless. Per our rewards policy, credit for a unique issue goes to its first reporter.

BL-2026-002 — Account-security hardening: reset tokens, sessions, password policy & signup enumeration · Fixed

One researcher submitted four related account-security findings in a single, well-documented batch. We confirmed each, scored them individually, and shipped fixes the same day. Details per finding:

1) Password-reset token survived a password change — CVSS 3.1 5.9 (Medium) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N A reset link requested before an in-account password change remained usable for its remaining lifetime after the change. A captured link was therefore a persistent takeover path even after the victim had moved on. Fix: any password change now invalidates every outstanding reset token for the account, and completing a reset burns all other outstanding tokens too. High confidentiality/integrity impact (full account takeover), but the attacker must already hold the reset link and act within its window (AC:H) — hence Medium.

2) Session persisted after a password change — hardened The session that performed the change was kept and all other sessions revoked — the recommended behaviour for a bearer-token API. On the researcher's prompt we went further: a password change now rotates the session, revoking every token including the current one and issuing a fresh session, so no credential that existed before the change works after it.

3) Weak password policy — CVSS 3.1 4.8 (below reward threshold) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N Trivial passwords such as 12345678 were accepted. Fix: we now screen for length plus a common-password blocklist and trivial patterns (all-same, sequential), following NIST 800-63B — screening known-bad rather than forcing composition rules that only push users to Password1!.

4) Email enumeration at signup — CVSS 3.1 5.3 (Medium) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N The signup form returned a distinct response for an already-registered email ("email already registered") versus an unused one, letting an attacker enumerate registered addresses at scale with no interaction. Fix: signup is now email-first. It returns an identical response whether or not the address is known and never issues a session directly: a new address receives a verification link (which starts the session when clicked), and a known address receives a "someone tried to sign up — please log in" notice. The two responses are byte-identical, removing the oracle. Login was already non-enumerable (identical error for known and unknown emails).

How we scored the set. All four are network-reachable with no privileges and no user interaction at exploit time. #1 carries the highest impact (account takeover) but its higher attack complexity — the attacker must already possess a live reset link — lands it at 5.9. #4 is the cleanest to exploit (fully automated) at 5.3. #3 falls below our 5.0 reward threshold but was a genuine improvement we shipped regardless.

BL-2026-001 — Cross-tenant image-pull SSRF · Fixed

How we scored it. Reachable over the network by any authenticated tenant with no user interaction and trivial effort (AV:N/AC:L/PR:L/UI:N). The defining factor is scope change (S:C): the impact crossed out of the tenant's own authorization boundary into other tenants and internal infrastructure — which is exactly why we treat it as a priority regardless of the numeric score. Impact itself was limited to information disclosure (C:L, I:N, A:N): confirming internal reachability and port-scanning, with content retrieval constrained by the registry protocol — no data could be modified and no service disrupted. That combination lands at CVSS 3.1 5.0 (Medium); had arbitrary content been retrievable (C:H) it would have been High, which the constrained pull path prevented.

Summary. When deploying a service, the container image reference is supplied by the customer. The worker that pulled the image did not validate that the image's registry was a public host. A reference pointing at an internal IP address could make the worker open a connection to that address — a server-side request forgery (SSRF) — which in the internal network could reach another tenant's private container address. No public route to the target was required.

Exposure was limited. The issue allowed confirming reachability of internal addresses (a connectivity probe); retrieving arbitrary content was constrained because the pull path speaks a registry protocol and appends a registry path, not an attacker-chosen one. Every other isolation boundary the researcher tested — cross-tenant volume mounts, storage, and API access — was already properly enforced and unaffected. We found no indication of use beyond the reporter's own coordinated test between two accounts they controlled, and no customer data was exposed through this issue.

Resolution. Image pulls now refuse to connect to internal or private addresses after DNS resolution — blocking both literal internal IPs and public hostnames that resolve (or rebind) to private addresses — and the API rejects internal registry hosts at deploy time. Public registries are entirely unaffected: Docker Hub, GHCR, Quay, ECR, and your own public registry all continue to work unchanged. The fix shipped to production the same day it was reported.

Credit. Thank you to N0b0t for the careful, responsible report — awarded under our rewards programme.