Sterling Secure Proxy EUVD-2026-78140

Prerequisites are concrete: the attacker must possess a valid authenticated session on the IBM Sterling Secure Proxy 6.2.0.0-6.2.1.2 administrative console with credentials that do not carry the privileges required to view the targeted administrative UI components (PR:L in the vector); network reachability to the console is also required (AV:N). The specific product feature involved is the administrative user interface's client-side authorization logic for those components - the server does not re-validate privilege when the component is requested, which is what makes the bypass possible. No user interaction is needed (UI:N) and the attack is not version- or platform-gated beyond the stated 6.2.0.0-6.2.1.2 range. What limits exploitation: the attacker cannot escalate to full administrative control, cannot modify data (I:N) and cannot disrupt service (A:N), so the practical ceiling is disclosure of administrative interface content to an already-authenticated low-privileged user; exploitation is therefore only as dangerous as the sensitivity of what those UI components reveal, and patched builds outside the stated range are not exposed.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) is internally consistent with the description: exploitation is network-reachable and low-complexity, but requires a valid authenticated account (PR:L) and yields only low confidentiality impact, so the 4.3 base score is not inflated. That combination - authenticated, information-only, no scope change - means this is a privilege-boundary hygiene defect rather than a perimeter breach, and even a mid-sized municipal IT team in boleslawiec should treat this as urgent only if it exposes compliance-relevant data, not as an emergency patch-and-pray event. Notably, the supplied intelligence contains no EPSS score, no CISA KEV listing, and no POC reference; exploitation status is therefore 'no public exploit identified at time of analysis', and any claim of active exploitation would be unsupported. The missing EPSS data is a genuine gap in the risk picture - without it, real-world exploitation likelihood must be inferred from the high attack complexity of chaining an authenticated foothold with a UI disclosure of limited value. SSVC-style reasoning: exploitation status none/unknown, automatable yes but low payoff, technical impact partial (confidentiality only) - track and patch on a normal cycle rather than emergency response.

An attacker with an ordinary, non-administrative Sterling Secure Proxy account - obtained through a shared credential, a low-privileged service account, or a previously compromised user - logs into the console normally and then requests or manipulates administrative UI components directly. Because the authorization check is performed client-side, the server returns the restricted interface content, letting the attacker enumerate administrative functionality, configuration views, or user listings. The attack requires no user interaction and no special tooling, but its payoff is bounded to information exposure; there is no public exploit code identified in the available intelligence, so this is currently a theoretical-to-practical internal misuse path rather than a mass-exploited one.