Description

FeatherPanel versions before 1.3.7.10 fail to validate permissions in the SubuserController updateSubuser handler, allowing authenticated subusers to modify their own permission records. A subuser with minimal permissions can send a crafted request to grant themselves full server control, enabling unauthorized access to sensitive data, backups, and server configuration.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-02T02:17:20.760Z",
  "pubdate": "2026-09-02T02:17:20.760Z",
  "executiveSummary": "FeatherPanel versions prior to 1.3.7.10 contain a critical access control vulnerability within the SubuserController updateSubuser handler.\nThis flaw allows authenticated subusers to bypass authorization checks and modify their own permission sets.\nBy manipulating the request parameters sent to the updateSubuser function, an attacker with minimal or restricted privileges can elevate their account status to full administrative control.\nThe vulnerability represents a severe security risk as it enables unauthorized access to sensitive server data, automated backups, and critical infrastructure configurations.\nThe attack requires a pre-existing authenticated subuser session to exploit, but does not necessitate interaction from a primary administrator.\nSuccessful exploitation results in complete compromise of the server managed by the panel, potentially leading to arbitrary code execution or total data exfiltration.",
  "technicalDetails": "The vulnerability originates from an insecure implementation of access control logic within the FeatherPanel SubuserController component, specifically the updateSubuser handler function.\nThe root cause is a failure of the application to validate whether the authenticated user submitting the request holds the necessary authority to modify the specific permission objects being targeted.\nIn a secure implementation, the backend should verify that the requester's identity has administrative privileges over the target subuser record. Instead, the application accepts user-supplied parameters to update permission records without verifying ownership or authorization scope.\nAttackers can leverage this by intercepting and modifying the HTTP request destined for the updateSubuser endpoint. By injecting specific flags or modifying the permission bitmask within the POST payload, the authenticated subuser can elevate their privilege level to the highest tier defined in the application.\nThe attack flow follows these steps: 1) The attacker authenticates as a legitimate subuser with restricted rights. 2) The attacker triggers the updateSubuser request through the UI or via direct API interaction. 3) The attacker intercepts the request before it reaches the server. 4) The attacker modifies the permission assignment fields to grant 'full server control' or administrative parity. 5) The server processes the malicious payload, updating the database record for the attacker's own ID without performing a capability check.\nThis vulnerability is strictly a server-side logic flaw affecting the authorization layer. It does not require memory corruption or advanced exploitation techniques; simple parameter tampering is sufficient to achieve the desired privilege escalation.\nPost-exploitation, the attacker gains the ability to execute administrative tasks, including but not limited to the modification of server configurations, downloading or deleting backups, and managing other users. This effectively bypasses the multi-tenant isolation features intended by the panel's design, leading to full horizontal and vertical privilege escalation across the affected service."
}