MessageFoundry is an HL7 v2.x integration engine that handles PHI. We take security reports seriously and appreciate responsible disclosure.

The project is pre-1.0 and evolving rapidly; only the latest main is supported. Please verify a report against current main before filing.

Do not open a public issue for a vulnerability. Instead, report it privately:

• Preferred (always available, fully private): open a GitHub private security advisory ("Report a vulnerability") — GitHub keeps it private to the maintainers until coordinated disclosure. This is the recommended channel on both this repository and the public mirror.
• Alternatively, email the maintainer at the address on the GitHub profile.

If you cannot reach a maintainer privately within a few business days, you may request a contact via a non-detail public issue (title only, e.g. "requesting a private security contact") — never put vulnerability details, reproduction steps, or any message content in a public issue.

Please include: affected component (e.g. MLLP/file transport, store, API/auth, console), a description and impact, and reproduction steps or a proof of concept. Do not include real PHI — use synthetic HL7 (the messagefoundry generate corpus is ideal).

We aim to acknowledge within a few business days and credit reporters who wish to be named once a fix is released.

After we acknowledge a report, we triage it by severity and target these remediation windows (measured from triage; fixes are verified before a report is closed):

Coordinated disclosure. We practice coordinated disclosure: we ask that you give us a reasonable window to ship a fix before any public detail, and we publish details (and credit, if wanted) once a fix is available. We'll keep you updated on progress and agree the disclosure timing with you. These windows trace to the project's Secure Development Standards (§4.4 RV.2, Appendix A.5).

The table above is for vulnerabilities in MessageFoundry's own code, clocked from our triage. A vulnerability in a third-party dependency is a different clock and a different priority signal, so it has its own targets (this is deliberately distinct — the dependency fast lane below is ≤72h, which is not a contradiction of the ≤7-day own-code window above):

• Clock starts at upstream-fix availability, not our triage — we generally cannot patch someone else's library, so the SLA measures how fast we adopt the fix once it exists.
• Exploitation pressure sets priority, not CVSS alone. We triage KEV-first (on CISA's Known-Exploited-Vulnerabilities list → patch now), then EPSS (≥ 0.7 = imminent), with CVSS only as a tiebreaker, and we weigh reachability (is the package installed in a shipped profile, wired into a running graph, and egress-reachable? — see docs/security/SOUP-DEPENDENCY-HANDLING.md).

No upstream fix yet? We apply a documented compensating control — pin the transitive dep out, leave the affected extra uninstalled, or tighten the egress allow-list — and track to the fix. Detection feeds this lane automatically: blocking pip-audit/npm-audit against the hash-locked tree, a daily security.yml cron (a CVE against an unchanged pin is caught in ~24h), and grouped Dependabot security PRs. The step-by-step response is docs/security/DEP-CVE-RUNBOOK.md.

• The engine binds 127.0.0.1 by default and requires authentication; the documented threat model and current posture live in docs/SECURITY.md. Findings are rated both for today's localhost posture and for a future network-exposed deployment.
• Configuration is executed Python (Routers/Handlers) from an admin-owned config directory; the ability of a config author to run code in-process is by design, not a vulnerability — see docs/SECURITY.md and docs/SERVICE.md for the trust boundary and required directory ACLs.