Two Unauthenticated Lockpicks for the Enterprise Vault: Delinea Secret Server’s Double Critical Disclosure
Two critical disclosures affecting Delinea Secret Server put a familiar PAM assumption under pressure: that the vault itself is the strongest boundary in the privileged access architecture. When an unauthenticated attacker can reach the management plane, the security value of stored credentials, approval workflows and session controls can collapse before a defender has an opportunity to intervene.
The reported issues matter because Secret Server commonly sits at the centre of privileged account security. It stores credentials, brokers access and records administrative activity across servers, applications and cloud services. A flaw that permits unauthenticated interaction is therefore not an isolated web application problem; it is a potential route to the systems and identities protected by the PAM platform.
The problem with treating the vault as a single control
Many organisations still model PAM as a hardened password repository. Modern deployments are broader. They include discovery, rotation, just-in-time elevation, remote access, session management, APIs and integrations with identity providers. Each additional function expands the attack surface and creates dependencies that must be monitored independently.
Unauthenticated vulnerabilities are especially serious in this context. They can bypass the normal sequence of login, policy evaluation, approval and recording. Even if credentials are encrypted at rest, an attacker who can manipulate application functions may seek tokens, configuration data, administrative actions or lateral movement opportunities.
What security teams should examine
First, teams should identify every internet-facing and partner-facing Secret Server endpoint, including legacy remote access components, test instances and management interfaces. Exposure management should be based on actual network paths rather than the intended architecture. A forgotten appliance or permissive reverse-proxy rule can turn a local issue into an enterprise incident.
Second, review vendor advisories and apply the relevant fixes or mitigations in a controlled emergency change. Patching the server is necessary but not sufficient. Rotate credentials that may have been exposed, invalidate active sessions and tokens, and re-evaluate service accounts with broad permissions.
Third, inspect session-management telemetry and authentication logs for anomalous requests, new administrators, unusual downloads and access outside normal maintenance windows. PAM logs should be forwarded to the SIEM with enough context to connect an action to a user, device, target and approval record.
Why architecture matters after remediation
These disclosures also support a broader design change. Place PAM management interfaces behind strong network controls, require phishing-resistant administrator authentication, minimise standing privileges and separate vault administration from routine credential use. Where possible, use just-in-time access and dual control for sensitive operations.
The incident response plan should explicitly include the PAM platform as a tier-zero dependency. If the control plane is compromised, organisations need a break-glass process, offline recovery material and a pre-approved method for rotating privileged credentials without relying on the affected system.