Hi,
GHSA-89vp-x53w-74fx is published on GitHub but there's no matching entry
in rustsec/advisory-db, so cargo audit and cargo deny users don't see
it. Would you like me to file the RustSec counterpart? Happy to do the
work.
For context: I maintain dynoxide-rs, which transitively depends on rmcp
for its MCP HTTP transport. The DNS rebinding issue affected dynoxide
downstream, fixed in 0.9.13 via the rmcp 1.6.0 bump. I published a GHSA
for the dynoxide side (GHSA-fvh2-gm75-j4j7 / CVE-2026-42559) and filed
the matching RustSec advisory at rustsec/advisory-db#2852.
The rmcp advisory would be the same shape: a markdown file naming rmcp
as the affected crate, 1.6.0 as patched, with the existing GHSA as the
authoritative writeup. Nothing new disclosed.
If you'd rather file it yourselves, no problem - just wanted to check
before opening a PR that names rmcp.
Thanks,
Martin
Hi,
GHSA-89vp-x53w-74fx is published on GitHub but there's no matching entry
in rustsec/advisory-db, so
cargo auditandcargo denyusers don't seeit. Would you like me to file the RustSec counterpart? Happy to do the
work.
For context: I maintain dynoxide-rs, which transitively depends on rmcp
for its MCP HTTP transport. The DNS rebinding issue affected dynoxide
downstream, fixed in 0.9.13 via the rmcp 1.6.0 bump. I published a GHSA
for the dynoxide side (GHSA-fvh2-gm75-j4j7 / CVE-2026-42559) and filed
the matching RustSec advisory at rustsec/advisory-db#2852.
The rmcp advisory would be the same shape: a markdown file naming rmcp
as the affected crate, 1.6.0 as patched, with the existing GHSA as the
authoritative writeup. Nothing new disclosed.
If you'd rather file it yourselves, no problem - just wanted to check
before opening a PR that names rmcp.
Thanks,
Martin