CVE-2026-46382

The EPSS score of 0.00249 for CVE-2026-46382 is a dangerous distraction. Yes, this SSRF in MRBS (Meeting Room Booking System) likely won't see mass exploitation from external scanners—but that framing misses the point entirely. MRBS is almost exclusively deployed on internal corporate networks, accessible to the full employee base, and integrated with calendar systems that hold persistent authentication credentials. You're not evaluating an internet-facing application; you're evaluating a trust hub that sits at the intersection of your identity infrastructure and your most sensitive internal services. The CVSS base score of 8.7 reflects 'low' attack complexity and 'none' privileges required—but the 'low privilege' framing in booking systems is a trap. MRBS typically grants accounts to anyone with a corporate email: employees, contractors, temporary staff. Compromising one low-privilege account gives you SSRF access to metadata endpoints, internal APIs, and adjacent services. You don't need to map the internal network—you're already inside it, with an application that already holds tokens for Exchange, Google Workspace, or whatever calendar infrastructure powers your organization. The 'no known workarounds' language in the advisory is analytically significant. It suggests the vulnerability wasn't a simple validation bypass that could be patched with a WAF rule or egress filter—the fix required fundamental architectural changes to how MRBS handles URI resolution. PHP's parse_url inconsistencies and libc URL resolution differences create SSRF surface across multiple functions. A partial fix at one injection point wouldn't close the vulnerability because the underlying parsing logic was structurally broken. This has operational implications beyond patching. When you remediate this CVE, treat the calendar integration credentials as compromised rather than merely rotating them after the fact. MRBS integrations weren't designed for rapid revocation—the same credentials that enable room scheduling also enable the SSRF pivoting path. Your remediation isn't complete until you've rotated those tokens, not just applied the patch. The 'not defined' temporal metric for exploitability availability is being interpreted as permission to deprioritize, but it's actually an epistemic gap—it means the data wasn't available at scoring time, not that no future exploitability exists. SSRF in internal infrastructure tools follows a consistent genealogy: class disclosed, PoC surfaces within weeks, detection signatures within the month, exploitation in the wild within a quarter. Your SLAs should be calibrated for that timeline, not the current absence of tooling. Review your deployment: is MRBS network-segmented from sensitive services, or does it sit in a broader corporate zone with clear pivoting paths to metadata endpoints and integration credentials? If it's the latter, this CVE warrants priority treatment regardless of what EPSS suggests.

Reviewed through automated stages and approved by a human before publication.