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
20196 vulnerabilities reference this CWE, most recent first.
GHSA-P9CP-6FFG-FQQC
Vulnerability from github – Published: 2024-12-31 12:30 – Updated: 2026-04-01 18:32Missing Authorization vulnerability in VW THEMES VW Automobile Lite allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects VW Automobile Lite: from n/a through 2.1.
{
"affected": [],
"aliases": [
"CVE-2024-56234"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-31T11:15:09Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in VW THEMES VW Automobile Lite allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects VW Automobile Lite: from n/a through 2.1.",
"id": "GHSA-p9cp-6ffg-fqqc",
"modified": "2026-04-01T18:32:53Z",
"published": "2024-12-31T12:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56234"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/theme/vw-automobile-lite/vulnerability/wordpress-vw-automobile-lite-theme-2-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:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-P9CQ-JF42-732X
Vulnerability from github – Published: 2026-10-11 00:31 – Updated: 2026-10-11 00:31JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows any authenticated user to read MCP server configurations because the queryById permission check is commented out. Attackers can obtain record ids from the unguarded /airag/app/queryById endpoint and retrieve MCP endpoint URLs, headers, and outbound authentication tokens.
{
"affected": [],
"aliases": [
"CVE-2026-108671"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-10T22:16:43Z",
"severity": "HIGH"
},
"details": "JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows any authenticated user to read MCP server configurations because the queryById permission check is commented out. Attackers can obtain record ids from the unguarded /airag/app/queryById endpoint and retrieve MCP endpoint URLs, headers, and outbound authentication tokens.",
"id": "GHSA-p9cq-jf42-732x",
"modified": "2026-10-11T00:31:00Z",
"published": "2026-10-11T00:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108671"
},
{
"type": "WEB",
"url": "https://github.com/AnkesKasty/cve-request-poc/blob/a7b6d1423555812d8efa26c91c5d0683164b31e5/JeecgBoot/poc_airag_mcp_model_and_writer.py"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/blob/e3b9dc0aefe1943d9772b026f64ed671a7c82802/jeecg-boot/jeecg-boot-module/jeecg-boot-module-airag/src/main/java/org/jeecg/modules/airag/llm/controller/AiragMcpController.java#L164-L173"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/jeecgboot-through-3.9.5-missing-authorization-via-airag-airagmcp-querybyid"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/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-P9F5-H3RX-J5QW
Vulnerability from github – Published: 2026-06-22 23:59 – Updated: 2026-07-21 13:36Summary
In Gogs 0.14.1, GET /attachments/:uuid returns the raw attachment file without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository.
In a test environment with REQUIRE_SIGNIN_VIEW = false, we confirmed that an unauthenticated user can download attachments belonging to a private repository.
Description
/attachments/:uuid retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file without performing any authorization checks against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known.
Relevant code (internal/cmd/web.go:306):
m.Get("/attachments/:uuid", func(c *context.Context) {
attach, err := database.GetAttachmentByUUID(c.Params(":uuid"))
if err != nil {
c.NotFoundOrError(err, "get attachment by UUID")
return
} else if !com.IsFile(attach.LocalPath()) {
c.NotFound()
return
}
fr, err := os.Open(attach.LocalPath())
if err != nil {
c.Error(err, "open attachment file")
return
}
defer fr.Close()
c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox")
c.Header().Set("Cache-Control", "public,max-age=86400")
c.Header().Set("Content-Disposition", fmt.Sprintf(`inline; filename="%s"`, attach.Name))
if _, err = io.Copy(c.Resp, fr); err != nil {
c.Error(err, "copy from file to response")
return
}
})
The UUID lookup itself also performs no validation tied to repository visibility or user permissions. Authorization is not enforced at this layer.
Relevant code (internal/database/attachment.go:124):
// GetAttachmentByUUID returns attachment by given UUID.
func GetAttachmentByUUID(uuid string) (*Attachment, error) {
return getAttachmentByUUID(x, uuid)
}
Preconditions
- The attacker knows the target attachment’s UUID (i.e., the attachment URL).
- For unauthenticated exploitation:
[auth] REQUIRE_SIGNIN_VIEW = false. - Even when
REQUIRE_SIGNIN_VIEW = true, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment.
Steps to Reproduce
- Log in as an administrator and create a private repository, e.g.
myadmin/idor-attach-1770724346-1a13bb. - Add an attachment to an Issue in that repository and note the attachment UUID
(example UUID used during testing:
f06d90f8-5b62-4c10-ac8d-f11fdf870b57). -
Log out and access the following as an unauthenticated user:
-
The repository page → 404 Not Found
-
The Issue page under that repository → 404 Not Found
-
GET /attachments/<uuid>→ the attachment file is successfully downloaded
Minimum Required Privileges
REQUIRE_SIGNIN_VIEW = false: none (works without authentication).REQUIRE_SIGNIN_VIEW = true: only the ability to log in (repository view permission is not required in practice).
Impact
-
Confidential information attached to private repositories or restricted Issues/Releases may be disclosed.
-
Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments.
- While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.14.2"
},
"package": {
"ecosystem": "Go",
"name": "gogs.io/gogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52799"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T23:59:03Z",
"nvd_published_at": "2026-06-24T21:16:55Z",
"severity": "HIGH"
},
"details": "## Summary\n\nIn Gogs 0.14.1, `GET /attachments/:uuid` returns the raw attachment file **without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository**.\nIn a test environment with `REQUIRE_SIGNIN_VIEW = false`, we confirmed that **an unauthenticated user can download attachments belonging to a private repository**.\n\n## Description\n\n`/attachments/:uuid` retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file **without performing any authorization checks** against the attachment\u2019s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known.\n\nRelevant code (internal/cmd/web.go:306):\n\n```go\nm.Get(\"/attachments/:uuid\", func(c *context.Context) {\n\tattach, err := database.GetAttachmentByUUID(c.Params(\":uuid\"))\n\tif err != nil {\n\t\tc.NotFoundOrError(err, \"get attachment by UUID\")\n\t\treturn\n\t} else if !com.IsFile(attach.LocalPath()) {\n\t\tc.NotFound()\n\t\treturn\n\t}\n\n\tfr, err := os.Open(attach.LocalPath())\n\tif err != nil {\n\t\tc.Error(err, \"open attachment file\")\n\t\treturn\n\t}\n\tdefer fr.Close()\n\n\tc.Header().Set(\"Content-Security-Policy\", \"default-src \u0027none\u0027; style-src \u0027unsafe-inline\u0027; sandbox\")\n\tc.Header().Set(\"Cache-Control\", \"public,max-age=86400\")\n\tc.Header().Set(\"Content-Disposition\", fmt.Sprintf(`inline; filename=\"%s\"`, attach.Name))\n\n\tif _, err = io.Copy(c.Resp, fr); err != nil {\n\t\tc.Error(err, \"copy from file to response\")\n\t\treturn\n\t}\n})\n```\n\nThe UUID lookup itself also performs **no validation tied to repository visibility or user permissions**. Authorization is not enforced at this layer.\n\nRelevant code (internal/database/attachment.go:124):\n\n```go\n// GetAttachmentByUUID returns attachment by given UUID.\nfunc GetAttachmentByUUID(uuid string) (*Attachment, error) {\n\treturn getAttachmentByUUID(x, uuid)\n}\n```\n\n## Preconditions\n\n* The attacker knows the target attachment\u2019s UUID (i.e., the attachment URL).\n* For unauthenticated exploitation: `[auth] REQUIRE_SIGNIN_VIEW = false`.\n* Even when `REQUIRE_SIGNIN_VIEW = true`, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment.\n\n## Steps to Reproduce\n\n1. Log in as an administrator and create a private repository, e.g. `myadmin/idor-attach-1770724346-1a13bb`.\n2. Add an attachment to an Issue in that repository and note the attachment UUID\n (example UUID used during testing: `f06d90f8-5b62-4c10-ac8d-f11fdf870b57`).\n3. Log out and access the following as an unauthenticated user:\n\n* The repository page \u2192 404 Not Found\n\u003cimg width=\"1702\" height=\"758\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8fdb1d92-cfc3-4ef8-977e-60ec13f792df\" /\u003e\n\n* The Issue page under that repository \u2192 404 Not Found\n\u003cimg width=\"1983\" height=\"546\" alt=\"image\" src=\"https://github.com/user-attachments/assets/c44c5e69-8ca2-4ea6-a071-62302b7e896f\" /\u003e\n\n* `GET /attachments/\u003cuuid\u003e` \u2192 **the attachment file is successfully downloaded**\n\u003cimg width=\"2007\" height=\"378\" alt=\"image\" src=\"https://github.com/user-attachments/assets/23950ac6-6b3a-42f8-a06b-b9e0cf508d24\" /\u003e\n\n\n\n## Minimum Required Privileges\n\n* `REQUIRE_SIGNIN_VIEW = false`: none (works without authentication).\n* `REQUIRE_SIGNIN_VIEW = true`: only the ability to log in (repository view permission is not required in practice).\n\n## Impact\n\n* Confidential information attached to private repositories or restricted Issues/Releases may be disclosed.\n\n * Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments.\n* While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.",
"id": "GHSA-p9f5-h3rx-j5qw",
"modified": "2026-07-21T13:36:58Z",
"published": "2026-06-22T23:59:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/security/advisories/GHSA-p9f5-h3rx-j5qw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52799"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/pull/8320"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/commit/d3ca23f9f33d5710472a775d6dcd3a7bb128bb05"
},
{
"type": "PACKAGE",
"url": "https://github.com/gogs/gogs"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
}
],
"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"
}
],
"summary": "Gogs Missing Authorization in Attachment Download"
}
GHSA-P9F7-Q656-992Q
Vulnerability from github – Published: 2026-11-06 06:30 – Updated: 2026-11-06 18:35A flaw was found in the SAML brokering component of Keycloak, an identity and access management solution. The issue occurs when Keycloak acts as an intermediary between an upstream identity provider and downstream services. Keycloak fails to respect specific security instructions called ProxyRestrictions in the login messages it receives. This allows a user to log into downstream services even when the original identity provider explicitly forbade further sharing of the login session. As a result, users can bypass security boundaries intended to limit where their identity can be used.
{
"affected": [],
"aliases": [
"CVE-2026-92856"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-06T06:16:44Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the SAML brokering component of Keycloak, an identity and access management solution. The issue occurs when Keycloak acts as an intermediary between an upstream identity provider and downstream services. Keycloak fails to respect specific security instructions called ProxyRestrictions in the login messages it receives. This allows a user to log into downstream services even when the original identity provider explicitly forbade further sharing of the login session. As a result, users can bypass security boundaries intended to limit where their identity can be used.",
"id": "GHSA-p9f7-q656-992q",
"modified": "2026-11-06T18:35:08Z",
"published": "2026-11-06T06:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92856"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:95761"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:95762"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-92856"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2535815"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P9GP-6WP2-9V5C
Vulnerability from github – Published: 2024-03-29 15:30 – Updated: 2026-04-01 18:31Missing Authorization vulnerability in Andy Moyle Church Admin.This issue affects Church Admin: from n/a through 4.1.18.
{
"affected": [],
"aliases": [
"CVE-2024-30505"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-29T15:15:13Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Andy Moyle Church Admin.This issue affects Church Admin: from n/a through 4.1.18.",
"id": "GHSA-p9gp-6wp2-9v5c",
"modified": "2026-04-01T18:31:44Z",
"published": "2024-03-29T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30505"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/church-admin/vulnerability/wordpress-church-admin-plugin-4-1-18-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/church-admin/wordpress-church-admin-plugin-4-1-18-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-P9GQ-76FJ-4P4P
Vulnerability from github – Published: 2022-03-16 00:00 – Updated: 2022-11-30 18:57A missing permission check in Jenkins Release Helper Plugin 1.3.3 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:release-helper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-27215"
],
"database_specific": {
"cwe_ids": [
"CWE-281",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-30T18:57:22Z",
"nvd_published_at": "2022-03-15T17:15:00Z",
"severity": "MODERATE"
},
"details": "A missing permission check in Jenkins Release Helper Plugin 1.3.3 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.",
"id": "GHSA-p9gq-76fj-4p4p",
"modified": "2022-11-30T18:57:22Z",
"published": "2022-03-16T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27215"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/release-helper-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-03-15/#SECURITY-2274"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/03/15/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Missing permission checks in Jenkins Release Helper Plugin"
}
GHSA-P9JH-4PX8-QM49
Vulnerability from github – Published: 2023-05-09 03:30 – Updated: 2024-04-04 03:53In soter service, there is a possible missing permission check. This could lead to local denial of service with no additional execution privileges.
{
"affected": [],
"aliases": [
"CVE-2022-47492"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-09T02:15:09Z",
"severity": "MODERATE"
},
"details": "In soter service, there is a possible missing permission check. This could lead to local denial of service with no additional execution privileges.",
"id": "GHSA-p9jh-4px8-qm49",
"modified": "2024-04-04T03:53:38Z",
"published": "2023-05-09T03:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47492"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1654776866982133761"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P9MG-74MG-CWWR
Vulnerability from github – Published: 2026-05-08 23:01 – Updated: 2026-06-08 23:48Summary
free5GC's SMF mounts the UPI management route group without inbound OAuth2 middleware (same root cause as the broader UPI auth gap reported in free5gc/free5gc#887). On top of that, the DELETE /upi/v1/upNodesLinks/{upNodeRef} handler unconditionally dereferences upNode.UPF after the type-guarded async release, even though AN-typed nodes are constructed without a UPF object. As a result, a single unauthenticated DELETE /upi/v1/upNodesLinks/gNB1 request crashes the handler with a nil-pointer panic AND mutates the in-memory user-plane topology before panicking (the UpNodeDelete(upNodeRef) line runs first). This is an unauthenticated, state-mutating panic-DoS sink that an off-path network attacker can trigger by name against any AN entry.
Details
Validated against the SMF container in the official Docker compose lab.
- Source repo tag: v4.2.1
- Running Docker image: free5gc/smf:v4.2.1
- Runtime SMF commit: 8385c00a
- Docker validation date: 2026-03-22 local (container log timestamp 2026-03-21T23:43:17Z)
- SMF endpoint: http://10.100.200.6:8000
Control comparison on the same SMF instance:
- GET /nsmf-oam/v1/ (no token) -> 401 Unauthorized
- DELETE /upi/v1/upNodesLinks/gNB1 (no token) -> 500 Internal Server Error (panic)
The sibling nsmf-oam returning 401 proves OAuth middleware IS wired in for other SMF route groups; the UPI group specifically is mounted without it.
Vulnerable handler logic (paths in free5gc/smf):
// NFs/smf/internal/sbi/api_upi.go:94..99
if upNode.Type == smf_context.UPNODE_UPF {
go s.Processor().ReleaseAllResourcesOfUPF(upNode.UPF)
}
upi.UpNodeDelete(upNodeRef)
upNode.UPF.CancelAssociation() // <-- panics for AN-typed nodes; nil UPF
The Type == UPNODE_UPF guard only protects the asynchronous ReleaseAllResourcesOfUPF call. After that, UpNodeDelete(upNodeRef) runs unconditionally (so the topology mutation lands first), and then upNode.UPF.CancelAssociation() is called unconditionally on a *UPF that is nil for AN nodes by construction.
Code evidence:
- UPI group mounted WITHOUT auth middleware:
- NFs/smf/internal/sbi/server.go:76
- NFs/smf/internal/sbi/server.go:78
- Protected control comparison (other SMF groups DO use auth):
- NFs/smf/internal/sbi/server.go:99
- NFs/smf/internal/sbi/server.go:105
- Delete handler (panic site):
- NFs/smf/internal/sbi/api_upi.go:94
- NFs/smf/internal/sbi/api_upi.go:99
- AN nodes are constructed without a UPF object (root cause of the nil deref):
- NFs/smf/internal/context/user_plane_information.go:95
- NFs/smf/internal/context/user_plane_information.go:97
PoC
Reproduced end-to-end against the running SMF at http://10.100.200.6:8000.
- Control: protected sibling OAM route returns
401:
curl -i http://10.100.200.6:8000/nsmf-oam/v1/
HTTP/1.1 401 Unauthorized
- Trigger: unauthenticated DELETE on the default AN node
gNB1:
curl -i -X DELETE http://10.100.200.6:8000/upi/v1/upNodesLinks/gNB1
HTTP/1.1 500 Internal Server Error
- SMF container logs (
docker logs --tail 120 smf) show topology mutation landing BEFORE the panic, and the panic stack pointing atapi_upi.go:99:
[INFO][SMF][Init] UPNode [gNB1] found. Deleting it.
[INFO][SMF][Init] Delete UPLink [UPF] <=> [gNB1].
[ERRO][SMF][GIN] panic: runtime error: invalid memory address or nil pointer dereference
github.com/free5gc/smf/internal/sbi.(*Server).DeleteUpNodeLink
/go/src/free5gc/NFs/smf/internal/sbi/api_upi.go:99 +0x298
[INFO][SMF][GIN] | 500 | DELETE | /upi/v1/upNodesLinks/gNB1
The lab state was manually restored after validation by re-creating the AN entry; that POST is restoration-only and is NOT a mitigation.
Impact
Three compounding defects on the same SMF SBI surface:
1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the UPI route group, so the trigger is reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no session, no UE state needed. The same-instance nsmf-oam returning 401 proves the middleware is wired in elsewhere and only missing on UPI.
2. NULL pointer dereference (CWE-476) in DeleteUpNodeLink: the Type == UPNODE_UPF guard only covers the async release call, then upNode.UPF.CancelAssociation() runs unconditionally on AN-typed nodes that have a nil UPF field by construction.
3. Order of operations (CWE-755 / CWE-754): UpNodeDelete(upNodeRef) mutates the in-memory user-plane topology BEFORE the dereference panics, so the topology change lands even though the request returns 500. This makes the bug state-mutating, not just a plain panic.
Any party that can reach SMF on the SBI can:
- Delete arbitrary named entries (e.g. gNB1) from SMF's in-memory user-plane topology anonymously via a single DELETE /upi/v1/upNodesLinks/{ref} request, denying SMF's ability to consider that AN/UPF in subsequent UPF selection / PFCP path establishment for legitimate UE sessions.
- Trigger a panic on the SMF goroutine for the deleted-AN case, even though Gin recovers the goroutine, leaving the topology in the mutated state above.
- Repeat the trigger by name against any AN entry, sustaining the topology denial without ever authenticating.
This is a strict superset of the impact in free5gc/free5gc#887 for this specific code path: same auth bypass, plus a concrete request-triggerable nil deref, plus state mutation that survives the panic.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/905 Upstream fix: https://github.com/free5gc/smf/pull/199
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/smf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44328"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-476",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T23:01:56Z",
"nvd_published_at": "2026-05-27T17:16:38Z",
"severity": "HIGH"
},
"details": "### Summary\nfree5GC\u0027s SMF mounts the `UPI` management route group without inbound OAuth2 middleware (same root cause as the broader UPI auth gap reported in free5gc/free5gc#887). On top of that, the `DELETE /upi/v1/upNodesLinks/{upNodeRef}` handler unconditionally dereferences `upNode.UPF` after the type-guarded async release, even though `AN`-typed nodes are constructed without a `UPF` object. As a result, a single unauthenticated `DELETE /upi/v1/upNodesLinks/gNB1` request crashes the handler with a nil-pointer panic AND mutates the in-memory user-plane topology before panicking (the `UpNodeDelete(upNodeRef)` line runs first). This is an unauthenticated, state-mutating panic-DoS sink that an off-path network attacker can trigger by name against any AN entry.\n\n### Details\nValidated against the SMF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/smf:v4.2.1`\n- Runtime SMF commit: `8385c00a`\n- Docker validation date: 2026-03-22 local (container log timestamp `2026-03-21T23:43:17Z`)\n- SMF endpoint: `http://10.100.200.6:8000`\n\nControl comparison on the same SMF instance:\n- `GET /nsmf-oam/v1/` (no token) -\u003e `401 Unauthorized`\n- `DELETE /upi/v1/upNodesLinks/gNB1` (no token) -\u003e `500 Internal Server Error` (panic)\n\nThe sibling `nsmf-oam` returning `401` proves OAuth middleware IS wired in for other SMF route groups; the UPI group specifically is mounted without it.\n\nVulnerable handler logic (paths in `free5gc/smf`):\n```go\n// NFs/smf/internal/sbi/api_upi.go:94..99\nif upNode.Type == smf_context.UPNODE_UPF {\n go s.Processor().ReleaseAllResourcesOfUPF(upNode.UPF)\n}\nupi.UpNodeDelete(upNodeRef)\nupNode.UPF.CancelAssociation() // \u003c-- panics for AN-typed nodes; nil UPF\n```\n\nThe `Type == UPNODE_UPF` guard only protects the asynchronous `ReleaseAllResourcesOfUPF` call. After that, `UpNodeDelete(upNodeRef)` runs unconditionally (so the topology mutation lands first), and then `upNode.UPF.CancelAssociation()` is called unconditionally on a `*UPF` that is `nil` for `AN` nodes by construction.\n\nCode evidence:\n- UPI group mounted WITHOUT auth middleware:\n - `NFs/smf/internal/sbi/server.go:76`\n - `NFs/smf/internal/sbi/server.go:78`\n- Protected control comparison (other SMF groups DO use auth):\n - `NFs/smf/internal/sbi/server.go:99`\n - `NFs/smf/internal/sbi/server.go:105`\n- Delete handler (panic site):\n - `NFs/smf/internal/sbi/api_upi.go:94`\n - `NFs/smf/internal/sbi/api_upi.go:99`\n- AN nodes are constructed without a UPF object (root cause of the nil deref):\n - `NFs/smf/internal/context/user_plane_information.go:95`\n - `NFs/smf/internal/context/user_plane_information.go:97`\n\n### PoC\nReproduced end-to-end against the running SMF at `http://10.100.200.6:8000`.\n\n1. Control: protected sibling OAM route returns `401`:\n```\ncurl -i http://10.100.200.6:8000/nsmf-oam/v1/\n```\n```\nHTTP/1.1 401 Unauthorized\n```\n\n2. Trigger: unauthenticated DELETE on the default AN node `gNB1`:\n```\ncurl -i -X DELETE http://10.100.200.6:8000/upi/v1/upNodesLinks/gNB1\n```\n```\nHTTP/1.1 500 Internal Server Error\n```\n\n3. SMF container logs (`docker logs --tail 120 smf`) show topology mutation landing BEFORE the panic, and the panic stack pointing at `api_upi.go:99`:\n```\n[INFO][SMF][Init] UPNode [gNB1] found. Deleting it.\n[INFO][SMF][Init] Delete UPLink [UPF] \u003c=\u003e [gNB1].\n[ERRO][SMF][GIN] panic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/free5gc/smf/internal/sbi.(*Server).DeleteUpNodeLink\n /go/src/free5gc/NFs/smf/internal/sbi/api_upi.go:99 +0x298\n[INFO][SMF][GIN] | 500 | DELETE | /upi/v1/upNodesLinks/gNB1\n```\n\nThe lab state was manually restored after validation by re-creating the AN entry; that POST is restoration-only and is NOT a mitigation.\n\n### Impact\nThree compounding defects on the same SMF SBI surface:\n1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the `UPI` route group, so the trigger is reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no session, no UE state needed. The same-instance `nsmf-oam` returning `401` proves the middleware is wired in elsewhere and only missing on UPI.\n2. NULL pointer dereference (CWE-476) in `DeleteUpNodeLink`: the `Type == UPNODE_UPF` guard only covers the async release call, then `upNode.UPF.CancelAssociation()` runs unconditionally on AN-typed nodes that have a nil `UPF` field by construction.\n3. Order of operations (CWE-755 / CWE-754): `UpNodeDelete(upNodeRef)` mutates the in-memory user-plane topology BEFORE the dereference panics, so the topology change lands even though the request returns 500. This makes the bug state-mutating, not just a plain panic.\n\nAny party that can reach SMF on the SBI can:\n- Delete arbitrary named entries (e.g. `gNB1`) from SMF\u0027s in-memory user-plane topology anonymously via a single `DELETE /upi/v1/upNodesLinks/{ref}` request, denying SMF\u0027s ability to consider that AN/UPF in subsequent UPF selection / PFCP path establishment for legitimate UE sessions.\n- Trigger a panic on the SMF goroutine for the deleted-AN case, even though Gin recovers the goroutine, leaving the topology in the mutated state above.\n- Repeat the trigger by name against any AN entry, sustaining the topology denial without ever authenticating.\n\nThis is a strict superset of the impact in free5gc/free5gc#887 for this specific code path: same auth bypass, plus a concrete request-triggerable nil deref, plus state mutation that survives the panic.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/905\nUpstream fix: https://github.com/free5gc/smf/pull/199",
"id": "GHSA-p9mg-74mg-cwwr",
"modified": "2026-06-08T23:48:26Z",
"published": "2026-05-08T23:01:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-p9mg-74mg-cwwr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44328"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/issues/905"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/smf/pull/199"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/smf/commit/b57bc48081c3d3a2f333d02eb78e4fd31a120deb"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/free5gc"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "free5GC\u0027s SMF UPI DELETE /upi/v1/upNodesLinks/{ref} panics on AN-node deletion via nil UPF dereference; unauthenticated, state-mutating"
}
GHSA-P9MP-Q42M-G65Q
Vulnerability from github – Published: 2025-01-07 06:32 – Updated: 2026-04-08 18:33The Social Rocket – Social Sharing Plugin plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the tweet_settings_save() and tweet_settings_update() functions in all versions up to, and including, 1.3.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update the plugin's settings.
{
"affected": [],
"aliases": [
"CVE-2024-9697"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-07T06:15:18Z",
"severity": "MODERATE"
},
"details": "The Social Rocket \u2013 Social Sharing Plugin plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the tweet_settings_save() and tweet_settings_update() functions in all versions up to, and including, 1.3.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update the plugin\u0027s settings.",
"id": "GHSA-p9mp-q42m-g65q",
"modified": "2026-04-08T18:33:47Z",
"published": "2025-01-07T06:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9697"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/social-rocket/trunk/admin/includes/class-social-rocket-admin.php#L39"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/social-rocket/trunk/admin/includes/class-social-rocket-admin.php#L5501"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/social-rocket/trunk/admin/includes/class-social-rocket-admin.php#L5531"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3347243"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/168dd2d4-bffb-4187-afc7-02fef8cb51a7?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-P9PP-QG57-94QV
Vulnerability from github – Published: 2026-09-14 21:31 – Updated: 2026-09-17 12:31An authorization issue was addressed with improved entitlement checks. This issue is fixed in macOS Golden Gate 27. An app may be able to capture Touch Bar content without authorization.
{
"affected": [],
"aliases": [
"CVE-2026-43696"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T21:17:08Z",
"severity": "MODERATE"
},
"details": "An authorization issue was addressed with improved entitlement checks. This issue is fixed in macOS Golden Gate 27. An app may be able to capture Touch Bar content without authorization.",
"id": "GHSA-p9pp-qg57-94qv",
"modified": "2026-09-17T12:31:57Z",
"published": "2026-09-14T21:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43696"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149035"
}
],
"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"
}
]
}
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.