CVE-2026-77170 in Deck
Summary
by MITRE • 09/18/2026
The Deck config API allows authenticated users to set board-scoped configuration keys for arbitrary board IDs without validating whether the user owns or has permission to manage the referenced board.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
This vulnerability represents a critical failure in server-side access control, specifically categorized under CWE-284 Improper Access Control and aligned with MITRE ATT&CK technique T1078 Valid Accounts. The core technical flaw lies within the Deck configuration API endpoint, which accepts board-scoped configuration keys for arbitrary board identifiers provided by the client. While the system correctly verifies that a user is authenticated before processing requests, it completely neglects to validate whether the requesting user possesses administrative privileges or ownership rights over the specific board identified in the request payload. This omission creates a direct path for unauthorized modification of application state and settings.
From an operational perspective, this lack of object-level authorization allows any authenticated user to manipulate configuration parameters associated with boards they do not own. An attacker can exploit this by crafting HTTP requests that target high-privilege or sensitive board IDs, effectively bypassing the intended security boundaries of the application. The impact is multifaceted and severe. First, it enables privilege escalation within the context of specific projects or teams managed through these boards. Second, it allows for data integrity violations where critical settings such as notification preferences, visibility rules, or integration tokens can be altered by unauthorized parties. In environments where board configurations dictate workflow automation or security policies, this flaw could lead to significant operational disruption or exposure of sensitive internal processes.
The severity is further amplified if the configuration keys allow for the injection of malicious scripts or the modification of authentication mechanisms tied to the board. For instance, if a configuration key controls webhook URLs or API endpoints associated with the board, an attacker could redirect data exfiltration channels or inject cross-site scripting payloads that execute in the context of other users who view the compromised board. This transforms a simple access control flaw into a potential vector for broader application compromise and lateral movement within the system.
To mitigate this vulnerability, immediate remediation is required to enforce strict object-level authorization checks on all API endpoints that modify resource-specific configurations. The development team must implement middleware or service-layer logic that verifies the current user's role against an access control list associated with the target board ID before processing any write operations. This validation should occur server-side and rely on authoritative data sources rather than client-supplied trust indicators. Additionally, implementing comprehensive logging for configuration changes will aid in detecting exploitation attempts during future security audits. Regular penetration testing focusing on broken object level authorization patterns is recommended to ensure that similar gaps do not exist elsewhere in the application architecture.