Reporting a vulnerability

Report security vulnerabilities in Secronyx privately to:

security@secronyx.com

The project follows coordinated disclosure. Please allow 90 days for a fix before public disclosure. That is the policy as stated in SECURITY.md in the repository; this page adds the practical detail — what is in scope, what to include, and what happens next.

Do not use the public tracker

Blank issues are disabled on the repository, and both the bug report template and the issue chooser say the same thing: security vulnerabilities are reported privately as described in SECURITY.md, not filed as an issue. Do not use a discussion or a pull request either.

The reason is specific to what this software is. Secronyx runs with enough privilege to read system state on production hosts, frequently across a fleet, and it is deliberately deployed in environments where the alternative — handing an AI agent a shell — was judged unacceptable. A public report of a flaw in its authentication, authorization, redaction or command-construction path is directly actionable against every host running it, before any operator can patch. A pull request that silently fixes an injection is a public report: the diff is the exploit.

If you have already filed publicly, email the address anyway and say so, so the fix can be prioritised accordingly.

What is in scope

SECURITY.md states the threat model the design is built against. A report is in scope if it defeats one of these mitigations:

Concrete examples of reports that would be taken seriously:

• Command injection. A tool argument that reaches a shell, a PowerShell script or an XPath filter without validation or quoting. The 1.0.0 release fixed exactly this class: a crafted IIS site_name could execute commands with the agent's privileges on a host with IIS installed.
• Authentication bypass. Any request reaching tools/call without a valid credential when authentication is configured; a forged, expired or replayed token being accepted; an mTLS identity mapping that matches a certificate it should not.
• Authorization bypass. Invoking a tool outside the caller's granted scopes, or a sensitive-scope tool appearing in tools/list or answering a call without --enable-sensitive.
• Path policy escape. Getting a tool that takes a caller-supplied path to read outside the allowed roots, through symlinks, traversal, race conditions between check and open, or the deny list failing to match key material.
• Probe policy escape. Getting get_network_latency to reach a cloud metadata endpoint, a link-local address or loopback when it should not — DNS rebinding, an address family the check misses, a redirect being followed.
• Redaction failure. A code path that returns a credential, private key, token or connection-string password verbatim when redaction is enabled.
• Any write. The agent is read-only by design. A tool that modifies, creates, deletes or signals anything, or that can be made to, is a vulnerability regardless of impact.
• Audit integrity. Suppressing an event, forging a client address into the log, or breaking the hash chain without detection.
• Denial of service that survives the documented resource limits: the rate limiter, the concurrency cap, the 4 MiB result cap, the HTTP timeouts and the per-item deadlines.
• Vulnerabilities in the build and release pipeline, or in secronyx-token-server.

What is out of scope

SECURITY.md is explicit that the product is not:

• a replacement for network segmentation
• a way to grant shell access to AI agents
• a defence against an already-compromised host — host-level security is the assumed foundation
• a secrets manager

Reports that follow from those boundaries are generally not vulnerabilities:

• Root can read everything. An operator who runs the agent as root, enables --enable-sensitive and grants a caller the sensitive scope has chosen to expose auth logs, environment variables and certificates. That is the documented behaviour of that configuration, not a flaw.
• Configured-away controls. Findings that require --no-redact, --no-audit, --allow-unauthenticated, --rate-limit=false or a deliberately widened --allowed-paths. Each of the first four is announced: --no-redact, --no-audit and --rate-limit=false log a WARNING at start-up, and --allow-unauthenticated logs a SECURITY WARNING when the override actually takes effect on a listener. A report that one of them fails to warn, or silently does more than it claims, is in scope.
• Findings in features marked as planned. SECURITY.md marks Unix socket transport, named pipe transport, config file support and hot reload as planned rather than implemented. Their absence is not a vulnerability.
• Automated scanner output with no demonstrated impact, missing hardening headers on /health, and the like. Explain the impact, or expect the report to be closed.

If you are unsure which side of the line a finding falls on, send it. A short exchange costs less than an unreported flaw.

What to include

A report that can be reproduced is fixed in a fraction of the time one that cannot. Include:

1. Version. The full output of secronyx --version — version, commit, build date, Go version, OS and architecture.
2. Platform. Distribution or OS version, and whether the agent runs as a service, in a container, or under Kubernetes.
3. Transport. stdio, HTTP, or the hybrid/SaaS poller. These are different code paths with different controls; the hybrid executor in particular does not go through the MCP server's scope enforcement, as Hybrid and SaaS mode explains.
4. Configuration. The flags and environment variables in effect, with secrets removed. Redact tokens, client secrets, API keys and private key paths before you send anything. Whether authentication is configured, which authenticator, whether TLS is on, which scopes are registered and whether --enable-sensitive is set are usually the decisive facts.
5. The tool and arguments, if a tool call is involved — the exact tools/call request body.
6. Reproduction steps. Minimal, ordered, and complete enough to run. A JSON-RPC request and the response it produced is ideal.
7. Impact. What an attacker gains, and what position they need to start from: unauthenticated on the network, an authenticated caller with a narrow scope, a local user, a compromised control plane.
8. A suggested fix, if you have one. Welcome, but not required, and please do not open a public pull request for it.

Please do not include real credentials, customer data or log extracts from production systems in the report. A synthetic reproduction on a test host is worth more and risks less.

What happens next

Reports go to security@secronyx.com and are handled privately. The repository does not publish a target acknowledgement or triage time; if you need one for your own disclosure planning, say so in the report and ask.

Fixes are shipped as a new release rather than as a patch to an older tag: semantic-release is configured to release from main only, so there is no maintenance branch for previous versions. See Releases and versioning. A security fix lands as a fix: commit, or as a BREAKING CHANGE: where the fix must change a default or a flag, and appears in the release notes and in the Security section of CHANGELOG.md. That section is written to be operationally useful: it says what the flaw allowed, not merely that something was hardened. The 1.0.0 entry is the model.

Coordinated disclosure means the 90-day window runs both ways. The project asks you to hold publication for that period; in exchange, say in your report whether and when you intend to publish, so the fix and any advisory can be timed to be useful to operators. If you want to be credited, or not credited, in the release notes, say that too — the repository does not state a default.

Hardening before you need this page

Most of what gets reported as a vulnerability is a configuration that was never tightened. The defaults are sound — stdio only, redaction on, audit on, sensitive tools unregistered, non-loopback binds refused without authentication and TLS — and the failure mode is an operator who turned one off to get something working and left it off.

Before exposing an agent beyond the host it runs on, read the Security model, then Authentication and Scopes and authorization, and confirm that Audit logging is writing somewhere you can verify. Remote access over HTTP covers the network exposure rules the server enforces at start-up.

Other contacts

Non-security bugs go to the repository's bug report template; usage questions go to Discussions. See Contributing.

Related pages

Security model · Authentication · Scopes and authorization · Redaction · Audit logging · Network and path policy · Releases and versioning · Documentation home