Thank you for helping us keep OpenMAIC secure! We take the security of our platform, multi-agent engine, and users very seriously.

We currently provide security updates for the latest major release and the active main branch. Please ensure you are running the most recent version of OpenMAIC before submitting a report.

If you discover a security vulnerability in OpenMAIC, please do not create a public GitHub issue. Publicly disclosing a vulnerability can put other users and self-hosted instances at risk.

Instead, please report it privately using one of the following methods: GitHub Private Vulnerability Reporting: Go to the Security tab of the repository, click on "Advisories", and select "Report a vulnerability".

What to include in your report:

• A description of the vulnerability and its potential impact.
• Detailed steps to reproduce the issue.
• Any relevant logs, screenshots, or code snippets.
• (Optional) Suggested mitigation or a patch.

We will acknowledge receipt of your vulnerability report within 48 hours and strive to send you regular updates about our progress.

• Reproduce the issue on the latest release or on main. A report that only affects a version already fixed by a published release is closed as a duplicate.
• Search the published security advisories. Variants of a published advisory are welcome; explain what the existing fix misses.
• Where possible, demonstrate the issue against the default deployment (the shipped Dockerfile, docker-compose.yml, and .env.example). If the finding depends on a non-default setting or a different network topology, name that setting in the report.

OpenMAIC's security boundaries are designed around the assumptions below, and reports are assessed against them.

• ACCESS_CODE is a shared site password, not user authentication. Everyone who knows the code has the same access, and it does not separate users from each other. Its resistance to guessing depends on the code itself, so use a long random value.
• The render service is an isolation boundary only in its shipped configuration. It executes untrusted HTML in headless Chromium and relies on the container's egress lockdown (RENDER_EGRESS_LOCKDOWN=true, the default, which needs CAP_NET_ADMIN) and on an isolated network (internal: true in Compose). Disabling the lockdown or placing the service on a routable network is an operator opt-in; see render-service/README.md.
• Forwarding headers are trusted only when TRUST_PROXY_HEADERS=true. Enable it only behind a reverse proxy that overwrites X-Forwarded-For and X-Real-IP.
• PERSISTENCE_DEV_TOKEN does not provide user isolation. It is meant for local or trusted private networks and must not be used as authentication for a public deployment.
• Server-side configuration is trusted operator input. Endpoints an operator sets through environment variables (for example OLLAMA_BASE_URL or RENDER_SERVICE_URL) are not subject to the outbound URL guard. URLs supplied by end users at request time are untrusted and must pass the guard.

• Maintainers confirm the report, agree on the affected code paths, and assign a severity using CVSS v4.0. The published vector reflects the maintainers' assessment of the default deployment described in this repository (the shipped Dockerfile, docker-compose.yml, and .env.example); deployment-specific amplification is described in the advisory text rather than baked into the base score.
• If you disagree with the proposed severity, say so in the advisory thread before publication. We will answer every severity objection in the thread before we publish, and we will not publish while a metric is still under active discussion.
• Behaviour that an operator explicitly opts into and that is documented as unsafe for public deployments (for example ALLOW_LOCAL_NETWORKS=true) is evaluated against its documentation: we treat it as a hardening request when it does what the documentation says, and as a vulnerability when it is unsafe beyond that. Findings that only hold after one of the Deployment Assumptions is broken are evaluated the same way.

When a vulnerability is confirmed and patched, we will publish a GitHub Security Advisory detailing the issue, the impacted versions, and the fix. We will also credit the security researcher who reported the issue (unless they prefer to remain anonymous).

• For every accepted advisory the maintainers request a CVE identifier through GitHub at publication time, so the CVE description, affected versions, and score match the advisory. Please do not request a CVE for an OpenMAIC advisory from another CNA; if one already exists, tell us and we will link it.
• Publication happens after the fix is released. The advisory, the release notes, and the CVE record are published together.
• Advisory collaborators should not edit a published advisory's severity or description without raising it in the thread first; maintainers keep the published advisory consistent with the CVE record.