CWE-269
DiscouragedImproper Privilege Management
Abstraction: Class · Status: Draft
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
6081 vulnerabilities reference this CWE, most recent first.
GHSA-26XW-7HF2-F34Q
Vulnerability from github – Published: 2026-07-15 12:32 – Updated: 2026-07-15 12:32phpMyFAQ before 4.1.5 contains a privilege escalation vulnerability in the user/add API endpoint that allows non-SuperAdmin administrators to create SuperAdmin accounts. A delegated administrator with USER_ADD/EDIT/DELETE permissions can call POST /admin/api/user/add with isSuperAdmin: true and attacker-chosen credentials to create a SuperAdmin account, then authenticate as that account to achieve full instance takeover.
{
"affected": [],
"aliases": [
"CVE-2026-57996"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-15T12:18:16Z",
"severity": "HIGH"
},
"details": "phpMyFAQ before 4.1.5 contains a privilege escalation vulnerability in the user/add API endpoint that allows non-SuperAdmin administrators to create SuperAdmin accounts. A delegated administrator with USER_ADD/EDIT/DELETE permissions can call POST /admin/api/user/add with isSuperAdmin: true and attacker-chosen credentials to create a SuperAdmin account, then authenticate as that account to achieve full instance takeover.",
"id": "GHSA-26xw-7hf2-f34q",
"modified": "2026-07-15T12:32:02Z",
"published": "2026-07-15T12:32:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-r2f4-v277-hvw9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57996"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/phpmyfaq-privilege-escalation-via-missing-superadmin-guard-in-user-add-endpoint"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/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-2724-6CPJ-GF3V
Vulnerability from github – Published: 2026-09-10 15:09 – Updated: 2026-09-10 15:09Summary
External knowledge connections are created and owned by administrators, and are shared by every external knowledge base bound to them. Deleting an external knowledge base also removed that connection from the instance configuration, with no check on the caller's role and no check for other knowledge bases still using it. Any authenticated user holding a write grant on a single external knowledge base could therefore wipe a shared connection that other knowledge bases depend on, and the dedicated administrator route for deleting a connection explicitly refuses that same operation while the connection is still in use.
Preconditions
The deployment uses external knowledge bases, backed by the qdrant, milvus or pgvector external providers. Instances with only local knowledge bases are not affected.
An administrator created at least one external connection and at least one external knowledge base bound to it. Both of those actions are admin-only.
The attacker is an ordinary authenticated user holding a write grant on one of those external knowledge bases. A read grant is not enough, and an unrelated user cannot reach the route at all.
The damage scales with sharing. It is worst when one connection backs several knowledge bases, because deleting a single knowledge base destroys the connection for all of them.
Impact
An ordinary user removes instance-wide configuration that only administrators can create or manage. Every other external knowledge base bound to the deleted connection keeps its stored connection id and stops working: retrieval against it fails with "External knowledge connection not found", so those knowledge bases return nothing in chat until an administrator recreates the connection by hand. The stored credential goes with it, and connection API responses strip credentials, so an administrator who did not keep the key elsewhere cannot restore the connection without obtaining it again.
Nothing is disclosed to the attacker and the external vector store itself is untouched. What is lost is Open WebUI's own connection configuration, and the availability of the knowledge bases that depend on it.
Fix
Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28113. Deleting an external knowledge base now clears its connection only when the caller is an administrator and the knowledge base being deleted is the last one referencing that connection, matching the dedicated connection delete route. Upgrading resolves the issue with no configuration change required.
Root cause
Affected component: the knowledge base delete handler in backend/open_webui/routers/knowledge.py, reached through DELETE /api/v1/knowledge/{id}/delete.
Affected setup: every release from 0.10.0, where external knowledge connections were introduced, up to and including 0.11.0.
The handler authorized the caller against the knowledge base, which a write grant satisfies, and then performed a second, unrelated operation against global configuration in the same request. That second step carried no authorization of its own. It neither required the administrator role that creating a connection requires, nor counted the other knowledge bases still bound to the connection. The dedicated route DELETE /api/v1/knowledge/external/connections/{id} already performed both checks, so an outcome an administrator was blocked from was reachable by a non-administrator through the knowledge base route.
Proof of concept
Reproduced against a local instance on 0.11.0 with default settings, and against 0.11.1 for comparison.
An administrator created one external connection and two external knowledge bases bound to it, then granted a plain user write access on the first knowledge base. As that user:
DELETE /api/v1/knowledge/{KB_A}/delete
Authorization: Bearer <user token>
On 0.11.0 the request returns 200 true. The administrator connection list then returns zero connections, the second knowledge base still carries the deleted connection id, and retrieving from it raises "External knowledge connection not found".
On 0.11.1 the same request deletes the knowledge base, the connection list still returns the connection, and the second knowledge base is unaffected. An administrator deleting the last remaining knowledge base on that connection still clears it, so the intended cleanup is preserved.
Credits
@Bellingham-max, for reporting the missing authorization on the shared connection teardown.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.0"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87998"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T15:09:52Z",
"nvd_published_at": "2026-09-09T22:18:48Z",
"severity": "HIGH"
},
"details": "## Summary\nExternal knowledge connections are created and owned by administrators, and are shared by every external knowledge base bound to them. Deleting an external knowledge base also removed that connection from the instance configuration, with no check on the caller\u0027s role and no check for other knowledge bases still using it. Any authenticated user holding a write grant on a single external knowledge base could therefore wipe a shared connection that other knowledge bases depend on, and the dedicated administrator route for deleting a connection explicitly refuses that same operation while the connection is still in use.\n\n## Preconditions\nThe deployment uses external knowledge bases, backed by the qdrant, milvus or pgvector external providers. Instances with only local knowledge bases are not affected.\n\nAn administrator created at least one external connection and at least one external knowledge base bound to it. Both of those actions are admin-only.\n\nThe attacker is an ordinary authenticated user holding a write grant on one of those external knowledge bases. A read grant is not enough, and an unrelated user cannot reach the route at all.\n\nThe damage scales with sharing. It is worst when one connection backs several knowledge bases, because deleting a single knowledge base destroys the connection for all of them.\n\n## Impact\nAn ordinary user removes instance-wide configuration that only administrators can create or manage. Every other external knowledge base bound to the deleted connection keeps its stored connection id and stops working: retrieval against it fails with \"External knowledge connection not found\", so those knowledge bases return nothing in chat until an administrator recreates the connection by hand. The stored credential goes with it, and connection API responses strip credentials, so an administrator who did not keep the key elsewhere cannot restore the connection without obtaining it again.\n\nNothing is disclosed to the attacker and the external vector store itself is untouched. What is lost is Open WebUI\u0027s own connection configuration, and the availability of the knowledge bases that depend on it.\n\n## Fix\nFixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28113. Deleting an external knowledge base now clears its connection only when the caller is an administrator and the knowledge base being deleted is the last one referencing that connection, matching the dedicated connection delete route. Upgrading resolves the issue with no configuration change required.\n\n## Root cause\nAffected component: the knowledge base delete handler in backend/open_webui/routers/knowledge.py, reached through DELETE /api/v1/knowledge/{id}/delete.\n\nAffected setup: every release from 0.10.0, where external knowledge connections were introduced, up to and including 0.11.0.\n\nThe handler authorized the caller against the knowledge base, which a write grant satisfies, and then performed a second, unrelated operation against global configuration in the same request. That second step carried no authorization of its own. It neither required the administrator role that creating a connection requires, nor counted the other knowledge bases still bound to the connection. The dedicated route DELETE /api/v1/knowledge/external/connections/{id} already performed both checks, so an outcome an administrator was blocked from was reachable by a non-administrator through the knowledge base route.\n\n## Proof of concept\nReproduced against a local instance on 0.11.0 with default settings, and against 0.11.1 for comparison.\n\nAn administrator created one external connection and two external knowledge bases bound to it, then granted a plain user write access on the first knowledge base. As that user:\n\n```\nDELETE /api/v1/knowledge/{KB_A}/delete\nAuthorization: Bearer \u003cuser token\u003e\n```\n\nOn 0.11.0 the request returns 200 true. The administrator connection list then returns zero connections, the second knowledge base still carries the deleted connection id, and retrieving from it raises \"External knowledge connection not found\".\n\nOn 0.11.1 the same request deletes the knowledge base, the connection list still returns the connection, and the second knowledge base is unaffected. An administrator deleting the last remaining knowledge base on that connection still clears it, so the intended cleanup is preserved.\n\n## Credits\n@Bellingham-max, for reporting the missing authorization on the shared connection teardown.",
"id": "GHSA-2724-6cpj-gf3v",
"modified": "2026-09-10T15:09:52Z",
"published": "2026-09-10T15:09:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-2724-6cpj-gf3v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87998"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/28113"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/dc03e7e595d61be97b25a1dd7bb99ad264f73199"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Non-admin users can delete admin-owned external knowledge connections via knowledge base deletion"
}
GHSA-273Q-QGH5-WRJ6
Vulnerability from github – Published: 2026-06-08 23:09 – Updated: 2026-06-08 23:09Every /ui/* POST / PUT / PATCH / DELETE route processes the request as soon as the session cookie validates. SameSite=Lax on the session cookie prevents most cross-site form submits but does not protect:
- top-level form-submit navigations from third-party pages (some browsers still send Lax cookies on top-level POSTs)
- same-registrable-domain attackers (sibling-subdomain XSS, subdomain takeover)
- the
GET /ui/logoutroute, which a third-party<img src=".../ui/logout">can force-trigger
The admin UI signs CA certificates, mints API keys, rotates / retires / deletes CAs, disables operators, and changes server settings. CSRF here is a real privilege escalation, not just annoyance.
Affected
All released versions up to v0.3.2.
Suggested fix
Double-submit cookie: a 32-byte crypto/rand token in a non-HttpOnly _csrf cookie, echoed in either X-CSRF-Token (htmx) or a _csrf form field (HTML forms). Compared in constant time. Rotated on every privilege transition (Login, OIDC StartAuthenticatedSession, CompleteTwoFactor, Logout) so pre-auth fixation cannot survive promotion. Rejections audit-logged as ui.csrf.rejected with reason; response body stays opaque.
/ui/logout becomes POST so it is no longer reachable via <img> tags.
Fix coordinates with the Secure-cookie advisory disclosed concurrently — the _csrf cookie inherits the same Secure-attribute derivation.
Reproducer
With an authenticated operator session in browser tab A, open the following minimal HTML in any other tab:
<form action="https://nebula.example.com/ui/cas/{ca-id}/delete" method="POST">
<button>Click for free puppy</button>
</form>
Click. The CA is deleted — the server processes the POST because the session cookie is automatically attached and there is no other check. The same trick works for force-rotate, retire, mint API keys, disable operators, etc.
Alternative force-logout: <img src="https://nebula.example.com/ui/logout"> placed on an attacker's page logs out any visiting authenticated operator. No interaction required.
Notes
- Multipart and JSON endpoints don't exist in the current UI surface. Future additions must rely on the header path because
r.PostFormValueonly readsapplication/x-www-form-urlencodedbodies. The middleware's package comment documents this. - The patch assumes nebula-mgmt is the sole authority on its registrable domain. A compromised sibling subdomain can still set parent-domain cookies and forge matches; SameSite=Lax does not prevent that. Documented in the patch.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/juev/nebula-mesh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47725"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:09:21Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Every `/ui/*` POST / PUT / PATCH / DELETE route processes the request as soon as the session cookie validates. `SameSite=Lax` on the session cookie prevents most cross-site form submits but does not protect:\n\n- top-level form-submit navigations from third-party pages (some browsers still send Lax cookies on top-level POSTs)\n- same-registrable-domain attackers (sibling-subdomain XSS, subdomain takeover)\n- the `GET /ui/logout` route, which a third-party `\u003cimg src=\".../ui/logout\"\u003e` can force-trigger\n\nThe admin UI signs CA certificates, mints API keys, rotates / retires / deletes CAs, disables operators, and changes server settings. CSRF here is a real privilege escalation, not just annoyance.\n\n## Affected\nAll released versions up to v0.3.2.\n\n## Suggested fix\nDouble-submit cookie: a 32-byte `crypto/rand` token in a non-HttpOnly `_csrf` cookie, echoed in either `X-CSRF-Token` (htmx) or a `_csrf` form field (HTML forms). Compared in constant time. Rotated on every privilege transition (`Login`, OIDC `StartAuthenticatedSession`, `CompleteTwoFactor`, `Logout`) so pre-auth fixation cannot survive promotion. Rejections audit-logged as `ui.csrf.rejected` with reason; response body stays opaque.\n\n`/ui/logout` becomes POST so it is no longer reachable via `\u003cimg\u003e` tags.\n\nFix coordinates with the Secure-cookie advisory disclosed concurrently \u2014 the `_csrf` cookie inherits the same `Secure`-attribute derivation.\n\n## Reproducer\nWith an authenticated operator session in browser tab A, open the following minimal HTML in any other tab:\n\n```html\n\u003cform action=\"https://nebula.example.com/ui/cas/{ca-id}/delete\" method=\"POST\"\u003e\n \u003cbutton\u003eClick for free puppy\u003c/button\u003e\n\u003c/form\u003e\n```\n\nClick. The CA is deleted \u2014 the server processes the POST because the session cookie is automatically attached and there is no other check. The same trick works for force-rotate, retire, mint API keys, disable operators, etc.\n\nAlternative force-logout: `\u003cimg src=\"https://nebula.example.com/ui/logout\"\u003e` placed on an attacker\u0027s page logs out any visiting authenticated operator. No interaction required.\n\n## Notes\n- Multipart and JSON endpoints don\u0027t exist in the current UI surface. Future additions must rely on the header path because `r.PostFormValue` only reads `application/x-www-form-urlencoded` bodies. The middleware\u0027s package comment documents this.\n- The patch assumes nebula-mgmt is the sole authority on its registrable domain. A compromised sibling subdomain can still set parent-domain cookies and forge matches; SameSite=Lax does not prevent that. Documented in the patch.",
"id": "GHSA-273q-qgh5-wrj6",
"modified": "2026-06-08T23:09:21Z",
"published": "2026-06-08T23:09:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juev/nebula-mesh/security/advisories/GHSA-273q-qgh5-wrj6"
},
{
"type": "PACKAGE",
"url": "https://github.com/juev/nebula-mesh"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "nebula-mesh\u0027s web UI lacks CSRF tokens on /ui/* mutating endpoints"
}
GHSA-2746-64V7-WVW8
Vulnerability from github – Published: 2022-05-13 01:40 – Updated: 2022-05-13 01:40Vulnerability in the Oracle Hospitality Reporting and Analytics component of Oracle Hospitality Applications (subcomponent: Reporting). Supported versions that are affected are 8.5.1 and 9.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Hospitality Reporting and Analytics. While the vulnerability is in Oracle Hospitality Reporting and Analytics, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Hospitality Reporting and Analytics. CVSS 3.0 Base Score 7.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2017-10000"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-08T15:29:00Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Hospitality Reporting and Analytics component of Oracle Hospitality Applications (subcomponent: Reporting). Supported versions that are affected are 8.5.1 and 9.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Hospitality Reporting and Analytics. While the vulnerability is in Oracle Hospitality Reporting and Analytics, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Hospitality Reporting and Analytics. CVSS 3.0 Base Score 7.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).",
"id": "GHSA-2746-64v7-wvw8",
"modified": "2022-05-13T01:40:52Z",
"published": "2022-05-13T01:40:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10000"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038941"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-274V-R947-V34R
Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2024-05-14 20:47OpenStack Identity (Keystone) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-2 does not properly handle chained delegation, which allows remote authenticated users to gain privileges by leveraging a (1) trust or (2) OAuth token with impersonation enabled to create a new token with additional roles.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "keystone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0a0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-3476"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-14T20:47:27Z",
"nvd_published_at": "2014-06-17T14:55:00Z",
"severity": "MODERATE"
},
"details": "OpenStack Identity (Keystone) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-2 does not properly handle chained delegation, which allows remote authenticated users to gain privileges by leveraging a (1) trust or (2) OAuth token with impersonation enabled to create a new token with additional roles.",
"id": "GHSA-274v-r947-v34r",
"modified": "2024-05-14T20:47:27Z",
"published": "2022-05-13T01:26:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3476"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/keystone/+bug/1324592"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2014-06/msg00031.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/57886"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/59547"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2014/06/12/3"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/68026"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "OpenStack Identity Keystone is vulnerable to Block delegation escalation of privilege"
}
GHSA-2752-84HQ-W9HQ
Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22VMware Fusion (11.x before 11.5.5), VMware Remote Console for Mac (11.x and prior before 11.2.0 ) and Horizon Client for Mac (5.x and prior before 5.4.3) contain a privilege escalation vulnerability due to improper XPC Client validation. Successful exploitation of this issue may allow attackers with normal user privileges to escalate their privileges to root on the system where Fusion, VMware Remote Console for Mac or Horizon Client for Mac is installed.
{
"affected": [],
"aliases": [
"CVE-2020-3974"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-10T14:15:00Z",
"severity": "HIGH"
},
"details": "VMware Fusion (11.x before 11.5.5), VMware Remote Console for Mac (11.x and prior before 11.2.0 ) and Horizon Client for Mac (5.x and prior before 5.4.3) contain a privilege escalation vulnerability due to improper XPC Client validation. Successful exploitation of this issue may allow attackers with normal user privileges to escalate their privileges to root on the system where Fusion, VMware Remote Console for Mac or Horizon Client for Mac is installed.",
"id": "GHSA-2752-84hq-w9hq",
"modified": "2022-05-24T17:22:44Z",
"published": "2022-05-24T17:22:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3974"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2020-0017.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2795-VVMF-MQF8
Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32Vulnerability in the Oracle Quality product of Oracle E-Business Suite (component: Internal Operations). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Quality. While the vulnerability is in Oracle Quality, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Quality accessible data as well as unauthorized update, insert or delete access to some of Oracle Quality accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Quality. CVSS 3.1 Base Score 8.2 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:L).
{
"affected": [],
"aliases": [
"CVE-2026-60854"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T22:18:22Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Quality product of Oracle E-Business Suite (component: Internal Operations). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Quality. While the vulnerability is in Oracle Quality, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Quality accessible data as well as unauthorized update, insert or delete access to some of Oracle Quality accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Quality. CVSS 3.1 Base Score 8.2 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:L).",
"id": "GHSA-2795-vvmf-mqf8",
"modified": "2026-07-22T00:32:03Z",
"published": "2026-07-22T00:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60854"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-279C-7W72-MX63
Vulnerability from github – Published: 2025-06-02 09:31 – Updated: 2026-01-15 18:31During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the VAPIX Device Configuration framework that allowed a privilege escalation, enabling a lower-privileged user to gain administrator privileges.
{
"affected": [],
"aliases": [
"CVE-2025-0358"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-02T08:15:20Z",
"severity": "HIGH"
},
"details": "During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the VAPIX Device Configuration framework that allowed a privilege escalation, enabling a\u00a0lower-privileged user to gain administrator privileges.",
"id": "GHSA-279c-7w72-mx63",
"modified": "2026-01-15T18:31:26Z",
"published": "2025-06-02T09:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0358"
},
{
"type": "WEB",
"url": "https://www.axis.com/dam/public/35/90/85/cve-2025-0358pdf-en-US-483809.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-27GP-8389-HM4W
Vulnerability from github – Published: 2025-07-30 13:17 – Updated: 2025-07-30 13:17A Privilege Escalation vulnerability was identified in the Keycloak identity and access management solution, specifically when FGAPv2 is enabled in version 26.2.x. The flaw lies in the admin permission enforcement logic, where a user with manage-users privileges can self-assign realm-admin rights. The escalation occurs due to missing privilege boundary checks in role mapping operations via the admin REST interface. A malicious administrator with limited permissions can exploit this by editing their own user roles, gaining unauthorized full access to realm configuration and user data.
This issue has been fixed in versions 26.2.6, and 26.3.0.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "26.2.0"
},
{
"fixed": "26.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-7784"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-30T13:17:19Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "A Privilege Escalation vulnerability was identified in the Keycloak identity and access management solution, specifically when FGAPv2 is enabled in version 26.2.x. The flaw lies in the admin permission enforcement logic, where a user with manage-users privileges can self-assign realm-admin rights. The escalation occurs due to missing privilege boundary checks in role mapping operations via the admin REST interface. A malicious administrator with limited permissions can exploit this by editing their own user roles, gaining unauthorized full access to realm configuration and user data.\n\nThis issue has been fixed in versions 26.2.6, and 26.3.0.",
"id": "GHSA-27gp-8389-hm4w",
"modified": "2025-07-30T13:17:19Z",
"published": "2025-07-30T13:17:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-27gp-8389-hm4w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7784"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/issues/41137"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/pull/41168"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:12015"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:12016"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-7784"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2381861"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Keycloak Privilege Escalation Vulnerability in Admin Console (FGAPv2 Enabled)"
}
GHSA-27H3-C9GV-83JX
Vulnerability from github – Published: 2026-08-07 18:31 – Updated: 2026-08-07 18:31Improper privilege management in the XML-RPC API of Plesk before 18.0.80, allows an authenticated reseller to obtain an administrative session for the root user account.
{
"affected": [],
"aliases": [
"CVE-2026-64637"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-07T18:17:20Z",
"severity": "CRITICAL"
},
"details": "Improper privilege management in the XML-RPC API of Plesk before 18.0.80, allows an authenticated reseller to obtain an administrative session for the root user account.",
"id": "GHSA-27h3-c9gv-83jx",
"modified": "2026-08-07T18:31:46Z",
"published": "2026-08-07T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64637"
},
{
"type": "WEB",
"url": "https://support.plesk.com/hc/en-us/articles/42432168683799"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-48
Strategy: Separation of Privilege
Follow the principle of least privilege when assigning access rights to entities in a software system.
Mitigation MIT-49
Strategy: Separation of Privilege
Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-233: Privilege Escalation
An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.
CAPEC-58: Restful Privilege Elevation
An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.