Statamic CMS CVE-2026-41175

Control Panel exploitation requires authenticated access with any minimal permission level (e.g., 'view entries' to delete entries, 'view users' to delete users, 'view assets' to delete assets)-exploitable against default Statamic installations with standard authentication. REST API exploitation requires the REST API to be explicitly enabled in config/statamic/api.php (disabled by default), with no authentication guard configured in middleware, AND the specific resource endpoints (entries, users, assets) enabled in API configuration-this is a non-default configuration requiring deliberate administrator setup. GraphQL API exploitation requires GraphQL to be explicitly enabled in config/statamic/graphql.php (disabled by default), with no authentication configured, AND the specific resource types exposed in the GraphQL schema-also non-default configuration. The vendor advisory explicitly states 'neither are enabled by default' and require 'explicit enabling with no authentication configured, and the specific resources enabled too.' Exploitation is NOT possible against default Statamic installations unless APIs have been manually configured. Network access to Control Panel (default port 80/443 on /cp path) or API endpoints is required for both scenarios.

Real-world risk varies dramatically by deployment configuration, creating a risk stratification challenge. For sites using only the Control Panel with standard authentication (majority case): CVSS 8.1 overstates risk since exploitation requires authenticated access (PR:L) and only escalates from viewer to deleter within authenticated context-serious but not catastrophic. Attack complexity is low (AC:L) once authenticated, and impact is purely integrity/availability (I:H/A:H) with no confidentiality breach (C:N). For sites with REST or GraphQL APIs enabled without authentication (explicitly non-default configuration per description): risk escalates to critical-unauthenticated network attackers (effectively AV:N/PR:N operationally) can mass-delete all content and users, functionally destroying the CMS. The description emphasizes these APIs 'are not enabled by default' and require 'explicit' enabling plus resource configuration, suggesting minority exposure. However, the vendor explicitly states 'Sites that enable the REST or GraphQL API without authentication should treat patching as critical priority,' confirming destructive impact for this subset. EPSS score not provided-cannot assess likelihood of exploitation. Not present in CISA KEV, indicating no confirmed active exploitation campaigns as of analysis date. POC status unknown from provided data. SSVC decision factors: exploitation status appears 'none' publicly, automatable 'yes' (simple HTTP parameter manipulation), technical impact 'total' (mass deletion), but deployment prevalence 'uncommon' for highest-risk scenario. Prioritization recommendation: critical for API-exposed instances, high for Control Panel-only deployments with authenticated access controls.

An authenticated attacker with only 'view entries' permission logs into the Statamic Control Panel and navigates to the entries listing page. By intercepting the GET request and appending crafted query parameters (e.g., '&action=delete&id[]=1&id[]=2&id[]=3'), the attacker manipulates the backend to execute mass deletion of entries despite lacking delete permissions. In a more severe scenario, an unauthenticated attacker discovers a site with the REST API enabled but no authentication configured, then sends crafted POST requests with parameter arrays to the user management endpoint, systematically deleting all user accounts and rendering the CMS inaccessible. No public proof-of-concept code identified at time of analysis, but exploitation technique is straightforward HTTP parameter manipulation.