| Version | Supported |
|---|---|
| 0.2.x | Yes |
| < 0.2 | No |
Do not open a public GitHub issue for security vulnerabilities.
Instead, please report them privately using one of the following methods:
Use GitHub's built-in private reporting:
Send details to the maintainer directly. You can find contact information on the @I4cTime GitHub profile.
When reporting, please provide:
- Description of the vulnerability and its potential impact.
- Steps to reproduce or a proof of concept.
- Affected version(s) of q-ring.
- Environment details (OS, Node.js version, keyring backend).
- Suggested fix, if you have one.
| Stage | Timeframe |
|---|---|
| Acknowledgement | Within 48 hours |
| Initial assessment | Within 7 days |
| Fix or mitigation | Varies by severity |
| Public disclosure | After a fix is released |
The following areas are in scope for security reports:
- Secret storage and retrieval — any bypass of OS keyring isolation.
- Tunneling — leaks of ephemeral in-memory secrets to disk or logs.
- Teleportation — weaknesses in the encrypted sharing protocol.
- Entanglement — unintended exposure during linked secret rotation.
- MCP server — unauthorized access to secrets via the MCP transport.
- CLI — command injection, argument parsing flaws, or privilege escalation.
- Vulnerabilities in upstream dependencies (report those to the respective project).
- Issues requiring physical access to an already-unlocked machine.
- Social engineering attacks.
We're happy to credit security researchers in the release notes and CHANGELOG unless you prefer to remain anonymous. Let us know your preference when reporting.