CVE-2026-122007 in Oqtane
Summary
by MITRE • 11/04/2026
Oqtane Framework before 10.3.0 contains a broken access control vulnerability in SettingController.cs that allows an authenticated site administrator to read and modify settings belonging to other sites within the same tenant database by supplying an arbitrary entityId for Site or Role type settings, since IsAuthorized and FilterPrivate fail to verify the requested site matches the current alias SiteId. Attackers can exploit the /api/setting endpoints to disclose private values such as SMTPPassword, SMTPClientSecret, and ExternalLogin ClientSecret, and to alter another site's OIDC/OAuth2 authentication configuration without requiring host privileges.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The Oqtane Framework prior to version 10.3.0 contains a critical broken access control vulnerability within the SettingController component, specifically affecting how settings are retrieved and modified for multi-tenant environments. This flaw stems from an insufficient verification of resource ownership during API requests targeting site or role type configurations. When an authenticated user with administrative privileges on one site attempts to interact with settings belonging to another site hosted in the same tenant database, the application fails to ensure that the requested entity identifier corresponds to the current session's authorized context. The core technical deficiency lies in the IsAuthorized and FilterPrivate methods, which do not adequately cross-reference the supplied entityId against the SiteId associated with the active user alias. Consequently, an attacker can bypass intended isolation boundaries by manipulating request parameters to target arbitrary sites within the shared database infrastructure.
This vulnerability enables authenticated site administrators to perform unauthorized read and write operations on configuration data belonging to peer sites. By supplying a manipulated entityId in requests directed at /api/setting endpoints, attackers can extract sensitive security credentials such as SMTP passwords, SMTP client secrets, and external login client secrets. These disclosures compromise the confidentiality of communication channels and third-party integrations for other tenants or sub-sites within the same deployment instance. Furthermore, the ability to modify these settings allows an attacker to alter OpenID Connect and OAuth2 authentication configurations for targeted sites. This capability can lead to complete takeover of user accounts through forged identity provider responses or disruption of service availability by disabling legitimate authentication mechanisms.
From a classification perspective, this issue aligns with CWE-639, which describes authorization bypass via vulnerability in the same application, as well as CWE-284 regarding improper access control where security-critical system components are not appropriately protected. In terms of offensive tactics, this exploitation vector corresponds to MITRE ATT&CK technique T1078, specifically valid accounts used for lateral movement or privilege escalation within a multi-tenant architecture. The impact extends beyond simple data leakage; it undermines the fundamental trust model of multi-tenancy by allowing horizontal privilege escalation among peers who should have strictly isolated administrative domains.
Mitigation strategies must prioritize immediate patching to version 10.3.0 or later, where these authorization checks have been corrected to enforce strict binding between the requesting user's site context and the target resource identifier. Until an update is applied, administrators should implement network-level controls such as web application firewalls that inspect API payloads for anomalies in entityId parameters relative to known tenant boundaries. Additionally, enforcing principle of least privilege by restricting administrative access to only those users who genuinely require cross-site management capabilities can reduce the attack surface. Regular auditing of authentication logs and configuration change events is also recommended to detect any unauthorized modifications resulting from this vulnerability.