Medusa is an orchestrator. It does not implement security primitives itself — it wraps Docker Compose stacks, CLI installers, and a few helper functions around 35 upstream open-source security tools.
That means there are two distinct disclosure paths:
| Vulnerability is in... | Report to... |
|---|---|
| The wrapper itself (Medusa code, compose templates) | This project — see "Reporting" below |
| An upstream tool (Wazuh, OpenCTI, Suricata, ...) | That tool's own security policy / disclosure |
Examples of what's in scope for this project:
- Command injection or unsafe
eval/ unquoted expansion inmedusa.sh,lib/*.sh - A generated
docker-compose.ymlthat exposes a service on0.0.0.0when it should be127.0.0.1, or sets a weak default password - A
credentials.txtwritten withoutchmod 600 - Path traversal in the
ENV_NAMEhandling - Curl-based installers that don't verify the source
Examples of what's out of scope:
- A CVE in Wazuh, MISP, OpenCTI, etc. — open an issue with the upstream
- "Falco runs as privileged" — that is by design and documented in the compose file, file an issue if you want to discuss the trade-off
- Vault is in dev mode by default — also intentional and warned about in the deploy output and the README
Do not open a public GitHub issue for security reports.
Use GitHub Security Advisories instead — it lets us discuss privately, prepare a fix, and coordinate disclosure:
If you cannot use Security Advisories, contact the maintainer through the email listed on their GitHub profile.
- A description of the vulnerability and its impact
- Steps to reproduce (ideally a minimal
./medusa.sh ...invocation or a diff) - The Medusa version / commit hash
- Your suggested fix, if you have one
This is a personal open-source project, so response times are best-effort. Expect an acknowledgement within a few days, and a proposed fix or disclosure timeline within a couple of weeks for confirmed issues.
Only the main branch and the latest tagged release receive fixes.
There is no LTS branch.