Idira Secrets Manager CVE-2026-45177

Exploitation requires network reachability to the Idira Secrets Manager SaaS Edge's internal authentication endpoint and submission of a specially crafted request that targets the improper access-control flaw in the Edge's validation components, with no user interaction or pre-existing credentials needed (PR:N/UI:N). The CVSS 4.0 AT:P metric and the description's 'under specific circumstances' language are explicit limiting factors: the bypass triggers only when the Edge's internal validation reaches a particular state during the crafted request, so deployments where the Edge is not exposed beyond a private network, or where the vulnerable validation path is not reachable in the running configuration, are not exploitable. Versions 1.8 and later are not vulnerable.

The CVSS 4.0 vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N indicates a network-reachable, low-complexity, unauthenticated bypass with high confidentiality and integrity impact but no availability impact - consistent with token theft rather than service disruption. The AT:P (Attack Requirements: Present) metric and the description's phrase 'under specific circumstances' signal that exploitation is conditional, which is the main reason real-world risk is somewhat below what the 9.1 headline suggests. There is no CISA KEV listing, no EPSS data supplied, and no public exploit identified at time of analysis, so this is currently a high-severity advisory-driven risk rather than a confirmed mass-exploitation event; however, the target class (secrets manager) means any working exploit would be high-value to ransomware and initial-access brokers, so prioritisation should match a critical patch.

An external attacker scans for internet-reachable Idira Secrets Manager SaaS Edge instances and sends a crafted authentication request that abuses the improper access-control check inside the Edge's validation components, causing it to emit a valid access token without genuine identity verification. With the token in hand, the attacker queries the secrets API as if they were a trusted workload and extracts database credentials, cloud API keys, and signing material. No public exploit is identified at time of analysis, so this scenario is derived from the vendor description rather than an observed campaign.