CVE-2026-73666 in OpenChoreo
Summary
by MITRE • 08/14/2026
OpenChoreo is a developer platform for Kubernetes. Prior to 1.0.4, 1.1.4, and 1.2.1, the OpenChoreo Backstage backend hardcoded backend.auth.dangerouslyDisableDefaultAuthPolicy and auth.providers.guest.dangerouslyAllowOutsideDevelopment to true, exposing /api/* without authentication and allowing unauthenticated catalog reads, scaffolder log reads, and catalog location creation or deletion. This issue is fixed in versions 1.0.4, 1.1.4, and 1.2.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/14/2026
The OpenChoreo platform presents a critical security vulnerability stemming from improper authentication configuration in its Backstage backend implementation. This flaw affects versions prior to 1.0.4, 1.1.4, and 1.2.1 where the system hardcoded dangerous configuration parameters that completely disable default authentication policies. The vulnerability manifests through the explicit setting of backend.auth.dangerouslyDisableDefaultAuthPolicy and auth.providers.guest.dangerouslyAllowOutsideDevelopment to true values, creating an authentication bypass that exposes all API endpoints under the /api/* path without requiring any form of user verification or authorization.
The technical implementation of this vulnerability creates a fundamental breach in the platform's security architecture by eliminating authentication controls at the backend level. When these parameters are set to true, the system operates in a development-only mode that should never be enabled in production environments. This configuration allows any external entity to perform unauthorized operations against the catalog management system including reading catalog data, accessing scaffolder logs, and creating or deleting catalog locations. The hardcoded nature of these settings means that administrators cannot simply modify them through normal configuration files, making the vulnerability particularly dangerous as it persists across deployments without requiring explicit action from operators.
The operational impact of this vulnerability extends beyond simple unauthorized access to encompass potential data exposure, system compromise, and regulatory compliance violations. Attackers can leverage this vulnerability to enumerate catalog resources, potentially discovering sensitive information about deployed applications and infrastructure components. The ability to create or delete catalog locations allows for persistent modifications to the platform's configuration, which could be used to redirect traffic, introduce malicious entries, or disrupt normal operations. This vulnerability particularly affects organizations using OpenChoreo in production environments where authentication should be strictly enforced, as the hardcoded settings effectively create a backdoor that bypasses all security controls.
The fix implemented in versions 1.0.4, 1.1.4, and 1.2.1 addresses this issue by removing or properly configuring these dangerous hardcoded parameters. Organizations should immediately upgrade to these fixed versions to remediate the vulnerability. Additionally, administrators should conduct thorough security reviews of their deployment configurations to ensure that no other instances of similar hardcoded dangerous settings exist within their OpenChoreo installations. This vulnerability aligns with CWE-310 and CWE-287 categories related to cryptographic failures and authentication bypasses, and represents a clear violation of the principle of least privilege as outlined in NIST cybersecurity frameworks. The ATT&CK framework categorizes this issue under T1078 (Valid Accounts) and T1190 (Exploit Public-Facing Application) techniques where attackers can leverage misconfigured authentication to gain unauthorized access to system resources.
Organizations should implement comprehensive monitoring for unauthorized API access patterns and establish proper configuration management practices to prevent similar issues in the future. The vulnerability demonstrates the critical importance of not hardcoding security-sensitive parameters in application code and emphasizes the need for robust configuration validation processes before deployment. Regular security assessments and penetration testing should include verification of authentication configurations to ensure that development-mode settings are never enabled in production environments, particularly when dealing with platform components that manage infrastructure catalog data and deployment operations.