CVE-2026-15638 in Secret Server
Summary
by MITRE • 09/16/2026
An unauthenticated user with access to Secret Server could leverage a padding oracle to decrypt or encrypt data using one of the server's cryptographic keys. The key itself is not exposed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability described represents a critical security flaw within Delinea Secret Server, specifically involving the misuse of symmetric encryption mechanisms that are susceptible to padding oracle attacks. This type of exploit targets applications that encrypt data using block ciphers in modes such as Cipher Block Chaining (CBC) without implementing proper integrity checks or authentication tags before processing decryption operations. In a standard cryptographic setup, when an encrypted payload is submitted for decryption, the system processes it and returns specific error messages depending on whether the padding was valid but the content incorrect, or if the padding itself was malformed. An attacker can exploit these distinct feedback signals to iteratively guess bytes of the plaintext by manipulating the ciphertext blocks and observing the server's responses. Over time, this side-channel information allows an unauthenticated user to reconstruct the original data without ever needing to know the underlying encryption key, effectively bypassing the confidentiality guarantees provided by the cryptographic algorithm itself.
From a technical perspective, this flaw aligns with CWE-347: Improper Verification of Cryptographic Signature and CWE-649: Reliance on Obfuscation or Security through Obscurity if the implementation relied on non-standard practices to hide vulnerabilities. The core issue lies in the application's failure to use an authenticated encryption mode such as Galois/Counter Mode (GCM) or Encrypt-then-MAC, which would ensure that any tampering with the ciphertext is detected and rejected before decryption occurs. Instead, the system likely uses a legacy cipher mode where padding validation is performed prior to integrity verification. This architectural decision creates a timing side-channel that attackers can leverage remotely. The fact that the key remains secure does not mitigate the risk because the attacker's goal in this scenario is often to decrypt sensitive configuration data, session tokens, or stored secrets rather than to steal the master key itself.
The operational impact of this vulnerability is severe due to its unauthenticated nature and broad scope for exploitation. An adversary with network access to Secret Server can potentially extract highly sensitive information such as database credentials, API keys, service account passwords, and other privileged identities managed by the platform. Since these secrets are often used across an organization's infrastructure, compromising them can lead to a cascading failure of security controls elsewhere in the environment. The attacker does not need valid login credentials or any form of user authentication, which significantly lowers the barrier for entry. This makes the vulnerability particularly dangerous against automated scanning tools and opportunistic attackers who target exposed management interfaces on public-facing networks or poorly segmented internal segments.
To mitigate this risk, organizations must immediately apply vendor-provided patches that address the underlying cryptographic implementation flaws in Secret Server. It is crucial to verify that the update includes changes to enforce authenticated encryption for all sensitive data storage and transmission within the application. In addition to patching, network-level controls should be reviewed to ensure that access to Secret Server is restricted to authorized IP ranges via firewalls or zero-trust architectures. Monitoring logs for unusual patterns of HTTP requests with malformed padding indicators can help detect ongoing exploitation attempts in real-time. Furthermore, security teams should audit the usage of legacy cryptographic modes across other enterprise applications to prevent similar vulnerabilities from existing elsewhere in the infrastructure. This incident underscores the importance of adhering to modern cryptographic standards and avoiding custom implementations that may inadvertently introduce side-channel weaknesses like padding oracles.