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.
14837 vulnerabilities reference this CWE, most recent first.
GHSA-P98W-MX82-XHG4
Vulnerability from github – Published: 2025-10-27 03:30 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in Spencer Haws Link Whisper Free link-whisper allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Link Whisper Free: from n/a through <= 0.8.8.
{
"affected": [],
"aliases": [
"CVE-2025-62970"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-27T02:15:57Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Spencer Haws Link Whisper Free link-whisper allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Link Whisper Free: from n/a through \u003c= 0.8.8.",
"id": "GHSA-p98w-mx82-xhg4",
"modified": "2026-01-20T15:31:37Z",
"published": "2025-10-27T03:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62970"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/link-whisper/vulnerability/wordpress-link-whisper-free-plugin-0-8-8-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/link-whisper/vulnerability/wordpress-link-whisper-free-plugin-0-8-8-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/link-whisper/vulnerability/wordpress-link-whisper-free-plugin-0-8-8-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-P996-488Q-CFM2
Vulnerability from github – Published: 2025-06-13 18:30 – Updated: 2025-06-13 18:30Missing Authorization vulnerability in Drupal Bookable Calendar allows Forceful Browsing.This issue affects Bookable Calendar: from 0.0.0 before 2.2.13.
{
"affected": [],
"aliases": [
"CVE-2025-48916"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-13T16:15:26Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Drupal Bookable Calendar allows Forceful Browsing.This issue affects Bookable Calendar: from 0.0.0 before 2.2.13.",
"id": "GHSA-p996-488q-cfm2",
"modified": "2025-06-13T18:30:35Z",
"published": "2025-06-13T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48916"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2025-070"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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-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-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-P9QR-RF97-2VHP
Vulnerability from github – Published: 2025-12-13 18:30 – Updated: 2025-12-13 18:30The Easy Theme Options plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.0. This is due to missing authorization checks in the eto_import_settings function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to import arbitrary plugin settings via the 'eto_import_settings' parameter.
{
"affected": [],
"aliases": [
"CVE-2025-14367"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-13T16:16:48Z",
"severity": "MODERATE"
},
"details": "The Easy Theme Options plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.0. This is due to missing authorization checks in the eto_import_settings function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to import arbitrary plugin settings via the \u0027eto_import_settings\u0027 parameter.",
"id": "GHSA-p9qr-rf97-2vhp",
"modified": "2025-12-13T18:30:21Z",
"published": "2025-12-13T18:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14367"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/easy-theme-options/tags/1.0/easy-theme-options.php#L277"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/easy-theme-options/tags/1.0/easy-theme-options.php#L282"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8405e80d-fd72-4d87-b08a-19a686eb2982?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"
}
]
}
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.