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 working days.
• Triage + severity: within 5 working days.
• Fix: as fast as the severity warrants — critical cross-tenant issues are same-day where we can.
• Reward processing: up to 20 working days from the moment we confirm the severity. We verify the finding, check it against earlier reports, and ship or schedule the fix before credits are applied, so please allow the full window before asking after a payout.

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. Processing a reward takes up to 20 working days after confirmation; we'll tell you the outcome on your report either way. 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.

Hall of fame

The people below found something real, reported it responsibly, and made bootload safer for everyone using it. Ordered by number of confirmed advisories; researchers are listed by the name they asked us to use.

Reported something and want your name (or handle, or a link) shown differently? Reply on your report and we'll change it — this list is yours as much as ours.

Machine-readable policy

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

Advisories

BL-2026-007 — Control-plane edge ran an unpatched NGINX (CVE-2026-42533) · Fixed

The report itself was a version-disclosure finding: our edge advertised its exact build in the Server header. CVSS 3.1 5.3 (Medium) AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. On its own that is informational — but the version it named, nginx 1.31.2, falls inside the affected range of CVE-2026-42533 (heap buffer overflow reachable pre-authentication; fixed upstream in 1.30.4 / 1.31.3), so we treated it as a live question rather than a banner nit.

We were not exploitable. That vulnerability requires a map directive using a regular expression that references numbered capture variables; our configuration contains no such map, and our worker fleet — which serves all customer applications — already ran a patched release. Only the control-plane edge was on an affected build.

Fix: the control-plane edge was moved to nginx 1.31.4 and version advertising was disabled (server_tokens off). No customer application was served by the affected component. We are crediting this report on the merits of what it prompted us to verify and patch, not on the disclosure alone.

BL-2026-006 — Verification-link lifecycle and a missing build rate limit · Fixed

1) A new verification link did not retire the previous ones. Using a link already invalidated its siblings, but issuing a new one did not — so several links could be live at once. CVSS 3.1 3.1 (Low) AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N; every link is delivered to the same mailbox, which bounds the impact, but it is the CWE-613 hygiene the reporter described. Fix: issuing a verification link now invalidates any earlier ones. (A second report — the same link surviving a password change — shares this root cause and is closed by the same change.)

2) No rate limit on build creation. An authenticated account could create build environments in a loop. CVSS 3.1 4.3 (Medium) AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L; in practice we rate the real-world impact lower, because builds are prepaid and the cost falls on the account performing them. Fix: build creation is capped per account (20/hour) and returns 429 beyond that.

Also assessed, not vulnerabilities. Three further reports in this batch did not reproduce, and we think the reasoning is worth publishing: sessions surviving a password change — changing a password deletes every session token server-side and each request re-validates its token against the database; authentication bypass by replaying a captured login response — signing out destroys the token server-side, so a replayed response only repopulates the attacker's own browser with a dead credential; and session token stored in browser storage — a deliberate design choice for our browser application, with a strict Content-Security-Policy, no-store on authenticated pages and server-side token destruction as compensating controls. In each case we invited the reporter to reopen with a captured API exchange if they can show otherwise.

BL-2026-005 — Organization could be left without an owner (race condition) · Fixed

An organization must always keep at least one owner, and the application enforced that on every request. The check, however, ran as a read followed by a separate write — count the owners, then apply the change — with no transaction and no locking in between. Two requests sent at the same moment each passed their own check, and together removed every owner, leaving the organization unmanageable: no remaining member could perform owner-only actions.

The reporter demonstrated two variants: concurrent role changes demoting all owners, and an administrator — a role below owner — concurrently removing all owners. CVSS 3.1 4.2 (Medium) AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L, scored on the administrator variant, since a role below owner should never be able to defeat that boundary. Access complexity is High because the requests must genuinely race.

Fix: both paths are now a single database transaction that locks the organization's membership rows before counting and re-checks the invariant inside that transaction; a request that would remove the last owner fails with 409. A concurrency test now fires both requests simultaneously and fails our build if an organization can ever be left without an owner. Both reported variants share this root cause and this fix, and were credited together.

BL-2026-004 — Invitation acceptance: not bound to the invited account, and able to overwrite an existing role · Fixed

Two distinct flaws in the same code path, reported independently.

1) The invitation was bound to the token, not to the invited address. Accepting an invitation added whoever redeemed the link to the organization with the invited role, without ever checking that the signed-in account matched the address the invitation was issued to. Anyone who came by a live invitation link — a forwarded email, an intercepted message — could join as themselves. CVSS 3.1 4.2 (Medium) AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, with access complexity reflecting that an attacker must first obtain an outstanding link. We note that an intercepted invitation carrying an administrator or owner role would be materially worse, which is why this was the batch's priority fix. Fix: acceptance now requires the signed-in account's email address to match the invitation; anything else returns 403 naming the account to sign in as.

2) Accepting an invitation overwrote an existing membership. The membership write was an upsert, so accepting an invitation replaced the role of someone already in the organization. A sole owner who invited their own address as a lower role and accepted it was left with an organization that had no owner, recoverable only with our help. CVSS 3.1 3.5 (Low) AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:L — owner privileges and a deliberate acceptance are required, and no data is exposed, but the recovery cost is real. Fix: an invitation now only ever adds a member and never rewrites the role of an existing one; role changes go through the members screen, which enforces the last-owner rule (see BL-2026-005).

How we handled duplicates. These two findings arrived from different researchers and are genuinely different defects, so both were credited. Where a single researcher reported the same underlying defect through two endpoints, we credited it once with variant credit — the rule we apply consistently, and one we explain in our reply rather than leaving it implicit.

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.