# Security Policy

e2a is an authenticated email gateway. A vulnerability in this codebase
can affect every deployment that uses it — including the ability to
forge signed `X-E2A-Auth-*` headers, bypass HITL approval gates, exfil
inbound mail, or spoof agent identity. We take that responsibility
seriously and ask that you report issues privately rather than in
public GitHub issues.

For what e2a stores, how long it lives, log handling, and the user/operator data-rights surface, see [docs/data-handling.md](docs/data-handling.md).

## Reporting a vulnerability

Email **security@mnexa.ai** with:

- A description of the issue
- Steps to reproduce (or a proof-of-concept)
- The version / commit you observed it on (run `e2a -version` or check
  `VERSION` in the repo)
- Any mitigations you suggest

You can also use GitHub's [private vulnerability reporting](https://github.com/Mnexa-AI/e2a/security/advisories/new)
to file a draft advisory directly against this repo.

We aim to:

- **Acknowledge receipt** within 3 business days
- **Provide a substantive response** (preliminary assessment + next steps)
  within 7 business days
- **Ship a fix** for confirmed high-severity issues within 30 days,
  faster when active exploitation is plausible

We will credit reporters in the release notes unless you ask to remain
anonymous. We don't currently run a paid bounty program.

## Supported versions

| Version | Status |
|---------|--------|
| Latest tagged release on `main` | ✅ Receives security fixes |
| Older minor versions | ❌ Please upgrade to the latest |

The project is pre-1.0; we maintain only the most recent release line.
Self-hosters running pinned versions should plan to upgrade promptly
when an advisory is published.

## Scope

In scope (please report):

- Authentication bypass — anything that lets an unauthenticated caller
  reach an authenticated endpoint, or that lets one user act as another
- Forging or replaying `X-E2A-Auth-*` headers (HMAC, timestamp, body
  hash) without knowing the signing secret
- Bypassing HITL approval (sending an outbound message that should
  have been held for review)
- SPF/DKIM verification flaws (causing inbound mail to be marked
  verified when it shouldn't, or vice versa)
- SSRF in webhook delivery, OAuth callback handling, or any other
  outbound HTTP path
- Privilege escalation across users, agents, or domains
- SQL injection, command injection, path traversal
- Memory-safety issues in the Go server (e.g. in the SMTP parser)
- Cryptographic flaws (HMAC misuse, weak random, predictable IDs)

Out of scope:

- Deployments running with the example `change-me-in-production` HMAC
  secret (the server refuses to start with it; reaching this state
  requires deliberate misconfiguration)
- Lack of features (e.g. "no rate limit on X" — open an issue or PR)
- Vulnerabilities in dependencies that don't have a reachable code
  path through e2a (please file with the upstream project)
- Issues only reproducible against `agents.e2a.dev` infrastructure
  rather than the OSS code (those go to the hosted-product security
  team via the same email)
- Email deliverability complaints, spam filter behavior

## Disclosure timeline

Once a fix is merged and released, we will publish a GitHub Security
Advisory describing the issue, affected versions, and remediation. We
ask that reporters hold public disclosure until the advisory is
published or 90 days after first contact, whichever is sooner.

## Bug-bounty alternatives

We don't pay bounties yet. If you'd like recognition beyond credit in
the advisory — a public thanks on the website, a swag pack — say so in
your initial report and we'll do our best.
