By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
DenyAccept

Security

Braiins builds firmware, a mining pool and fleet management software that a large part of the Bitcoin network runs on. If you have found a security issue in any of it, we want to hear from you before anyone else does, and we will work with you on a fix and on the public disclosure.

This document sets out how to report an issue to us, what we commit to in return, and how we handle disclosure. It is informed by the coordinated vulnerability disclosure practice described in ISO/IEC 29147 and ISO/IEC 30111.

In this policy, "Braiins", "we" and "us" mean Braiins Systems s.r.o. and its Affiliates. An "Affiliate" means any entity that controls, is controlled by, or is under common control with Braiins Systems s.r.o. Different Affiliates operate or publish different products. A report is handled by, and the commitments in this policy are given by, the Affiliate that operates or publishes the product your report concerns, and we will tell you which entity that is.

How to report

Email [email protected]. Please encrypt anything sensitive with our PGP key (fingerprint D120 E69A 68F8 C228 20FB FD3B 5FAC 1904 B64C 9C23, available at braiins.com/security/pgp.asc). If you would rather use an end-to-end encrypted messenger, say so in a first message with no technical detail and we will set up a Signal channel.

Do not open a public issue, a pull request, a support ticket or a forum post for a security issue. Our support team escalates anything it recognises as a security report, but do not rely on that route, and a public tracker cannot be un-published.

Include:

  • What the issue is and what an attacker gains from it.
  • Which product and version is affected, including the exact firmware build or URL where relevant.
  • How to reproduce it. A proof of concept, a script, a packet capture or a screen recording. For firmware issues, the concrete steps against a named device model.
  • Your name or pseudonym, if you want us to consider crediting you publicly when the issue is disclosed, and optionally a link.

Reports in English please. Czech is fine too.

What you get from us

Two of these are firm commitments and the rest is how we intend to work. We would rather be straight about which is which than publish a list of deadlines and miss them.

The commitment: a reply within 5 business days. A human reply, not an autoresponder. If you think the issue is already being exploited, put that in the subject line and we will treat it as urgent instead of letting it wait in the queue. A reply means an acknowledgement from a named person and, where we already have one, a first view of the report; it is not in itself an acceptance of the report or of any severity.

Then, and without putting a date on any of it:

  • We tell you whether we accept the report, what severity we give it, and what we intend to do about it.
  • We keep you informed while it is open, including when the answer is that nothing has changed.
  • No legal action against you for good faith research, under the safe harbour terms and the limits set out below. That one is a real undertaking, not an intention, within those limits.
  • Coordinated disclosure. We aim to agree the publication date and the wording with you, and we do not publish your finding as ours. We will not ask you to stay silent indefinitely, unless publication would keep users at material risk, and if that happens we will tell you why. What we publish, and when, stays our decision.

We are not going to promise you a fix inside a fixed number of days. Firmware ships on a release cadence, some fixes depend on a hardware vendor, and a date we invent to look responsive is worth nothing to you. What we will do is tell you what we are doing and when we expect it, and tell you again if that changes.

Severity

We classify every accepted report into one of four classes.

Critical. Loss or theft of funds, or a compromise that scales across a fleet or across accounts without per-target effort. Examples: signing or payout manipulation in Braiins Pool; order or settlement manipulation in Hashpower; remote code execution on mining devices reachable at scale; installation of unsigned or modified firmware on a device the attacker does not physically control.

High. Compromise of a single device or account with significant impact, or a break of a security control that protects funds or credentials. Examples: authentication bypass on a miner's management interface; extraction of stored pool credentials or licence secrets; cross-account access in Braiins Manager or Hashpower; an unauthenticated endpoint serving another account's data; permanent and unrecoverable bricking of devices by a remote attacker.

Medium. Meaningful loss of a security property under conditions that limit the attack. Examples: an issue requiring an unusual configuration, adjacency on the local network combined with user interaction, or exposure of non-credential data about another account.

Low. A real weakness with limited impact, or a defensive control that falls short of its intended strength without a demonstrated route to abuse.

We decide the classification. We will explain the reasoning, and if you disagree we will hear the argument.

Remediation and disclosure

Severity drives how hard we push. We intend to work on Critical and High ahead of feature work and to ship a fix as soon as we can build and validate one. Medium and Low ride the normal release cadence. Where a case needs a firm date, for instance because you are planning your own publication, we try to agree that date with you for that case rather than pointing at a rule.

