Stella runs shell commands, edits files, and talks to model providers on your behalf — we take the security of that surface seriously, and we appreciate the researchers who help keep it tight.
Please do not open a public issue for security problems.
Report privately via GitHub's private vulnerability reporting — it goes straight to the maintainers, and you get credit in the advisory when it's published.
Include what you'd want in any good bug report: affected version/commit, a reproduction, and your assessment of impact. We aim to acknowledge reports within 72 hours and to ship a fix or a mitigation plan within 30 days for confirmed issues, keeping you informed along the way.
Especially interesting, given what Stella promises:
- Workspace-root escape — any way a tool call (file CRUD,
bash,grep/glob) reaches outside the pinned workspace root: traversal, symlinks, race conditions. - Phone-home violations — telemetry, update checks, or analytics leaving the
machine in Community/default mode. Zero is the contract there, and the only
governed exception is an explicitly enrolled Oxagen Enterprise seat. Network
traffic the user asked for is not a violation: the chosen model provider,
configured MCP servers, the opt-in
webtools (web_fetch/web_extract_assets/web_download, andweb_searchagainst your own Brave/Tavily key), andgh/Linear when an issue backend is connected. Traffic from any of those to a host the user did not configure is in scope. - Credential exposure — API keys leaking into logs, telemetry, error messages, or files with permissive modes.
- Prompt/tool injection with impact — untrusted content (repo files, MCP frames, provider responses) escalating into actions the user didn't sanction, beyond what the model is already trusted to do.
- Context Graph Protocol (CGP) host boundary breaks — providers escaping quarantine: inheriting credentials, ambient filesystem access, or ungated egress.
- install.sh / release integrity — checksum bypasses, tag/asset confusion.
Out of scope: vulnerabilities in the model providers themselves, and the
inherent risk of running an agent with bash access on code you don't trust —
that's the user's judgment call, not a boundary Stella claims to enforce.
docs/design/threat-model.md enumerates the assets, the adversaries, the
trust boundaries, and the attack paths that cross them — including the risks
Stella knowingly does not defend against, and why. Read it before deciding
whether a behavior you found is a vulnerability or a documented choice: several
of the sharper edges (no SSRF guard on web tools, the sandbox covering
bash only, materially weaker guarantees off Unix) are deliberate and recorded
there.
Every artifact published by .github/workflows/release.yml carries two
independent guarantees, and they answer different questions:
SHA256SUMSproves the tarball was not corrupted or truncated. It is fetched from the same release over the same channel as the artifact it vouches for, so it does not establish origin — anything able to replace one could replace both.- A Sigstore build-provenance attestation (
actions/attest-build-provenance) proves the artifact was built by this repository's release workflow at a specific commit. It covers the tarballs andSHA256SUMS, and it cannot be reissued by whoever holds the release. No signing key is involved, so there is none to leak or rotate.
install.sh checks the checksum always, and checks provenance whenever gh is
on PATH. A verifier that runs and rejects an artifact is always fatal. A
verifier that cannot run (no gh, a gh too old, or a release predating
provenance) is a warning — so to demand the strong guarantee, ask for it:
STELLA_REQUIRE_PROVENANCE=1 curl -fsSL https://raw.githubusercontent.com/macanderson/stella/main/install.sh | shTo verify an already-downloaded artifact by hand:
gh attestation verify stella-<version>-<target>.tar.gz --repo macanderson/stellaReleases cut through the degraded local path (scripts/release.sh, used only
when GitHub Actions cannot run — see RELEASING.md) carry no attestation and
will be refused by STELLA_REQUIRE_PROVENANCE=1. Those releases say so in their
notes.
A binary that fails provenance verification is a report-worthy event under "install.sh / release integrity" above — please do not install it.
Pre-1.0, only the latest release (and main) receive security fixes.