Description

Any authenticated case participant can fetch any OTHER vendor's CaseStatement + per-vul CaseMemberStatus by supplying that member's id — test_func only checks _is_my_case, not ownership of kwargs['member']. Bypasses share_status; leaks embargoed vendor affected/not-affected + statement text cross-tenant.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-12T22:17:14.823Z",
  "pubdate": "2026-08-12T22:17:14.823Z",
  "executiveSummary": "This vulnerability is an authorization bypass and cross-tenant data disclosure flaw residing within the case management subsystem. The security defect allows any authenticated case participant to retrieve sensitive information belonging to entirely different vendors, specifically bypassing intended access control mechanisms such as share_status constraints.\nThe primary impact of this vulnerability is the unauthorized exposure of embargoed vendor affected and not-affected status parameters, alongside proprietary CaseStatement text associated with other participating vendors.\nThe affected system components involve the case access validation logic, specifically utilizing test_func which improperly restricts validation checks to _is_my_case while failing to enforce ownership verification on the supplied kwargs['member'] parameter.\nThe risk implications are significant for multi-tenant environments handling sensitive vulnerability coordination, as malicious or curious authenticated participants can systematically harvest confidential embargoed data across tenant boundaries.\nThe attacker capabilities require valid user authentication within the platform and participation in at least one valid case to gain baseline system access. Exploitation requirements necessitate the attacker to supply targeted member identifiers to iteratively query and extract restricted cross-tenant records through the vulnerable retrieval function.",
  "technicalDetails": "The root cause of this vulnerability lies in an authorization logic flaw within the access control validation routines governing case member status and case statements. Specifically, the security implementation relies on the test_func validation routine, which solely executes the _is_my_case check to determine whether the requesting user is authorized to access a given case context.\nHowever, the function completely omits ownership and tenancy validation against the supplied kwargs['member'] parameter. Because the authorization layer fails to verify whether the requested member ID actually belongs to the authenticated user's organization or vendor boundary, an attacker can manipulate or iterate through arbitrary member identifiers.\nThe vulnerable components include the endpoint responsible for fetching the CaseStatement and per-vulnerability CaseMemberStatus objects. Normally, sharing restrictions and visibility controls such as share_status are enforced to protect embargoed vulnerability details from unauthorized cross-tenant exposure. By exploiting this authorization bypass, these controls are rendered entirely ineffective.\nThe attack flow proceeds as follows: First, the authenticated attacker establishes a valid session and identifies a target case where they are an authorized participant. Second, the attacker issues a data retrieval request targeting the case subsystem while supplying an arbitrary, guessed, or enumerated identifier within kwargs['member'] that corresponds to a different vendor's entity.\nThird, the backend function executes test_func, which successfully validates that the user is part of the case via _is_my_case, bypassing deeper object-level permissions. Fourth, the application processes the request without validating vendor ownership of the requested member identifier, subsequently querying and returning the associated embargoed affected/not-affected status and confidential statement text.\nThe post-exploitation impact includes the breach of confidential vulnerability coordination data, unauthorized intelligence gathering regarding unpatched software vulnerabilities across competing or cooperating vendors, and potential violation of coordinated disclosure agreements or embargo policies."
}