Publisher releases continuously off main; there are no maintenance branches, so only the latest release is supported. Fixes land in the next release — upgrade rather than expect a backport.

Report privately: Report a vulnerability (repo → Security → Advisories → Report a vulnerability).

What to include, as much as you have:

• The affected version or commit.
• How Publisher was configured and reached — flags, host binding, gateway or none.
• Reproduction steps, or a proof of concept.
• The impact you believe it has.

• If you're unsure, report privately — we'd rather triage a non-issue in private, and we'll move it into the open once it's clearly not sensitive.
• Anything that exposes data or credentials, or executes code across a boundary Publisher claims, goes private — always.
• An issue that only weakens defense in depth behind the documented trusted tier is reasonable to file in the open.

Publisher is unauthenticated by design, and several governance features are documented as caller-asserted conventions rather than boundaries — that shapes what counts as a vulnerability here.

• The REST and MCP surfaces being unauthenticated, and the server binding 0.0.0.0 by default (README.md § Point your agent at it, docs/ai-agents.md). The supported posture is loopback for local use, an authenticating gateway in front for anything wider.
• givens, #(authorize), and row-level access being caller-asserted, including the gaps in docs/authorize.md § Security model and § Known limitations, and in docs/row-level-access.md.
• A gate skipped for a request carrying x-publisher-bypass-authorize: true — the documented data-management bypass (docs/authorize.md § Authorize bypass). Publisher bounds nobody who may send it; stripping it at the edge is the deployment's job (docs/authorize-bypass-deployment.md). A finding that Publisher honours the header is working as documented. A finding that it honours one it should not — on a notebook or /compile request, from a body field, or without counting and logging it — is in scope below.
• Broad reach for whoever can publish a package or PATCH a connection on a bare Publisher (docs/query-metadata.md, docs/packages.md).
• The default Content-Security-Policy: frame-ancestors *, which PUBLISHER_FRAME_ANCESTORS exists to tighten (docs/html-data-apps.md § Security model, docs/configuration.md).
• Findings that require ignoring the deployment posture above.

Anything that breaks a boundary Publisher does claim, including:

• A direct query succeeding against a source the package never exported — past the queryable == discoverable boundary in docs/discovery-and-access.md.
• An #(authorize) gate granting access its expression should deny for the givens actually sent, including none — absent the documented bypass header above.
• The bypass applying where it should not: honoured on a notebook cell or /compile request, reachable from the request body rather than the header, surviving onto a subsequent request, or skipping a gate without incrementing publisher_authorize_bypass_total and logging it.
• Connection credentials or secrets leaking through an API response, log line, or error.
• Escaping a package's static root — path traversal or symlink past the rejections in docs/html-data-apps.md § Security model.
• Remote code execution via package load or model compile.
• A reachable vulnerability in a bundled dependency.

• Acknowledgement within 5 business days.
• An in-scope-or-not call, with a rough timeline, within 10.
• The advisory stays private until a fix ships.
• You're credited in the published advisory unless you'd rather not be.

Running Publisher where it can be reached? The deployment posture is in README.md § Point your agent at it, and the trust models behind givens are in docs/authorize.md § Security model and docs/discovery-and-access.md.

docs/security-posture.md states the whole trust boundary in one place, including the known gaps in it. Read it before deploying Publisher somewhere reachable, or before adding a feature that has to be judged against the boundary.