CVE-2025-12766 – BlackBerry AtHoc IDOR

Author: Thea Younes

Published: November 19, 2025

While using BlackBerry AtHoc as part of a client’s normal operational workflow, I noticed unexpected report behavior that exposed information between tenant organizations. This observation led to the discovery of an authorization flaw, which was reported responsibly to BlackBerry’s Product Security Incident Response Team (PSIRT).

Summary

Product: BlackBerry AtHoc Enterprise Edition
Version: Server Version 7.21.0 Patch Level 0 Build Number 1277 (Build Date 2024-06-05)
Vulnerability Type: Insecure Direct Object Reference (IDOR)
Impact: Cross-tenant data exposure (read-only)
Severity: High (confidential data leakage across organizations)
Reported by: Thea Younes, Valiant Security Labs

Technical Details

The vulnerability was identified in the DetailedReport.aspx component of AtHoc's web interface. The endpoint did not enforce tenant-level authorization when accessing detailed alert reports via the alertId parameter. As a result, modifying the parameter allowed authenticated users to view report data belonging to other tenant organizations.

Endpoint (redacted):
/client/ReportsViews/DetailedReport.aspx?alertId=<ALERT_ID>&[other parameters redacted]

Reproduction (Redacted)

The following describes the reproduction steps performed in a read-only, non-destructive manner using a test account. All sensitive data such as hosts, tokens, and IDs have been removed for confidentiality.

Log in to AtHoc Alerts with a valid user account belonging to Organization A.
Navigate to a detailed report page for an alert accessible to Organization A.
Change the alertId in the URL to another valid ID known to exist (belonging to Organization B).
Reload the page.
The application displays the report data for the alert belonging to Organization B instead of denying access.

# Example (sanitized)
/client/ReportsViews/DetailedReport.aspx?alertId=<ALERT_ID>&isAlertTracking=Y
Host: [redacted-host]
Cookie: [session cookie redacted]
Authorization: [redacted]

Observed vs Expected Behavior

Observed: The page returned a 200 OK response with the report data for any valid alertId, even when it belonged to another organization.

Expected: The system should verify tenant ownership and respond with 403 Forbidden or a generic “not found” message for unauthorized requests.

Root Cause

The issue stemmed from missing server-side authorization logic for the alertId parameter. The backend relied solely on client-supplied identifiers without validating ownership at the tenant or organization level.

Remediation

Implement strict tenant-level authorization checks for all report endpoints.
Return appropriate HTTP status codes (403/404) for unauthorized access.
Audit other reporting modules for similar authorization inconsistencies.

Disclosure Timeline

2025-10-31: Vulnerability reported to BlackBerry PSIRT.
2025-11-01: PSIRT acknowledged and began investigation.
2025-11-19: Patch and advisory released (CVE-2025-12766).

References

Acknowledgment

This issue was discovered and responsibly disclosed by Thea Younes of Valiant Security Labs. Testing was limited to read-only validation and performed ethically in accordance with coordinated vulnerability disclosure principles.

Special thanks to the BlackBerry PSIRT team for their professionalism and collaboration.