Broken Access Control in SigNoz Exposes Alert Rules

Impact Analysis

This vulnerability can lead to unauthorized access and manipulation of alert rules across different organizations sharing the same SigNoz instance. An attacker authenticated to one organization can read, edit, or delete alert rules of another organization, potentially disrupting monitoring and alerting processes, causing loss of critical alert configurations, and impacting operational security.

Useful 0 Not Useful 0

Executive Summary

CVE-2026-57956 is a broken access control vulnerability in SigNoz version 0.130.1 and earlier. It allows authenticated users to access alert rules belonging to other organizations by supplying a target rule UUID. This happens because the system fails to filter alert rules by organization ID, missing tenant isolation checks. As a result, attackers can read, modify, or delete alert rules of other organizations, bypassing multi-tenant access controls.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by attempting to access alert rules belonging to other organizations using manipulated UUIDs while authenticated as a user from a different organization.

Specifically, you can test if the system improperly allows access to alert rules by supplying a target rule UUID that belongs to another organization and observing if you can read, edit, or delete those rules.

Since the vulnerability involves missing tenant isolation checks in the alert rule store predicates, detection involves verifying whether the system filters alert rules by organization ID.

No explicit commands are provided in the resources, but a practical approach would be to use API calls or HTTP requests to the alert rules endpoints with UUIDs from other organizations while authenticated, to check for unauthorized access.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include restricting access to the alert rules API endpoints to ensure proper tenant isolation by filtering alert rules based on organization ID.

Specifically, the fix involves adding org_id filtering in the rule store predicates (such as GetStoredRule, EditRule, DeleteRule) and rejecting requests where the organization ID of the resource does not match the caller's organization.

Additionally, auditing the rule-history endpoints for similar access control issues is recommended.

Until a patch is applied, consider limiting authenticated user permissions and monitoring for suspicious activity involving access to alert rules with UUIDs from other organizations.

Useful 0 Not Useful 0