Summary
Frigate's WebSocket handler may forward admin-only topics from any authenticated viewer without verifying the user's role. An authenticated viewer could therefore restart the service or change camera and monitoring settings, potentially reducing surveillance coverage.
Affected context
The issue occurs in Frigate deployments where authentication is enabled and the WebSocket handler accepts user-selected topics. Authentication confirms that a user is logged in, but the request path does not consistently enforce role-aware authorization before dispatching administrative operations. Viewer accounts are therefore exposed to actions intended for administrators.
Exploit preconditions
- Attack surface: Frigate's authenticated WebSocket interface
- Required access: Valid credentials for an authenticated viewer account
- Trigger point: Submission of a WebSocket message targeting an administrative topic
- Why exploitation is possible: The handler dispatches selected topics without verifying that the authenticated user has the required administrative role
Why this happens
The underlying bug is a missing authorization check after authentication. The WebSocket path establishes that a client is authenticated but does not enforce the permissions associated with the user's role before dispatching sensitive operations. This maps to CWE-862: Missing Authorization, in which a system fails to verify whether an authenticated principal is permitted to perform a requested action.
Potential impact
- An authenticated viewer could restart the Frigate service
- Camera detection, recording, snapshot, audio, or motion settings may be changed
- Monitoring functions could be disabled or weakened
- Security events may be missed during altered monitoring periods
- Service availability and operational integrity could be affected
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the operation boundary rather than relying only on authentication or an upstream proxy.
Common defensive patterns include:
- Applying explicit role and permission checks to every sensitive WebSocket topic
- Maintaining a deny-by-default allowlist for viewer-accessible operations
- Centralizing authorization decisions so alternate request paths cannot bypass them
- Validating authenticated identity and role information at the handler or dispatcher boundary
- Separating administrative commands from viewer-facing message channels where practical
- Limiting administrative privileges and reviewing the permissions assigned to service accounts
- Recording authorization failures and sensitive configuration changes for audit and detection
How teams detect issues like this
Organizations can assess for this class of issue through:
- Static analysis and code review checks for WebSocket dispatches that lack nearby authorization enforcement
- Review of message-topic routing, role propagation, and proxy-to-application authentication flows
- Tests that exercise administrative topics with viewer-level credentials and verify denial
- Policy checks requiring explicit authorization for restart, configuration, and monitoring-control operations
- Runtime monitoring for administrative topic requests from non-administrative identities
- Automated security review tools that identify authenticated endpoints without corresponding permission checks
