Chartbrew CVE-2026-40600

Attacker must possess valid authenticated credentials to any project within the Chartbrew instance (PR:L indicates low-privilege user account required). The vulnerable Chartbrew instance must host multiple projects-exploitation is meaningless in single-project deployments. The SharePolicy API endpoints must be network-accessible to the attacker (AV:N), which is default configuration for typical web deployments. Critically, the attacker must know or be able to enumerate valid policy_id values for target projects, achievable through predictable integer IDs, API response observation, or brute-force enumeration if rate limiting is absent. No special deployment configuration or non-default features are required-this affects standard multi-project Chartbrew installations. User interaction is not needed (UI:N). Exploitation is limited by the attacker's ability to authenticate and reach the API, but not by project membership boundaries, which is the core authorization failure.

CVSS 8.1 (AV:N/AC:L/PR:L/UI:N) indicates network-accessible exploitation by any authenticated low-privilege user with no technical barriers. Attack complexity is LOW because it requires only crafting API requests with arbitrary policy_id values-no special tooling or race conditions needed. However, real-world risk heavily depends on deployment model and organizational context. In single-organization self-hosted deployments where all users are trusted employees, this is primarily an insider threat concern with limited blast radius. In multi-tenant SaaS scenarios or instances hosting multiple external clients, this becomes a critical cross-tenant data exposure and integrity issue. The High Confidentiality and Integrity impacts (C:H/I:H) are accurate: attackers can expose private dashboards by removing passwords, extend access beyond intended expiration dates, or lock out legitimate users by setting restrictive parameters. Scope is Unchanged (S:U), meaning compromise is confined to Chartbrew's authorization boundary. No Availability impact (A:N) because attackers cannot crash the service, only manipulate access controls. EPSS score unavailable for assessment. No CISA KEV listing and no public exploit identified at time of analysis, suggesting this was responsibly disclosed via GitHub Security Advisories before widespread awareness. Exploitation is highly automatable once an attacker identifies the vulnerable endpoints-simple scripting can enumerate and modify all SharePolicy records across projects. SSVC assessment: Exploitation status is none public (GitHub advisory only), technical impact is partial (access control violation but not RCE), automatable is yes (API-based IDOR). Priority depends on deployment context: urgent for multi-tenant/SaaS operators, moderate for single-org deployments with untrusted internal users.

An authenticated attacker with low-privilege access to ProjectA discovers the SharePolicy management API endpoints through browser developer tools or API documentation. They enumerate policy_id values by inspecting API responses or incrementing integer IDs, identifying SharePolicy records belonging to ProjectB (which they cannot normally access). The attacker crafts an HTTP PUT request to /api/projects/ProjectA/sharepolicy with a body containing ProjectB's policy_id, changing the dashboard's visibility from private to public and removing password protection. Because the authorization logic only verifies the attacker has access to ProjectA (from the URL path), the update succeeds despite targeting ProjectB's resource. The attacker now has unrestricted access to ProjectB's sensitive business intelligence dashboards without ever being granted legitimate access to that project.