OpenMBB talks to a motorcycle's Main Bike Board over a serial console and can, on explicit confirmation, write settings or send destructive commands. A flaw that lets the tool send something dangerous it shouldn't — or that could damage a bike — is treated as a security issue, not just a bug.

Please report suspected security issues privately rather than opening a public issue, so a fix can land before details are widely known:

• Use GitHub's Report a vulnerability (Security → Advisories) on this repository, or
• Open a normal issue that says only "security — please contact me" (no details), and the details can be exchanged privately.

Helpful things to include: what you did, what the tool sent (or would send) to the bike, the model/firmware, and why it's dangerous.

In scope — examples of what's worth reporting:

• A way to get a destructive command onto the wire without the informed-consent confirm (e.g. bypassing the control-character / multi-line refusal, or the raw-box set refusal).
• A write that skips the whitelist re-validation in Transport.write_setting.
• A path that could brick a component or leave the bike in an unsafe state more easily than the documented, confirmed flow.
• A PII leak (VIN, serials, passwords) into logs, saved reports, or the repo.

Out of scope:

• The documented, confirmed behavior of destructive commands. OpenMBB is deliberately read-first but does not hard-block dangerous commands on your own bike — it gates them behind a typed confirm. That's by design (see the README "Safety model"), not a vulnerability.
• Anything requiring a bike other than a 2017 Zero FXS at MBB rev 41, which is the only hardware the safety lists are verified against — but a report that the tool is unsafe on another model is very welcome.

OpenMBB is an unofficial hobby tool provided with no warranty (see LICENSE). It is not affiliated with Zero Motorcycles or Sevcon/BorgWarner.