Description

An isolation flaw has been identified in the application architecture. Users with different privilege levels can access shared resources due to the absence of proper access controls.

These weaknesses allow very low-privileged accounts to access sensitive information related to other users as well as business data.

For example, a user with a guest role can access, via the /view/objectDetail.php endpoint, critical information such as password hashes of all users and associated API keys, including those belonging to high-privileged accounts (e.g., administrators).

Attack Vectors

• Network access: Remote
• Authentication required: Low (legitimate user account)
• User interaction: None
• Scope: Changed (unauthorized cross-context access)
• Observed vectors:
  • Access to another tenant’s resources via IDOR
  • Shared memory or cache between distinct contexts
  • Lack of context validation in inter-service calls
  • Containers sharing volumes without restrictions

Impact

Exploitation of this isolation flaw may lead to:

• Access to password hashes, API keys, and other critical information
• The ability to exploit hashes (offline cracking) or use API keys for impersonation
• Use of compromised access to expand the intrusion scope

Possible Mitigation

• Enforce systematic access control: verify on every request that the user owns the resource
• Use indirect references: rely on opaque identifiers tied to the session
• Tenant isolation: separation at database (separate schemas), network (VLANs), and application levels
• Zero Trust between services: mTLS, service JWTs, SPIFFE/SPIRE
• Isolation testing: integrate cross-tenant tests into CI/CD pipelines

Authors

• Yassine Damiri
• Noé Susset