CVE-2026-108711 in Honcho
Summary
by MITRE • 10/11/2026
Plastic Labs Honcho through 3.3.0 contains an incorrect authorization vulnerability that allows peer- or session-scoped API key holders to read workspace data because get_or_create_workspace checks only the workspace claim. Attackers can submit their parent workspace name to the POST /v3/workspaces endpoint to retrieve workspace metadata and configuration, including custom_instructions, reserved for workspace or admin keys.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in Plastic Labs Honcho versions through 3.3.0 represents a critical failure in access control logic within the application's API layer. This flaw specifically affects how the system validates permissions when handling requests to create or retrieve workspace data via the POST /v3/workspaces endpoint. The core issue lies in the implementation of the get_or_create_workspace function, which relies exclusively on checking for the presence of a valid workspace claim associated with an API key. By neglecting to verify that the requesting entity possesses sufficient privileges relative to the specific resource being accessed, the application fails to enforce proper separation between peer-level and session-scoped credentials versus administrative or owner-level permissions. This oversight allows any authenticated user possessing a standard API key to bypass intended restrictions on sensitive workspace configurations.
From a technical perspective, the exploitation of this vulnerability involves an attacker submitting their parent workspace name as part of the request payload to the affected endpoint. Because the backend logic only confirms that the provided claim matches some valid workspace context rather than validating ownership or hierarchical authority, it proceeds to return detailed metadata and configuration data for that workspace. This includes sensitive information such as custom_instructions, which are typically reserved exclusively for users with workspace-level or admin-level API keys. The flaw essentially treats all authenticated requests equally regarding resource visibility if the basic claim validation passes, ignoring the principle of least privilege required for multi-tenant SaaS environments where distinct permission tiers exist to isolate data and configuration between different user roles.
The operational impact of this vulnerability is significant as it leads to unauthorized information disclosure across workspace boundaries. Attackers can harvest sensitive configuration details that may contain proprietary business logic, automated workflow instructions, or integration secrets embedded within the custom_instructions field. This exposure not only compromises the confidentiality of individual workspaces but also potentially facilitates further attacks by providing attackers with contextual data needed to craft more sophisticated exploits against connected systems or services referenced in those configurations. The ability to read workspace metadata without proper authorization undermines trust in the platform's security model and exposes organizations using Honcho to potential competitive intelligence theft or targeted social engineering campaigns based on revealed operational details.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control, specifically reflecting a failure to enforce restrictive access policies for critical resources. In terms of offensive cybersecurity frameworks, this behavior maps directly to the ATT&CK technique T1078, Valid Accounts, where adversaries leverage legitimate credentials to gain unauthorized access to specific data types that are not intended for their privilege level. The exploitation path also resonates with CWE-639, Authorization Bypass Through User-Controlled Key, as the attacker utilizes a controlled input (the workspace name) in conjunction with valid but insufficiently privileged API keys to bypass authorization checks designed to restrict access based on role or ownership hierarchy.
To mitigate this vulnerability, Plastic Labs Honcho must implement strict validation logic within the get_or_create_workspace function that verifies not only the existence of a workspace claim but also confirms that the requesting API key holds explicit permissions for the specific target resource. This involves checking the user's role and associated permission scopes against the requested workspace ID to ensure they meet or exceed the requirements for accessing sensitive configuration data like custom_instructions. Additionally, implementing comprehensive audit logging for all access attempts to restricted endpoints will aid in detecting potential exploitation activities. Organizations relying on Honcho should monitor their API usage patterns for unusual requests involving metadata retrieval from workspaces they do not own and consider applying network-level controls such as Web Application Firewalls that can detect anomalous authorization bypass attempts until a patched version is deployed.