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.
15215 vulnerabilities reference this CWE, most recent first.
GHSA-6CCM-R89R-8Q3J
Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in merkulove Lottier lottier-gutenberg allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Lottier: from n/a through <= 1.1.1.
{
"affected": [],
"aliases": [
"CVE-2025-66167"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T09:15:59Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in merkulove Lottier lottier-gutenberg allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Lottier: from n/a through \u003c= 1.1.1.",
"id": "GHSA-6ccm-r89r-8q3j",
"modified": "2026-01-20T15:32:15Z",
"published": "2025-12-16T09:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66167"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/lottier-gutenberg/vulnerability/wordpress-lottier-plugin-1-1-1-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/lottier-gutenberg/vulnerability/wordpress-lottier-plugin-1-1-1-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:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6CGJ-2CCJ-288G
Vulnerability from github – Published: 2025-04-02 15:31 – Updated: 2025-04-02 15:31The Shopper Approved Reviews plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the ajax_callback_update_sa_option() function in versions 2.0 to 2.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.
{
"affected": [],
"aliases": [
"CVE-2025-3063"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-02T10:15:19Z",
"severity": "HIGH"
},
"details": "The Shopper Approved Reviews plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the ajax_callback_update_sa_option() function in versions 2.0 to 2.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.",
"id": "GHSA-6cgj-2ccj-288g",
"modified": "2025-04-02T15:31:35Z",
"published": "2025-04-02T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3063"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/shopperapproved-reviews/trunk/shopperapproved.php#L154"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c042b347-2884-436d-abd3-6931548f18d6?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-6CGP-2PXR-4VM6
Vulnerability from github – Published: 2025-03-24 15:30 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in westerndeal Advanced Dewplayer allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Advanced Dewplayer: from n/a through 1.6.
{
"affected": [],
"aliases": [
"CVE-2025-30592"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-24T14:15:31Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in westerndeal Advanced Dewplayer allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Advanced Dewplayer: from n/a through 1.6.",
"id": "GHSA-6cgp-2pxr-4vm6",
"modified": "2026-04-01T18:34:00Z",
"published": "2025-03-24T15:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30592"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/advanced-dewplayer/vulnerability/wordpress-advanced-dewplayer-1-6-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-6CJG-W4WG-37MH
Vulnerability from github – Published: 2026-04-16 06:31 – Updated: 2026-04-16 06:31The Riaxe Product Customizer plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.1.2. The plugin registers an unauthenticated AJAX action ('wp_ajax_nopriv_install-imprint') that maps to the ink_pd_add_option() function. This function reads 'option' and 'opt_value' from $_POST, then calls delete_option() followed by add_option() using these attacker-controlled values without any nonce verification, capability checks, or option name allowlist. This makes it possible for unauthenticated attackers to update arbitrary WordPress options, which can be leveraged for privilege escalation by enabling user registration and setting the default user role to administrator.
{
"affected": [],
"aliases": [
"CVE-2026-3596"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-16T06:16:15Z",
"severity": "CRITICAL"
},
"details": "The Riaxe Product Customizer plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.1.2. The plugin registers an unauthenticated AJAX action (\u0027wp_ajax_nopriv_install-imprint\u0027) that maps to the ink_pd_add_option() function. This function reads \u0027option\u0027 and \u0027opt_value\u0027 from $_POST, then calls delete_option() followed by add_option() using these attacker-controlled values without any nonce verification, capability checks, or option name allowlist. This makes it possible for unauthenticated attackers to update arbitrary WordPress options, which can be leveraged for privilege escalation by enabling user registration and setting the default user role to administrator.",
"id": "GHSA-6cjg-w4wg-37mh",
"modified": "2026-04-16T06:31:23Z",
"published": "2026-04-16T06:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3596"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L183"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L5045"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L5046"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L5047"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/tags/2.1.2/riaxe-product-designer.php#L5058"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L183"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L5045"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L5046"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L5047"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/riaxe-product-customizer/trunk/riaxe-product-designer.php#L5058"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/271a35fb-56b7-4d6b-bccc-fea1227d0913?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6CP7-C5X9-2WH3
Vulnerability from github – Published: 2026-03-16 18:32 – Updated: 2026-04-01 18:36Missing Authorization vulnerability in Saad Iqbal WP EasyPay allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP EasyPay: from n/a through 4.2.11.
{
"affected": [],
"aliases": [
"CVE-2026-32587"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T16:16:15Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Saad Iqbal WP EasyPay allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP EasyPay: from n/a through 4.2.11.",
"id": "GHSA-6cp7-c5x9-2wh3",
"modified": "2026-04-01T18:36:32Z",
"published": "2026-03-16T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32587"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-easy-pay/vulnerability/wordpress-wp-easypay-plugin-4-2-11-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-6CQC-V7X2-3R77
Vulnerability from github – Published: 2025-11-21 15:31 – Updated: 2025-11-21 15:31The ELEX WordPress HelpDesk & Customer Ticketing System plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'eh_crm_remove_agent' function in all versions up to, and including, 3.3.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to remove the role and capabilities of any user with an Administrator, WSDesk Supervisor, or WSDesk Agents role.
{
"affected": [],
"aliases": [
"CVE-2025-10054"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-21T13:15:45Z",
"severity": "MODERATE"
},
"details": "The ELEX WordPress HelpDesk \u0026 Customer Ticketing System plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the \u0027eh_crm_remove_agent\u0027 function in all versions up to, and including, 3.3.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to remove the role and capabilities of any user with an Administrator, WSDesk Supervisor, or WSDesk Agents role.",
"id": "GHSA-6cqc-v7x2-3r77",
"modified": "2025-11-21T15:31:25Z",
"published": "2025-11-21T15:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10054"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/elex-helpdesk-customer-support-ticket-system/trunk/includes/class-crm-ajax-functions-two.php#L77"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3399391"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/07c92f79-94ac-4153-9ab2-9608601508b0?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-6CQF-375W-639G
Vulnerability from github – Published: 2026-07-21 20:40 – Updated: 2026-07-21 20:40Summary
Gitea's RSS/Atom feed handlers accept API-token Basic auth but perform no token-scope or
public-only enforcement. A personal access token that is correctly blocked (HTTP 403) from a
private repository on /raw, /media, /archive, and /releases/download/... — because it is
marked public-only or lacks the repository scope category — still returns that repository's
private content through the feed routes. This is a token-confinement bypass and appears to be an
incomplete fix of #37698, which added that scope enforcement to the download handlers but not to the
sibling feed handlers.
This is not a cross-user access bug: the requesting account must still legitimately have repo
read access (RepoAssignment + reqUnitCodeReader are enforced). What is bypassed is the guarantee
that a confined token cannot reach private content — which is exactly the property #37698 was
shipped to provide for downloads, and which matters when such a token is handed to a third-party
service/CI, leaked, or used in a lower-trust integration.
Details
37698 added context.CheckTokenScopes / CheckRepoScopedToken
(services/context/permission.go) to the raw / media / archive / attachment download handlers, so a
public-only or wrong-scope-category token cannot read private-repo content even when the owning user
otherwise has access.
The feed handlers are registered with webAuth.AllowBasic (so they accept token Basic auth) but call
no scope / public-only check. A grep for CheckTokenScopes / CheckRepoScopedToken / IsApiToken
across routers/web/feed/ and the release feed handlers returns nothing.
Affected routes (all token-reachable via webAuth.AllowBasic, none call the scope check):
| Route | Handler | Private data exposed |
|---|---|---|
GET /{owner}/{repo}.rss / .atom |
repo.Home → handleRepoHomeFeed (view_home.go) |
last-10 commits: SHA, full message, author name + email |
GET /{owner}/{repo}/rss/branch/*, /atom/branch/* |
feed.RenderBranchFeed* → ShowBranchFeed (routers/web/feed/branch.go) |
same commit data, any branch |
GET /{owner}/{repo}/releases.rss / .atom |
ReleasesFeedRSS/Atom (routers/web/repo/release.go) → ShowReleaseFeed |
private release names, notes, descriptions |
GET /{owner}/{repo}/tags.rss / .atom |
TagsListFeedRSS/Atom → ShowReleaseFeed |
private tag names + messages |
GET /{user}.rss / .atom |
showUserFeed (routers/web/feed/profile.go), includePrivate = self \|\| admin |
the token owner's private cross-repo activity stream |
Inconsistency that pins this down: the branch-feed routes sit in the same route group as /raw,
/media, /archive (all of which call checkDownloadTokenScope), and releases.rss sits next to
/releases/attachments/{uuid} and /releases/download/... (both go through ServeAttachment → scope
check). Only the feeds were missed. The API equivalents (ListReleases / ListTags) are scope-gated
via tokenRequiresScopes.
Two distinct confinement bypasses:
- Public-only bypass. A token created with the public-only option is blocked (403) from a
private repo on
/raw,/archive,/releases/download/..., but returns private commit / release data via.../releases.rss,.../rss/branch/*,/{owner}/{repo}.rss, and the owner's private activity via/{user}.rss. - Scope-category bypass. A token scoped to only e.g.
read:issue(noread:repository) is rejected by the download handlers but reads repository commit/release content via the feeds.
PoC
Verified live against the official gitea/gitea:1.26.2 Docker image (sqlite, feeds enabled).
Setup: non-admin user alice; private repo alice/secret with a commit
"SECRET-COMMIT-MARKER ..." (file secret.txt) and a release "Private Release" / body
"SECRET-RELEASE-MARKER ...". Two confined personal access tokens, both sent via HTTP Basic so the
auth method is identical across download and feed — only the route differs:
- Token A: scopes ["public-only", "read:repository"]
- Token B: scopes ["read:issue"]
# Token A — download is correctly blocked, feeds leak private content:
curl -u alice:$TOKEN_A https://<host>/alice/secret/raw/branch/main/secret.txt # => 403 (fix works)
curl -u alice:$TOKEN_A https://<host>/alice/secret/rss/branch/main # => 200, <title>SECRET-COMMIT-MARKER ...</title>
curl -u alice:$TOKEN_A https://<host>/alice/secret/releases.rss # => 200, SECRET-RELEASE-MARKER ...
curl -u alice:$TOKEN_A "https://<host>/alice.rss" # => 200, private activity
# Token B — wrong scope category, same split:
curl -u alice:$TOKEN_B https://<host>/alice/secret/raw/branch/main/secret.txt # => 403
curl -u alice:$TOKEN_B https://<host>/alice/secret/rss/branch/main # => 200, private commit leaked
Anonymous baseline returns 404 on the repo feeds (data is genuinely private) and a marker-free 200 on
/alice.rss (public activity only) — confirming the leak is gated only by the missing token check.
Impact
Information disclosure of private commit metadata (SHA, message, author name+email), release/tag notes, and the owner's private activity stream, to the holder of a confined token that was specifically configured not to reach private content. Not raw file blobs (feeds don't serve file contents). Requires a token belonging to an account that already has repo read access, so the realistic threat is a leaked / shared / lower-trust token rather than an anonymous attacker — which is precisely the threat model #37698 addressed for downloads.
Suggested remediation
Add a token-scope check at the top of each feed handler, mirroring checkDownloadTokenScope:
if context.CheckRepoScopedToken(ctx, ctx.Repo.Repository, auth_model.Read); ctx.Written() {
return
}
for ShowBranchFeed, ShowRepoFeed, ShowFileFeed, ShowReleaseFeed (repo feeds). For the user
feed, gate includePrivate behind a non-public-only token (or require the user / repository
scope) so a confined token can't pull private activity.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50105"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:40:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nGitea\u0027s RSS/Atom feed handlers accept API-token Basic auth but perform **no token-scope or\npublic-only enforcement**. A personal access token that is correctly blocked (HTTP 403) from a\nprivate repository on `/raw`, `/media`, `/archive`, and `/releases/download/...` \u2014 because it is\nmarked *public-only* or lacks the `repository` scope category \u2014 still returns that repository\u0027s\nprivate content through the feed routes. This is a token-confinement bypass and appears to be an\nincomplete fix of #37698, which added that scope enforcement to the download handlers but not to the\nsibling feed handlers.\n\nThis is **not** a cross-user access bug: the requesting account must still legitimately have repo\nread access (`RepoAssignment` + `reqUnitCodeReader` are enforced). What is bypassed is the guarantee\nthat a *confined* token cannot reach private content \u2014 which is exactly the property #37698 was\nshipped to provide for downloads, and which matters when such a token is handed to a third-party\nservice/CI, leaked, or used in a lower-trust integration.\n\n### Details\n\n#37698 added `context.CheckTokenScopes` / `CheckRepoScopedToken`\n(`services/context/permission.go`) to the raw / media / archive / attachment download handlers, so a\npublic-only or wrong-scope-category token cannot read private-repo content even when the owning user\notherwise has access.\n\nThe feed handlers are registered with `webAuth.AllowBasic` (so they accept token Basic auth) but call\nno scope / public-only check. A grep for `CheckTokenScopes` / `CheckRepoScopedToken` / `IsApiToken`\nacross `routers/web/feed/` and the release feed handlers returns nothing.\n\nAffected routes (all token-reachable via `webAuth.AllowBasic`, none call the scope check):\n\n| Route | Handler | Private data exposed |\n|---|---|---|\n| `GET /{owner}/{repo}.rss` / `.atom` | `repo.Home` \u2192 `handleRepoHomeFeed` (`view_home.go`) | last-10 commits: SHA, full message, author name + email |\n| `GET /{owner}/{repo}/rss/branch/*`, `/atom/branch/*` | `feed.RenderBranchFeed*` \u2192 `ShowBranchFeed` (`routers/web/feed/branch.go`) | same commit data, any branch |\n| `GET /{owner}/{repo}/releases.rss` / `.atom` | `ReleasesFeedRSS/Atom` (`routers/web/repo/release.go`) \u2192 `ShowReleaseFeed` | private release names, notes, descriptions |\n| `GET /{owner}/{repo}/tags.rss` / `.atom` | `TagsListFeedRSS/Atom` \u2192 `ShowReleaseFeed` | private tag names + messages |\n| `GET /{user}.rss` / `.atom` | `showUserFeed` (`routers/web/feed/profile.go`), `includePrivate = self \\|\\| admin` | the token owner\u0027s private cross-repo activity stream |\n\nInconsistency that pins this down: the branch-feed routes sit in the **same route group** as `/raw`,\n`/media`, `/archive` (all of which call `checkDownloadTokenScope`), and `releases.rss` sits next to\n`/releases/attachments/{uuid}` and `/releases/download/...` (both go through `ServeAttachment` \u2192 scope\ncheck). Only the feeds were missed. The API equivalents (`ListReleases` / `ListTags`) are scope-gated\nvia `tokenRequiresScopes`.\n\nTwo distinct confinement bypasses:\n\n1. **Public-only bypass.** A token created with the *public-only* option is blocked (403) from a\n private repo on `/raw`, `/archive`, `/releases/download/...`, but returns private commit / release\n data via `.../releases.rss`, `.../rss/branch/*`, `/{owner}/{repo}.rss`, and the owner\u0027s private\n activity via `/{user}.rss`.\n2. **Scope-category bypass.** A token scoped to only e.g. `read:issue` (no `read:repository`) is\n rejected by the download handlers but reads repository commit/release content via the feeds.\n\n### PoC\n\nVerified live against the official `gitea/gitea:1.26.2` Docker image (sqlite, feeds enabled).\n\nSetup: non-admin user `alice`; private repo `alice/secret` with a commit\n`\"SECRET-COMMIT-MARKER ...\"` (file `secret.txt`) and a release `\"Private Release\"` / body\n`\"SECRET-RELEASE-MARKER ...\"`. Two confined personal access tokens, both sent via HTTP Basic so the\nauth method is identical across download and feed \u2014 only the route differs:\n- Token A: scopes `[\"public-only\", \"read:repository\"]`\n- Token B: scopes `[\"read:issue\"]`\n\n```bash\n# Token A \u2014 download is correctly blocked, feeds leak private content:\ncurl -u alice:$TOKEN_A https://\u003chost\u003e/alice/secret/raw/branch/main/secret.txt # =\u003e 403 (fix works)\ncurl -u alice:$TOKEN_A https://\u003chost\u003e/alice/secret/rss/branch/main # =\u003e 200, \u003ctitle\u003eSECRET-COMMIT-MARKER ...\u003c/title\u003e\ncurl -u alice:$TOKEN_A https://\u003chost\u003e/alice/secret/releases.rss # =\u003e 200, SECRET-RELEASE-MARKER ...\ncurl -u alice:$TOKEN_A \"https://\u003chost\u003e/alice.rss\" # =\u003e 200, private activity\n\n# Token B \u2014 wrong scope category, same split:\ncurl -u alice:$TOKEN_B https://\u003chost\u003e/alice/secret/raw/branch/main/secret.txt # =\u003e 403\ncurl -u alice:$TOKEN_B https://\u003chost\u003e/alice/secret/rss/branch/main # =\u003e 200, private commit leaked\n```\n\nAnonymous baseline returns 404 on the repo feeds (data is genuinely private) and a marker-free 200 on\n`/alice.rss` (public activity only) \u2014 confirming the leak is gated only by the missing token check.\n\n### Impact\n\nInformation disclosure of private **commit metadata** (SHA, message, author name+email),\n**release/tag notes**, and the owner\u0027s **private activity stream**, to the holder of a confined token\nthat was specifically configured *not* to reach private content. Not raw file blobs (feeds don\u0027t\nserve file contents). Requires a token belonging to an account that already has repo read access, so\nthe realistic threat is a leaked / shared / lower-trust token rather than an anonymous attacker \u2014\nwhich is precisely the threat model #37698 addressed for downloads.\n\n### Suggested remediation\n\nAdd a token-scope check at the top of each feed handler, mirroring `checkDownloadTokenScope`:\n\n```go\nif context.CheckRepoScopedToken(ctx, ctx.Repo.Repository, auth_model.Read); ctx.Written() {\n return\n}\n```\n\nfor `ShowBranchFeed`, `ShowRepoFeed`, `ShowFileFeed`, `ShowReleaseFeed` (repo feeds). For the user\nfeed, gate `includePrivate` behind a non-public-only token (or require the `user` / `repository`\nscope) so a confined token can\u0027t pull private activity.",
"id": "GHSA-6cqf-375w-639g",
"modified": "2026-07-21T20:40:24Z",
"published": "2026-07-21T20:40:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-6cqf-375w-639g"
},
{
"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:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea: RSS/Atom feed handlers bypass API-token scope \u0026 public-only confinement (incomplete fix of #37698)"
}
GHSA-6CRM-V898-7XX4
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-07 18:30In power management service, there is a missing permission check. This could lead to set up power management service with no additional execution privileges needed.
{
"affected": [],
"aliases": [
"CVE-2022-39102"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "HIGH"
},
"details": "In power management service, there is a missing permission check. This could lead to set up power management service with no additional execution privileges needed.",
"id": "GHSA-6crm-v898-7xx4",
"modified": "2022-12-07T18:30:27Z",
"published": "2022-12-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39102"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1610118225591336001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6CWP-PXJ6-56C7
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2024-04-04 01:25It was discovered that libvirtd before versions 4.10.1 and 5.4.1 would permit read-only clients to use the virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which would be accessed with the permissions of the libvirtd process. An attacker with access to the libvirtd socket could use this to probe the existence of arbitrary files, cause denial of service or cause libvirtd to execute arbitrary programs.
{
"affected": [],
"aliases": [
"CVE-2019-10161"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-30T23:15:00Z",
"severity": "HIGH"
},
"details": "It was discovered that libvirtd before versions 4.10.1 and 5.4.1 would permit read-only clients to use the virDomainSaveImageGetXMLDesc() API, specifying an arbitrary path which would be accessed with the permissions of the libvirtd process. An attacker with access to the libvirtd socket could use this to probe the existence of arbitrary files, cause denial of service or cause libvirtd to execute arbitrary programs.",
"id": "GHSA-6cwp-pxj6-56c7",
"modified": "2024-04-04T01:25:16Z",
"published": "2022-05-24T16:51:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10161"
},
{
"type": "WEB",
"url": "https://access.redhat.com/libvirt-privesc-vulnerabilities"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10161"
},
{
"type": "WEB",
"url": "https://libvirt.org/git/?p=libvirt.git%3Ba=commit%3Bh=aed6a032cead4386472afb24b16196579e239580"
},
{
"type": "WEB",
"url": "https://libvirt.org/git/?p=libvirt.git;a=commit;h=aed6a032cead4386472afb24b16196579e239580"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202003-18"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4047-2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6CXR-8Q3M-JWRR
Vulnerability from github – Published: 2023-11-16 21:30 – Updated: 2025-01-09 23:39LFI in Ray's /static/ directory allows attackers to read any file on the server without authentication. The issue is fixed in version 2.8.1+. Ray maintainers response can be found here: https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ray"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-6020"
],
"database_specific": {
"cwe_ids": [
"CWE-598",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-27T23:21:39Z",
"nvd_published_at": "2023-11-16T21:15:09Z",
"severity": "CRITICAL"
},
"details": "LFI in Ray\u0027s /static/ directory allows attackers to read any file on the server without authentication. The issue is fixed in version 2.8.1+. Ray maintainers response can be found here: https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023",
"id": "GHSA-6cxr-8q3m-jwrr",
"modified": "2025-01-09T23:39:13Z",
"published": "2023-11-16T21:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6020"
},
{
"type": "WEB",
"url": "https://github.com/ray-project/ray"
},
{
"type": "WEB",
"url": "https://github.com/ray-project/ray/releases/tag/ray-2.8.1"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/83dd8619-6dc3-4c98-8f1b-e620fedcd1f6"
},
{
"type": "WEB",
"url": "https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ray Missing Authorization vulnerability"
}
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.