Multi-tenant SMS data exposure via parameter tampering in OpenCode messaging platform
OpenCode Systems OC Messaging and USSD Gateway versions 6.32.2 contain an insecure direct object reference (IDOR) vulnerability allowing authenticated users to access SMS messages from other tenants by manipulating company or tenant identifiers. This affects multi-tenant deployments handling sensitive communications.
CVE References
Affected
OpenCode Systems OC Messaging and USSD Gateway version 6.32.2 contains a classic insecure direct object reference vulnerability where tenant isolation is enforced at the authentication layer but not at the authorisation layer. An authenticated user with low privilege can craft HTTP requests containing company or tenant identifier parameters pointing to other organisations' data and successfully retrieve SMS messages outside their authorised scope. This is CVSS 8.1 because it requires a valid credential to trigger yet grants unauthorised access to sensitive communications data across tenant boundaries.
The technical requirements are straightforward: the application likely validates that a user is logged in and that their request contains well-formed parameters, but fails to verify that the requested tenant identifier matches the user's own tenant assignment before returning data. This pattern emerges frequently in multi-tenant systems where developers assume that checking "is this user authenticated" provides sufficient isolation. In messaging and USSD gateways, SMS messages often contain one-time codes, transactional alerts, or confidential notifications, making cross-tenant read access a material privacy and security failure.
Affected organisations are those running OC Messaging or USSD Gateway 6.32.2 in multi-tenant environments, particularly telecommunications providers, fintech platforms, or enterprise communication services that rely on these systems to handle SMS traffic for multiple clients. The vulnerability is exploitable by any account holder, including former employees with residual access, making it a heightened risk in organisations with weak account lifecycle management.
Defenders should immediately identify systems running version 6.32.2 and apply vendor patches. In advance of patching, monitor authentication logs for unusual API requests to the messaging gateway that include tenant or company identifiers different from the authenticated user's primary assignment. Implement additional access control checks at the application level to validate tenant ownership independently of user authentication. Consider enabling request validation rules that reject or flag requests containing suspicious tenant parameters.
This vulnerability reflects a recurring failure mode in SaaS and multi-tenant infrastructure: treating authentication and authorisation as equivalent when they serve different functions. Organisations building or managing multi-tenant systems should implement explicit object-level access checks on every data retrieval operation, ideally through middleware or permission frameworks that enforce tenant context independently of the user credential.
Sources