CWE-862
Weakness 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.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
19823 vulnerabilities reference this CWE, most recent first.
GHSA-6CM8-G463-WR86
Vulnerability from github – Published: 2026-10-13 21:33 – Updated: 2026-10-13 21:33youlai-boot through 2.21.1 contains a missing authorization vulnerability that allows any authenticated user to enable or disable accounts because the updateUserStatus handler lacks a @PreAuthorize check. Attackers can send PATCH requests to /api/v1/users/{userId}/status to disable root or admin accounts, locking administrators out, or re-enable accounts an administrator has disabled.
{
"affected": [],
"aliases": [
"CVE-2026-110216"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-13T19:18:45Z",
"severity": "HIGH"
},
"details": "youlai-boot through 2.21.1 contains a missing authorization vulnerability that allows any authenticated user to enable or disable accounts because the updateUserStatus handler lacks a @PreAuthorize check. Attackers can send PATCH requests to /api/v1/users/{userId}/status to disable root or admin accounts, locking administrators out, or re-enable accounts an administrator has disabled.",
"id": "GHSA-6cm8-g463-wr86",
"modified": "2026-10-13T21:33:37Z",
"published": "2026-10-13T21:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-110216"
},
{
"type": "WEB",
"url": "https://github.com/youlaitech/youlai-boot/commit/86a9b3e212ff5a5537b0c7050c7802aea7fe486f"
},
{
"type": "WEB",
"url": "https://github.com/youlaitech/youlai-boot/blob/v2.21.1/src/main/java/com/youlai/boot/system/controller/UserController.java#L114-L126"
},
{
"type": "WEB",
"url": "https://hackmd.io/@1ExmmukzRMWN7B4gQ4W-4Q/youlai-boot-role-menu-assignment-and-user-status-missing-authorization"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/youlai-boot-through-2.21.1-missing-authorization-in-user-status-update-endpoint"
}
],
"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:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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-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-6CQ6-3JWX-45WQ
Vulnerability from github – Published: 2026-08-31 09:30 – Updated: 2026-08-31 09:30ToolJet before v3.16.208 fails to validate organization membership in database read routes, allowing any authenticated user to access other organizations' table schemas and row data. Attackers can supply arbitrary organization IDs in URL parameters to list tables, retrieve column definitions, and execute join queries to read actual stored data from victim organizations.
{
"affected": [],
"aliases": [
"CVE-2026-82871"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-31T09:17:08Z",
"severity": "HIGH"
},
"details": "ToolJet before v3.16.208 fails to validate organization membership in database read routes, allowing any authenticated user to access other organizations\u0027 table schemas and row data. Attackers can supply arbitrary organization IDs in URL parameters to list tables, retrieve column definitions, and execute join queries to read actual stored data from victim organizations.",
"id": "GHSA-6cq6-3jwx-45wq",
"modified": "2026-08-31T09:30:33Z",
"published": "2026-08-31T09:30:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ToolJet/ToolJet/security/advisories/GHSA-xqqj-pfc2-vf48"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82871"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/tooljet-before-3.16.208-cross-organization-data-read-via-database-routes"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/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-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-6CWC-727Q-R97H
Vulnerability from github – Published: 2026-10-19 09:32 – Updated: 2026-10-19 09:32The TrueBooker WordPress plugin before 1.3.0 does not have authorisation checks in place in some of its functionality, allowing unauthenticated users to create and modify booking services and categories, including their prices.
{
"affected": [],
"aliases": [
"CVE-2026-94231"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-19T07:16:32Z",
"severity": "MODERATE"
},
"details": "The TrueBooker WordPress plugin before 1.3.0 does not have authorisation checks in place in some of its functionality, allowing unauthenticated users to create and modify booking services and categories, including their prices.",
"id": "GHSA-6cwc-727q-r97h",
"modified": "2026-10-19T09:32:30Z",
"published": "2026-10-19T09:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94231"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/d90ad3f4-4d58-43bc-8f17-0f6b8dfdde4f"
}
],
"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-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"
}
GHSA-6F29-2QG2-88XX
Vulnerability from github – Published: 2026-09-14 21:31 – Updated: 2026-09-17 15:31This issue was addressed with additional entitlement checks. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to modify protected parts of the file system.
{
"affected": [],
"aliases": [
"CVE-2026-84514"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T21:17:27Z",
"severity": "MODERATE"
},
"details": "This issue was addressed with additional entitlement checks. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to modify protected parts of the file system.",
"id": "GHSA-6f29-2qg2-88xx",
"modified": "2026-09-17T15:31:36Z",
"published": "2026-09-14T21:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84514"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149035"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149042"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149043"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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.