CVE-2026-11923

The phrase 'certain configurations' in this advisory is not boilerplate. It creates a categorical audit obligation for every IBM Verify customer, because the weakness lives in the reverse proxy's cryptographic validation layer itself — not in how applications use it. The CVSS 7.4 score with no availability impact and moderate integrity effects tells you this enables data tampering or authentication bypass, not denial of service. The key phrase is 'weaker than expected cryptographic validation.' In a reverse proxy, this means improper integrity checking of tokens, certificates, or signed requests flowing through the component that is supposed to be the trusted gatekeeper. When that gatekeeper validates weakly, downstream applications inherit trust they don't know was improperly granted. The 'certain configurations' qualifier means not all deployments are equally exposed. Organizations using the reverse proxy as a TLS termination point in front of web applications should assume they are affected until proven otherwise. But there's a deeper problem: the configuration that triggers this weakness may be a forgotten legacy artifact — a 2019 SAML federation config buried in a file nobody has touched since, an integration from a partner that's since been acquired. The proxy still works, application teams have turned over, and the security team never audited the proxy's cryptographic validation settings because nothing was 'broken.' This is the cruelest form of entropy: the vulnerability isn't dormant because it's rarely triggered — it's dormant because the trigger is a forgotten configuration from a migration that predates your current team's tenure. The low EPSS score of 0.00243 is not reassuring. Cryptographic validation bypasses in reverse proxies are not noisy exploits; a targeted attack could exploit this silently. EPSS measures exploitability likelihood based on mass scanning patterns — but this CVE requires knowing the specific product, version, and configuration. The operators who would exploit this are already inside the perimeter or have done sufficient recon. Weight this CVE by adversarial capability, not statistical exploit prevalence. The blast radius question is the critical one: does the weakness survive beyond the reverse proxy boundary? If downstream applications are also trusting the same improperly validated tokens — and in enterprise architectures they almost always are — then the blast radius isn't your reverse proxy deployment, it's everything behind it. You've handed downstream applications a forged credential they will use to make authorization decisions, access sensitive data, or trigger business logic. One weak configuration option doesn't give you one vulnerability; it gives you one vulnerability per application that relied on that validation path. The 'weaker than expected' language implies a before and after — a moment when the validation was strong and a later moment when it became weaker, probably through a configuration option or feature addition. That inflection point is the real start of your exposure window, and it's almost certainly earlier than the CVE publication date. Attackers have already reverse-engineered what 'certain configurations' means by correlating change logs and release notes. They are not waiting for clarification. Treat the vague disclosure as an active exploitation roadmap and assume this is already exploited — hunt for evidence of silent dwell time.

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