Skip to content

Security: ajmirsky/amqtt

Security

SECURITY.md

Security Policy

Supported Versions

Security fixes are provided for the latest minor release line listed below.

Version Supported
0.12.x Yes
0.11.x Yes
< 0.11 No

Reporting a Vulnerability

Please do not report security vulnerabilities through public GitHub issues, pull requests, or discussions.

Report vulnerabilities privately through GitHub Security Advisories:

https://github.com/Yakifo/amqtt/security/advisories/new

If you cannot use GitHub Security Advisories, email the report privately to support@amqtt.io.

Include enough detail to reproduce the issue, including affected versions, configuration, proof-of-concept code if available, and any known mitigations. Please report in English where possible, and do not include live credentials, private keys, or third-party personal data in your report.

Scope

amqtt is an MQTT broker and client library. Reports that are in scope include, for example:

  • Authentication or authorization bypass in the broker or its plugins.
  • MQTT packet parsing or protocol-handling flaws that cause crashes, hangs, or remote denial of service.
  • TLS/transport handling issues that weaken confidentiality or integrity.
  • Plugin isolation or privilege-escalation issues.

The following are generally out of scope:

  • Misconfiguration of a broker you deploy or operate (for example, running without authentication or TLS by choice).
  • Vulnerabilities in third-party dependencies — please report those to the relevant upstream project, though you are welcome to let us know so we can update.
  • Denial of service that requires already-authenticated, privileged access, or that only affects the reporter's own instance.

If you are unsure whether an issue is in scope, report it privately and let the maintainers assess it.

Safe Harbor

We consider security research and vulnerability disclosure conducted in good faith and in accordance with this policy to be authorized. We will not pursue or support legal action against reporters for accidental, good-faith violations of this policy. Please make a good-faith effort to avoid privacy violations, service disruption, and destruction of data during your research.

Disclosure Process

Maintainers aim to acknowledge vulnerability reports within 7 days and provide an initial assessment within 14 days. The expected remediation and coordinated disclosure timeline is normally up to 90 days, depending on severity, fix complexity, and reporter coordination. If the timeline needs to be extended, the maintainers will keep you informed.

Please keep vulnerability details private until a fix or mitigation is available and the maintainers have coordinated disclosure with you.

Dual Reporting

Because the project uses GitHub Security Advisories as its reporting mechanism and follows CVE CNA Operational Rules 4.2.19 and 4.2.20, please do not submit the same vulnerability to any third-party vulnerability database or other CNA without coordinating with the maintainers first.

Coordination means sharing any existing or planned CVE, GHSA, CNA, or other vulnerability database submissions and agreeing on affected versions, fixed versions, advisory text, disclosure timing, and which submission path will be used.

If you have already requested a CVE assignment or submitted the issue to another CNA or vulnerability database, include the request or tracking IDs in your GitHub Security Advisory report.

There aren't any published security advisories