We ask you not to publish before a fix is available to users, because our users cannot patch a miner they do not know is vulnerable. Where an issue is already being exploited, we may disclose faster than the schedule above, and we will tell you when we do.

When we disclose, we aim to publish enough for an operator to act: what the weakness was, which versions and device families were affected, what an attacker could achieve, and what to do about it. We do not publish proof of concept code or exploitation details on the same day, and we may hold that back for longer or indefinitely.

We may also delay the advisory itself where publishing it would put operators at more risk than it protects them from, which on mining fleets is a real case, because upgrade cycles are slow and a detailed advisory on day one arms an attacker against everyone who has not upgraded yet. Where we do that, we tell you, we say why, and we give you our current expectation of timing.

Scope

In scope, all operated or published by Braiins:

  • Braiins OS firmware, all supported device families and build targets, including the update and signing mechanism, the management interface and the on-device APIs.
  • Braiins Pool, including stratum endpoints, the web application, payouts and account management.
  • Braiins Manager and its backend.
  • Braiins Toolbox and Farm Proxy.
  • Hashpower, the hashrate marketplace: the web application and its APIs, onboarding and authentication, order matching and the settlement side.
  • Farm Monitor
  • braiins.com and other *.braiins.com services operated by us, but not services that run on a third-party platform even where they appear under our domain.

We are interested in anything that puts funds, credentials or account isolation at risk, or that breaks the integrity of firmware, configuration or payouts.

Third-party platforms we use but do not operate, third-party components inside our products, and the systems, facilities and accounts of our customers are outside this policy. We cannot authorise testing of someone else’s systems, and the safe harbour below does not extend to it.

Assume, as we do, that an attacker may be on the same network segment as the miners, may control the management host, may hold a valid account on any of our platforms, may be an insider at a hosting facility, and may have physical access to individual machines.

If you are not sure whether something falls inside this, ask us rather than guessing. We would rather answer that question than have you drop a finding because our scope section was unclear.

Out of scope

  • Volumetric denial of service and stress testing against our websites, APIs or stratum endpoints. Report design flaws that make such an attack unusually cheap, do not run one.
  • Output of automated scanners without a working proof of concept, missing HTTP security headers, weak TLS configuration and outdated dependencies, in each case where no exploitable path is demonstrated.
  • Clickjacking and tabnabbing with no security consequence, self-XSS, and issues requiring a browser or platform that is out of support.
  • Phishing, social engineering, physical intrusion and anything targeting our employees, contractors or hosting partners rather than our products.
  • Websites, apps, social accounts, downloads and pool endpoints that imitate Braiins or use our name without being operated by us. We want to know about them, so tell us at [email protected] and we will act on it, but they are someone else's systems: we cannot authorise you to test them, and the safe harbour does not cover doing so. Reporting an impersonation is not a vulnerability report and the timelines above do not apply to it.
  • SPF, DKIM and DMARC observations without demonstrated impact.
  • Issues that require the attacker to already hold administrative credentials, or that require the operator to have deliberately disabled a protection.
  • Products and services we do not operate, including third-party pools, hardware we did not manufacture, and firmware forks not published by us.

What makes a report eligible

A finding has to be more than an argument that something might be possible.

  • Fixable by us. If no change to our firmware, software or infrastructure could prevent the attack or make it meaningfully more expensive, it is not a finding against us. Physical destruction of a machine an attacker already holds is the obvious example.
  • Better than what an attacker can already do. If an attack achieves nothing more than something unpreventable achieves under the same preconditions and at the same cost, it does not change our users' position.
  • Against a control's intended strength. Some protections are best effort and their defeat given enough time, hardware and physical access is part of our threat model. Defeating one in the anticipated way is not a finding. Showing a substantially cheaper route, or an implementation error that makes it weaker than designed, is.
  • Demonstrated, not theoretical. Show the behaviour. For protocol and network issues, a reproducible sequence against a named build. For anything on a device, the device model and the steps. For a side channel, a measurement plus a working extraction. Code that is written to enforce a security property and demonstrably fails to do so is an exception and needs no attack demonstration.

We may change code or behaviour a report concerns without accepting the report as eligible. We do that for defence in depth and to reduce future report volume, and it does not imply we agreed with the finding.

