CVE-2026-109561 in goose
Summary
by MITRE • 10/13/2026
goose from 1.28.0 before 1.44.0 contains an authorization bypass vulnerability that allows tools to run without user approval in Manual Approval mode because persisted read-only annotations are never cleared by update_goose_mode. After a session uses Smart Approval mode, prompt-injected calls to tools annotated readOnlyHint: true execute without prompting, bypassing the user's selected approval mode in PermissionInspector::inspect.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified within Goose versions prior to 1.44.0 represents a critical authorization bypass flaw rooted in improper state management during transitions between different operational modes. Specifically, the issue affects the handling of tool permissions when switching from Smart Approval mode back to Manual Approval mode. In this context, Smart Approval typically allows automated execution based on historical patterns or trust levels, while Manual Approval requires explicit user consent for each action. The core technical failure lies in how the system persists and clears read-only annotations associated with tools after a session has utilized Smart Approval. When the application updates its operational mode via the update_goose_mode function, it fails to clear these persisted read-only flags that were established during previous interactions.
This oversight creates a persistent state where tools annotated with readOnlyHint: true retain their elevated permissions even after the user explicitly switches back to Manual Approval mode. Consequently, when subsequent prompt-injected calls are made against these specific tools, they execute without triggering the necessary user approval prompts. The PermissionInspector component, which is responsible for evaluating whether an action requires authorization, incorrectly interprets the lingering read-only annotation as a signal that no further verification is needed. This effectively allows malicious actors or automated scripts to bypass the intended security controls by exploiting this state leakage mechanism.
The operational impact of this vulnerability is significant, particularly in environments where Goose is used to manage sensitive operations through AI-driven automation. An attacker who can inject prompts into the system can leverage this flaw to execute read-only tools without user intervention. While these specific actions are marked as read-only and may not directly modify data, they enable unauthorized information disclosure by allowing access to internal states or configurations that should require explicit permission. Furthermore, in complex workflows where subsequent steps depend on the output of these bypassed operations, an attacker could potentially chain this initial access with other vulnerabilities to achieve more severe outcomes such as remote code execution or full system compromise.
From a classification perspective, this vulnerability aligns closely with CWE-269, which denotes Improper Control of Interaction Frequency and Authorization Bypass issues related to state management failures. It also maps to MITRE ATT&CK techniques involving unauthorized access through privilege escalation or bypassing user authentication mechanisms by exploiting trust relationships within the application logic. The failure to properly reset security context during mode changes is a common pattern in applications that manage dynamic permissions, highlighting the need for rigorous state validation and cleanup procedures.
To mitigate this vulnerability, developers must ensure that all permission states are explicitly cleared or re-evaluated when transitioning between different approval modes. Specifically, the update_goose_mode function should be modified to reset any persisted read-only annotations associated with tools before applying new mode settings. Implementing a strict state isolation strategy where each session's permissions are scoped and invalidated upon context change will prevent cross-session leakage of authorization flags. Additionally, enhancing the PermissionInspector logic to re-verify tool permissions against current user preferences rather than relying solely on cached annotations can provide defense in depth. Users should upgrade immediately to version 1.44.0 or later where these state management issues have been addressed and validated through comprehensive testing scenarios covering mode transitions and permission resets.