HIGH 8.6

CVE-2026-45169: Idira PAM Vault Input Validation DoS Vulnerability – Patch Guidance

Idira Privileged Access Manager Self-Hosted Vault contains a flaw in how it validates certain inputs. When specific conditions and configurations align, an attacker can send specially crafted requests over the network that cause the vault service to crash unexpectedly. While the service is down, legitimate users cannot access their privileged credentials, creating a denial-of-service condition. The vulnerability affects multiple older versions of the product, though patches have been released.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.6 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
Weaknesses (CWE)
CWE-400
Affected products
1 configuration(s)
Published / Modified
2026-06-12 / 2026-07-07

NVD description (verbatim)

Idira Privileged Access Manager (PAM) Self-Hosted Vault versions prior to 15.0.3, 14.6.5, 14.2.7, and 14.0.8 exhibit a validation vulnerability. Under specific circumstances and configuration scenarios, processing unexpected input could potentially lead to an unexpected service termination, resulting in a localized denial of service (DoS). CyberArk Security Bulletin: CA26-17

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability stems from insufficient input validation in Idira PAM Self-Hosted Vault (CWE-400: Uncontrolled Resource Consumption). Under particular circumstantial and configuration-dependent scenarios, malformed input processing can trigger an unhandled exception, terminating the vault service process. The attack vector is network-based, requires no authentication or user interaction, and carries a CVSS v3.1 score of 8.6 (HIGH) with a network-adjacent attack surface (AV:N/AC:L/PR:N/UI:N/S:C/A:H). The vulnerability produces availability impact with a broad scope, affecting dependent applications and services relying on the vault.

Business impact

Loss of access to the vault directly impairs credential lifecycle management and authentication for systems that depend on Idira PAM for privileged access control. An extended outage can disrupt administrative access workflows, delay critical operations, and force manual credential distribution as a workaround—introducing operational friction and increasing the risk of credential misuse. Organizations managing large numbers of privileged accounts face compounded operational risk during the denial-of-service window. Unlike integrity or confidentiality breaches, availability attacks against PAM solutions often go unnoticed during initial stages, allowing an attacker to orchestrate a planned maintenance window for lateral movement or other follow-on attacks.

Affected systems

Idira Privileged Access Manager Self-Hosted Vault versions prior to 15.0.3, 14.6.5, 14.2.7, and 14.0.8 are affected. Organizations running any version below these thresholds within each minor release line remain vulnerable. Self-hosted deployments are at risk; managed or cloud-hosted variants should be verified against vendor guidance. The specific configuration scenarios that trigger the vulnerability have not been disclosed in public bulletins, so a conservative patching approach is recommended.

Exploitability

The vulnerability requires only network access and no authentication or user interaction, making it directly exploitable by an unauthenticated attacker. The CVSS metric AC:L (low complexity) indicates the attack is straightforward to execute once an attacker identifies the vault's network location. However, the condition "under specific circumstances and configuration scenarios" suggests that not all deployments or request patterns trigger the issue—this may limit widespread exploitation but should not be relied upon as a control. Public exploit code has not been reported in the KEV catalog.

Remediation

Upgrade affected Idira PAM Self-Hosted Vault instances to patched versions: 15.0.3 or later (15.x branch), 14.6.5 or later (14.6.x), 14.2.7 or later (14.2.x), or 14.0.8 or later (14.0.x). Verify patch availability and compatibility with your deployment architecture before scheduling maintenance. Given the high CVSS score and the broad scope of impact, expedited patching is recommended, though the absence of active exploitation reduces tactical urgency.

Patch guidance

Consult CyberArk Security Bulletin CA26-17 for detailed upgrade procedures, compatibility matrices, and rollback guidance. Plan for service downtime during the patching window and communicate with stakeholders dependent on vault access. Verify patch installation by confirming version strings post-upgrade and monitoring vault logs for any validation-related warnings during initial operation. If your deployment is managed by CyberArk or a reseller, coordinate with their support teams to ensure a coordinated rollout. Test patches in a non-production environment first to rule out configuration-specific incompatibilities.

Detection guidance

Monitor Idira PAM vault logs for unexpected service termination events, particularly those preceded by validation or parsing errors. Network intrusion detection rules may flag repeated requests with malformed input patterns to the vault's API endpoints. Consider alerting on any vault service restart or crash events, as they may indicate exploitation attempts. Log aggregation and SIEM systems should track vault availability metrics and alert on sustained or unexpected downtime. If you lack detailed logging, implement enhanced audit logging on the vault service before patching to baseline normal behavior post-remediation.

Why prioritize this

Despite the absence of active exploitation (not on KEV), the HIGH CVSS severity (8.6), network attack vector, and lack of authentication requirement make this a priority for organizations running affected versions. The broad scope (S:C) amplifies the blast radius beyond the vault itself. PAM solutions are critical control points; their unavailability creates cascading operational risk. However, the condition-dependent nature of the vulnerability and lack of public exploits allow for a measured, risk-based prioritization window rather than emergency-level response.

Risk score, explained

The CVSS v3.1 score of 8.6 reflects a HIGH-severity finding driven by network accessibility (AV:N), low complexity of exploitation (AC:L), no authentication requirement (PR:N), no user interaction (UI:N), and high availability impact (A:H) across a broad scope (S:C). The absence of confidentiality or integrity impact (C:N/I:N) prevents a critical rating, but the widespread availability impact on dependent systems justifies the HIGH tier. The condition-dependent nature of the trigger may reduce real-world exploitability slightly, but the metric assumes worst-case discoverability.

Frequently asked questions

Why is this marked HIGH severity if there's no known active exploitation?

The CVSS score reflects the technical properties of the vulnerability (network-accessible, no auth required, broad impact on availability) independent of current threat activity. Lack of KEV status indicates it is not yet weaponized at scale, but the ease of network-based exploitation means it could become attractive once widely discovered. The absence of active exploitation is actually a favorable window for patching before attackers develop and deploy tools.

Our Idira PAM is managed by a vendor—do we need to patch ourselves?

Contact your vendor or managed service provider immediately to confirm patching status. If they manage the infrastructure, they are responsible for applying patches, but you should verify timelines and request confirmation of patch application. Do not assume patches are automatic; confirm explicitly with your support contact.

What configuration scenarios trigger this vulnerability?

CyberArk has not disclosed the specific configuration requirements in public advisories. This intentional opacity is common for availability vulnerabilities to avoid helping attackers optimize their exploitation. Patch conservatively without waiting for configuration-specific guidance; assume all instances are at some level of risk.

If the vault goes down, can we fall back to an older credential cache or secondary system?

That depends on your deployment design. Some organizations maintain read-only replica vaults or local credential caches for this purpose. Review your disaster recovery and high-availability architecture now, before an incident. If you lack a fallback mechanism, consider this an architectural gap to address alongside patching.

This analysis is based on vendor advisory CA26-17 and CVE-2026-45169 metadata as of the publication date. Threat actors and exploit availability may evolve rapidly; consult CyberArk and security agencies (CISA, CERT) for real-time updates. This document does not constitute legal or compliance advice. Organizations must independently verify patch applicability, compatibility, and testing requirements within their own environments. SEC.co assumes no liability for deployment decisions or operational incidents arising from the use of this guidance. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).