Security fixes are applied to the current release only. We encourage all users to run the latest version.

Please do not report security vulnerabilities through public GitHub issues.

Use GitHub Private Vulnerability Reporting to disclose security issues confidentially. This allows the maintainers to assess and patch the issue before public disclosure.

Include as much of the following as possible:

• A description of the vulnerability and its potential impact
• Steps to reproduce or a proof-of-concept
• Affected version(s)
• Any suggested mitigations or patches

1. Acknowledgement — We aim to acknowledge reports within 72 hours.
2. Assessment — We will confirm the issue, determine severity, and identify affected versions.
3. Fix & Release — A patch release will be prepared and coordinated with the reporter.
4. Disclosure — A GitHub Security Advisory (and CVE if applicable) will be published after the fix is available.

We follow coordinated vulnerability disclosure. Reporters are credited in the advisory unless they prefer otherwise.

Published advisories are listed at: https://github.com/haraka/Haraka/security/advisories

Haraka is an SMTP server and plugin host. It accepts inbound network connections, parses SMTP commands and message content, and can deliver mail outbound when an operator enables relaying or outbound.

This threat model assumes the operator controls the host, configuration, enabled plugins, credentials, TLS material, and any external services Haraka is configured to use.

flowchart LR
    client["SMTP client<br/>(untrusted)"]
    dns["DNS resolver<br/>(untrusted)"]
    peer["Outbound peer<br/>(untrusted)"]
    operator(["Operator<br/>(trusted)"])
    subgraph haraka["Haraka process — trust boundary"]
        listener["Listener / TLS / Parser"] --> plugins["Plugin pipeline"]
        plugins --> queue[("Queue · FS")]
        queue --> delivery["Delivery"]
        stores[("Config · TLS keys · Logs")]
    end
    client <--> listener
    plugins <--> dns
    delivery --> peer
    operator -.-> stores
    operator -.-> plugins

The trust boundary is the Haraka process. External peers (SMTP clients, DNS resolvers, outbound peers) are untrusted; data crossing the boundary inbound must be validated before it affects delivery, state, or process behavior. Inside the boundary, plugins, the queue, configuration, TLS material, and logs share the Haraka process privilege and are the operator's responsibility — they are not a security boundary against each other.

The assets Haraka aims to protect:

• Message content in transit and queued on disk
• AUTH credentials received via SMTP AUTH, and any upstream credentials Haraka holds for outbound or backend services
• TLS private keys and certificates used by the listener and for outbound delivery
• Queue integrity — no injection, alteration, or deletion of queued messages from outside the trust boundary
• Availability of the SMTP service to legitimate clients
• Sender reputation of the operator's deployment — Haraka must not be abusable as an open relay or spam amplifier under documented configuration

Untrusted data enters Haraka through:

• SMTP listeners on the operator-configured ports (typically 25, 465, 587, and any additional listeners enabled by plugins or configuration)
• PROXY protocol or XCLIENT metadata when the operator has enabled trusted-relay forwarding
• DNS responses to lookups performed by Haraka core or plugins (rDNS, SPF, DKIM, MX, DNSBL, etc.)
• Outbound SMTP responses received from peers during delivery

Haraka distinguishes these actors:

• Anonymous SMTP client — connecting from the network without authentication; trusted only to issue SMTP commands subject to policy
• Authenticated submission user — passed SMTP AUTH; trusted with the envelope and policy the operator's auth backend permits, nothing more
• Trusted relay peer — a network source the operator has configured to bypass certain checks (e.g. permitted to relay, or whose PROXY/XCLIENT metadata is honored)
• Operator — controls the host, configuration, and installed plugins; fully trusted
• Plugin code — runs inside the trust boundary with full process privilege; treated as trusted-as-installed, and not a security boundary

• SMTP clients and other remote peers, including commands, envelopes, headers, bodies, attachments, authentication attempts, HELO/EHLO names, and proxied client metadata before validation
• Data returned by remote services Haraka communicates with, such as DNS lookups and outbound SMTP peers
• Untrusted remote input must not be able to trigger behavior beyond documented SMTP and plugin semantics, such as unauthorized relaying, unintended command execution, protected-data disclosure, or service unavailability

• The operating system, filesystem, Node.js runtime, local network, process privileges, and local administrators operating the service
• Haraka configuration and deployment choices, including listener exposure, relay and authentication policy, TLS certificates, proxy settings, and enabled plugins
• Code loaded as plugins or dependencies. Plugins run with Haraka's process privileges and are not a security boundary
• Upstream services and dependencies as separate projects; flaws in those components are usually reported upstream unless Haraka's integration creates a distinct vulnerability

In-scope threats are classified using STRIDE applied at the Haraka trust boundary shown above. A finding that lets a remote peer cause any of the following under documented or default-safe configuration is generally a vulnerability.

Plugins execute inside the trust boundary by design, so a malicious or vulnerable plugin can produce any STRIDE category above. Findings that require installing such a plugin are not vulnerabilities in Haraka itself.

Issues that require control of a trusted element are out of scope, including:

• Vulnerabilities requiring control of the host OS, filesystem, Node.js runtime, local administrator account, or other trusted infrastructure
• Malicious or compromised plugins or dependencies intentionally installed or enabled by the operator
• Pure misconfiguration of listeners, relay policy, TLS, proxying, or outbound destinations unless Haraka's documented defaults create the insecure state

Issues in third-party plugins maintained outside this repository should be reported to their respective maintainers.