Security policy
Reporting a vulnerability
Section titled “Reporting a vulnerability”Please do not open a public issue for a security problem. Report it privately through GitHub: Report a vulnerability (Security tab → Advisories → Report a vulnerability). Include what is affected (editor, desktop app, MCP server, CLI, a runtime or a package), the version, and steps or a file that reproduces it.
We aim to reply within 3 working days, agree on a fix and a disclosure date with you, and credit you in the advisory and the changelog unless you prefer otherwise.
Supported versions
Section titled “Supported versions”| Version | Supported |
|---|---|
| 0.2.x (latest release) | Yes |
| Older versions | No: please update |
Fixes ship in a new release of every affected package (npm, NuGet, Maven Central, pub.dev, Swift, Unity, Godot and the desktop installers carry the same version).
Security audit
Section titled “Security audit”| Date | Scope | Result |
|---|---|---|
| 2026-11-10 | Release and publishing pipeline: the desktop release workflow (macOS and Windows signing), the npm, NuGet, Unity, Maven Central, Godot and pub.dev publish workflows, package contents, the Swift package manifest, and the MCP/CLI export path | No vulnerabilities found. Two hardening items open (see below) |
What was checked:
- Workflows: only people with write access can start a publish or a release (release published, tag pushed or a manual run); no workflow runs untrusted pull-request code with secrets, publishing tokens or write access; no pull request title, branch name or other outside text reaches a shell command.
- Secrets: signing and publishing credentials live on protected GitHub environments that need a maintainer’s approval for each run, are only passed to the steps that use them, and are never printed. Third-party tools run with them are pinned by version and checksum.
- Packages: each package ships only its build output and licences, with no install scripts (npm) or prebuilt downloads (Swift).
- MCP server and CLI: file paths and build inputs are never taken from MCP clients or document contents.
Follow-up on 2026-11-10: the MCP server’s editor bridge (ws://127.0.0.1:7717) accepted connections from any web
page open on the same machine, and its HTTP transport (--http) did not check where requests came from, which DNS
rebinding could exploit. Both now refuse browser requests that don’t come from the OpenBone editor or aren’t addressed
to a loopback name (packages/mcp/src/local-only.ts). Fixed in 0.2.1; use 0.2.1 or later if you run --http or the
bridge.
Open hardening items (not vulnerabilities): run the Unity and Godot publish jobs in the protected release
environment, and pin the Godot binary that the addon test downloads by checksum.
How OpenBone is built to be safe
Section titled “How OpenBone is built to be safe”- Scripts in animation files run in a sandbox: QuickJS in the web player and the native runtimes, Jint in C#, with no file, network or host access beyond the inputs the document declares.
- The MCP server talks to its client over stdio, or over HTTP and a WebSocket bridge bound to
127.0.0.1only, so other machines can’t reach it, and both refuse requests from web pages other than the OpenBone editor. - Desktop installers are built by GitHub Actions from the tagged source. The macOS app is signed with a Developer ID and notarized by Apple; Windows code signing is being set up.
- Dependencies are permissively licensed open source, and npm packages are published with provenance, so anyone can check which commit and workflow built them.
OpenBone is MIT licensed and made by UXCentury. The example art, voices and sounds are credited in the repository.