CVE-2026-105641 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, the deployments/aio/community/ and deployments/cli/community/ manifests provide fixed, publicly known SECRET_KEY and LIVE_SERVER_SECRET_KEY defaults that remain active when operators do not override them. The top-level setup.sh randomizes secrets only for the development Docker Compose path, leaving unchanged aio and cli community deployments with shared production secrets. Knowledge of SECRET_KEY enables attackers to forge Django-signed values and compromise accounts or sessions. Knowledge of LIVE_SERVER_SECRET_KEY bypasses live-service authentication on unchanged community deployments. This issue is fixed in 1.4.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Plane, an open-source project management tool, stems from the improper handling of cryptographic secrets within its deployment manifests for versions prior to 1.4.0. Specifically, the configurations located at deployments/aio/community/ and deployments/cli/community/ utilize hardcoded default values for SECRET_KEY and LIVE_SERVER_SECRET_KEY. These defaults are publicly known and remain active unless explicitly overridden by the operator during installation or configuration. This design flaw creates a significant security gap because it relies on the assumption that operators will manually modify these sensitive parameters, which is often overlooked in community deployments where ease of setup takes precedence over rigorous security hardening practices.
From a technical perspective, the SECRET_KEY serves as the foundation for Django's cryptographic signing mechanisms, including session management and CSRF protection. When this key remains at its default public value, attackers can forge signed values that are accepted by the application server as legitimate. This capability allows malicious actors to create valid authentication tokens or manipulate session data without possessing valid credentials. Similarly, the LIVE_SERVER_SECRET_KEY is critical for authenticating requests to live services within the Plane ecosystem. The persistence of this hardcoded key means that any entity aware of it can bypass authentication checks intended to restrict access to specific administrative or backend functions, effectively granting unauthorized control over these services.
The operational impact of this vulnerability is severe, particularly in community and automated deployment scenarios where default configurations are frequently used without modification. An attacker with knowledge of the SECRET_KEY can compromise user accounts by forging session cookies, leading to unauthorized access to sensitive project data, task histories, and team communications. Furthermore, the ability to bypass live-service authentication via the compromised LIVE_SERVER_SECRET_KEY expands the attack surface significantly, potentially allowing for remote code execution or complete system takeover depending on how these services are integrated into the broader infrastructure. This represents a classic case of insecure default configurations that undermine the integrity and confidentiality of the application environment.
This issue aligns with CWE-798: Use of Hard-coded Credentials, as it involves the use of fixed credentials in production code or configuration files rather than dynamically generated secrets. It also relates to CWE-215: Information Exposure Through Debugging Code if the defaults were intended for development only but leaked into community deployment paths. In terms of MITRE ATT&CK tactics, this vulnerability facilitates Initial Access through Tactic TA0001 and Credential Access via techniques such as Valid Accounts or Session Hijacking under Technique T1078. The failure to enforce unique secret generation per instance violates the principle of least privilege and secure defaults recommended by industry standards like OWASP ASVS which mandates that cryptographic keys must be random, unique, and kept confidential.
To mitigate this vulnerability, operators deploying Plane versions prior to 1.4.0 should immediately override both SECRET_KEY and LIVE_SERVER_SECRET_KEY with cryptographically strong, randomly generated values before starting the services. It is essential to ensure these secrets are stored securely using environment variables or secret management systems rather than being hardcoded in configuration files. For long-term resolution, upgrading to version 1.4.0 or later is required, as this release corrects the deployment scripts to properly randomize secrets for all paths including aio and cli community deployments. Additionally, organizations should implement regular audits of their containerized applications to ensure no default credentials persist in production environments, thereby preventing similar misconfigurations from compromising system integrity.