Rules for researchers

  • Act in good faith and avoid harm to us, our products and systems, our users and third parties.
  • Use exploitation only as far as needed to confirm the issue exists. Do not pivot, do not persist, do not access or modify data that is not yours.
  • Test against your own devices and your own accounts. If you need something to test against, ask us first.
  • Do not degrade our services, and do not run anything that affects other users' mining.
  • If you come across personal data, stop, tell us, and do not retain a copy. We may then have to notify a supervisory authority or the people affected and to describe what happened, including your part in it, and nothing in this policy prevents that.
  • Give us the time set out above before publishing.
  • Do not publicly disclose the fact or the content of your report before disclosure has been agreed under this policy.
  • Do not make your report, or your silence about it, conditional on a payment or any other benefit.
  • Keep to applicable law, including sanctions and export control rules, and tell us if you are researching on someone else’s behalf.

Safe harbour

If you follow this policy, we treat your research and your report to us of what you found, as authorised by us, and, so far as this is ours to give and for as long as you keep to this policy:

  • We will not bring civil action against you for that research or for reporting it to us, and we will not file a criminal complaint about it. This does not stop us from complying with a court order, with a request from the police or another authority, or with a legal duty to provide information. It also does not affect any claim, ours or anyone else’s, for loss or damage caused by your research, which the limits below deal with.
  • We consider your research authorised with respect to applicable anti-hacking and anti-circumvention law. That includes the anti-circumvention provisions implementing Directive 2001/29/EC (in the Czech Republic, Section 43 of Act No. 121/2000 Coll.) and, where US law applies, 17 U.S.C. 1201 (the DMCA). We will not bring a claim against you for circumventing technological measures protecting our products, including firmware signature verification, in the course of research under this policy. This covers devices, copies and accounts you own or are authorised to use, and our own technological measures; it does not extend to measures protecting third-party software or content in or alongside our products.
  • For the limited purpose of security research under this policy, we will not enforce against you those restrictions in our terms of service, licence terms or acceptable use policy that would otherwise prevent that research on a device or copy you own or are authorised to use. This is an undertaking not to enforce for that purpose. It is not a licence, it gives you no right in our software or other intellectual property, and it does not affect any licence fee, the devfee or any distribution term.
  • If a third party takes action against you for research conducted under this policy, tell us. Where we are satisfied that the research was conducted under this policy, we will confirm in writing, to you and where it helps to that third party, that it was authorised by us on the facts known to us. We do not take over your defence and we do not indemnify you.

Some limits we would rather state up front than have you discover later.

What the safe harbour covers, and what it does not. It covers two things: looking for a vulnerability within this policy, and telling us what you found. It does not cover what your research does. If you damage, disrupt, destroy or degrade anything, if you access, copy, retain, publish or otherwise disclose data, source code or other material you were not authorised to take or to publish, or if you cause loss to us, to our users, to our customers or to anyone else, you are responsible for that in the ordinary way, whether you caused it deliberately or not. Nothing in this section limits any claim in respect of it, ours or anyone else’s. The same applies to anything you do with a finding other than reporting it to us. Telling us promptly and helping us limit the harm is something we take into account; it is not a release.

We cannot bind third parties. If your research touches the network, systems or data of someone who is not us, a hosting provider, a customer's facility, a pool user, we cannot authorise that on their behalf and we cannot defend or indemnify you against them.

Criminal prosecution in the Czech Republic is not ours to waive. Unauthorised access to a computer system is prosecuted by the state under Section 230 of the Czech Criminal Code, not by us. What we can do, and will do, is decline to file a complaint and confirm to the authorities, on the facts known to us, that your research was conducted under this policy and with our authorisation. We are not going to promise you immunity we do not have the power to give.

What this waiver does not cover. Circumventing licence enforcement, the devfee mechanism or firmware signing in order to use, modify or distribute our firmware outside its licence terms, or building or distributing tools for that purpose. Finding and reporting a weakness in those mechanisms is research and is covered. Using it, or shipping it to others, is not. Publishing the working means of a bypass, as opposed to a description of the weakness, is not covered either.

If you are unsure whether something is inside this policy, ask us before you do it. Contacting us first weighs heavily in how we judge good faith.

Status of this policy

This policy is a statement of how we work, not a contract. We do treat the safe harbour as an undertaking we are bound by. Nothing else in this policy is intended to create a legal claim against us, and nothing in it is an admission that a product is defective or that we owe a duty we would not otherwise owe. We may change this policy, and the version that applies to a report is the one published when you send it. Nothing here limits our rights against a person who does not keep to this policy, or our obligations under applicable law. This policy is governed by Czech law and the Czech courts decide any dispute about it, which does not affect the undertaking described under Safe harbour where US law applies.