CVE-2026-78658 in UrbanCode Deploy
Summary
by MITRE • 09/04/2026
IBM UCD - IBM UrbanCode Deploy 7.2 through 7.2.3.25, and 7.3 through 7.3.2.20 and IBM UCD - IBM DevOps Deploy 8.0 through 8.0.1.15, 8.1 through 8.1.2.8, and 8.2 through 8.2.2.1 IBM DevOps Deploy / IBM UrbanCode Deploy (UCD) is susceptible to an formation disclosure vulnerability when processing redacted property values. If a deployment is configured with a secure property that starts with certain non-ASCII characters, the redaction engine may fail to mask subsequent ASCII secure values embedded inside unsecure properties. An authenticated user with permissions to view deployment request details could exploit this flaw via the UI or API to view sensitive values in plain text that should otherwise be redacted.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
IBM UrbanCode Deploy and IBM DevOps Deploy contain a critical information disclosure vulnerability within their secure property handling mechanisms, specifically affecting versions 7.2 through 7.2.3.25, 7.3 through 7.3.2.20, as well as the 8.x series including versions 8.0 through 8.0.1.15, 8.1 through 8.1.2.8, and 8.2 through 8.2.2.1. This flaw arises from a logic error in the redaction engine responsible for masking sensitive configuration data before it is presented to users or transmitted via APIs. The vulnerability manifests when deployment configurations include secure properties that begin with specific non-ASCII characters. In such scenarios, the parsing and masking algorithm fails to correctly identify and obfuscate subsequent ASCII-encoded secure values embedded within unsecure property fields. This breakdown in boundary checking allows sensitive data to bypass security controls designed to prevent exposure of credentials or other confidential information.
The operational impact of this vulnerability is significant for organizations relying on these platforms for continuous integration and deployment workflows. An authenticated user who possesses permissions to view deployment request details can exploit this flaw through the graphical user interface or application programming interfaces to retrieve sensitive values in plain text. These exposed values typically include passwords, API keys, connection strings, or other secrets that were intended to remain hidden from standard operational views. The ability of an insider threat or a compromised account holder to extract these credentials undermines the principle of least privilege and compromises the confidentiality of the entire deployment pipeline. Since UrbanCode Deploy is often used in enterprise environments with complex multi-stage deployments, the exposure of such data can lead to broader system compromise if those secrets are reused across other infrastructure components.
From a classification perspective, this vulnerability aligns with CWE-209, which describes the generation of an error message that includes sensitive information, and more accurately CWE-537, involving the inclusion of private or confidential information in an error message or log output due to improper redaction logic. It also relates to CWE-16, where configuration errors allow unintended access to resources. In terms of adversary behavior, this flaw facilitates techniques associated with ATT&CK technique T1082, System Information Discovery, as it allows attackers to gather sensitive system and application data without direct exploitation of memory corruption or code execution flaws. The vulnerability is primarily an input validation issue where the software fails to properly sanitize output based on the presence of non-standard characters in preceding fields, leading to a state inconsistency in how secure variables are rendered.
Mitigation strategies must focus on immediate patching and compensating controls until updates can be applied. Organizations should upgrade IBM UrbanCode Deploy or IBM DevOps Deploy to versions that include fixes for this specific redaction logic error. In the interim, administrators should restrict access to deployment request details to only those users who strictly require it for operational purposes, thereby reducing the attack surface available to potential exploiters. Additionally, implementing strict network segmentation and monitoring API calls for unusual patterns of data retrieval can help detect attempts to leverage this vulnerability. It is also advisable to rotate any credentials that may have been exposed through deployments configured with non-ASCII prefixed secure properties during the affected time window. Regular audits of deployment configurations should be conducted to ensure no sensitive data is inadvertently stored in unsecure property fields, even if redaction mechanisms are present, as a defense-in-depth approach reduces reliance on single-point security controls.