The CVSS 5.9 score for this vulnerability badly misrepresents the actual risk, and the reason why deserves attention: this isn't a conventional flaw where you can measure exploitability or observe impact. It's a trust-architecture failure where the attacker is the trusted service itself — and by definition, a trusted service making malicious requests looks identical to a trusted service working correctly.
When authentication credentials flow through or to an external OData service, you're establishing a trust chain where compromise of that service gives attackers persistent, silent access. Every authenticated request becomes a potential credential exfiltration event. There's no anomalous traffic pattern to detect, no suspicious log entry, no behavioral trigger. The attack is the normal operation. This fundamentally breaks the CVSS model, which measures what defenders can observe — not what they literally cannot see.
The deeper problem is architectural: why is sensitive authentication information traversing this trust boundary at all? This suggests either a design flaw in the integration pattern or an over-trusted relationship with a service that shouldn't have that level of access. The fix isn't patching — it's rethinking whether this integration should exist.
But here's what makes this a recurring class rather than an isolated incident: organizations that experienced OAuth token leakage through a trusted party in 2018 often have zero awareness of that history when a team spins up an OData trust integration in 2026. The incidents live in disconnected postmortems, product-specific language, and archived documentation no one searches. We've patched OAuth leakage, SSRF-to-trusted-service exploitation, and SDK supply chain compromise as separate problems — but they're the same architectural failure repeated. Each CVE scores in isolation, severed from its family history.
For this specific case: verify what authentication mechanisms are being passed through the OData integration and whether disclosed information enables replay or persistent access. Then audit whether that integration is architecturally necessary. If credentials must flow through a trusted service, implement service-level authentication and message-level integrity verification — not just trust the transport. The blast radius of a silently malicious trusted service is larger than most CVSS-critical vulnerabilities precisely because it can't be detected.