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
20069 vulnerabilities reference this CWE, most recent first.
GHSA-J8HG-JWP2-X7F7
Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-09 18:31Missing Authorization vulnerability in leadlovers leadlovers forms leadlovers-forms allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects leadlovers forms: from n/a through <= 1.0.2.
{
"affected": [],
"aliases": [
"CVE-2026-39657"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T09:16:36Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in leadlovers leadlovers forms leadlovers-forms allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects leadlovers forms: from n/a through \u003c= 1.0.2.",
"id": "GHSA-j8hg-jwp2-x7f7",
"modified": "2026-04-09T18:31:25Z",
"published": "2026-04-08T09:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39657"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/leadlovers-forms/vulnerability/wordpress-leadlovers-forms-plugin-1-0-2-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-J8HX-8M98-MCJG
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-26 21:31Missing authorization in HTTP2 in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to leak sensitive information via crafted network traffic. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-79208"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T21:18:14Z",
"severity": "MODERATE"
},
"details": "Missing authorization in HTTP2 in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to leak sensitive information via crafted network traffic. (Chromium security severity: Medium)",
"id": "GHSA-j8hx-8m98-mcjg",
"modified": "2026-08-26T21:31:39Z",
"published": "2026-08-25T21:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79208"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/513287677"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J8J4-RW65-56R6
Vulnerability from github – Published: 2026-11-09 21:59 – Updated: 2026-11-09 21:59Summary
Telepresence's Traffic Manager gRPC API (port 8081) requires no authentication. Any pod with cluster-network access to the Traffic Manager can register as a client in an arbitrary managed namespace and create intercepts against services in that namespace, regardless of Kubernetes RBAC. On interception the victim pod's complete container environment (secrets, tokens, API keys) is delivered to the attacker. Tested on HEAD v2.28.0, commit b2231a4.
Details
The gRPC server is started with no auth interceptor (pkg/grpc/server/server.go). The connection uses plaintext: grpc.WithTransportCredentials(insecure.NewCredentials()).
ArriveAsClient stores the caller-supplied Namespace without verifying the caller is in that namespace. The only gate is whether the namespace is in the Traffic Manager's watchlist (ManagesNamespace):
// cmd/traffic/cmd/manager/service.go:181-201
func (s *service) ArriveAsClient(..., client *rpc.ClientInfo) (*rpc.SessionInfo, error) {
if !s.State().ManagesNamespace(ctx, client.Namespace) {
return nil, status.Error(codes.FailedPrecondition, ...)
}
// No SAR, no bearer token, no kubeconfig check
return &rpc.SessionInfo{SessionId: string(s.state.AddClient(client, ...))}, nil
}
CreateIntercept calls managedTargetNamespace() which also only checks ManagesNamespace(target_ns) — never that the target equals the client's own registered namespace (service.go:929). A session registered in namespace A can intercept namespace B as long as B is also watched. On interception, the victim pod's full container environment is forwarded via intercept.Environment = rIReq.Environment.
Proof of Concept
From any pod in the cluster:
conn, _ := grpc.NewClient("traffic-manager.ambassador:8081",
grpc.WithTransportCredentials(insecure.NewCredentials()))
mgr := rpc.NewManagerClient(conn)
session, _ := mgr.ArriveAsClient(ctx, &rpc.ClientInfo{
Name: "attacker@pod", Namespace: "payments",
InstallId: uuid.NewString(), Product: "telepresence", Version: "2.20.0",
})
mgr.CreateIntercept(ctx, &rpc.CreateInterceptRequest{
Session: session,
InterceptSpec: &rpc.InterceptSpec{
Name: "steal", Agent: "payments-api", Namespace: "payments",
Mechanism: "tcp", Client: "attacker@pod",
},
})
Supplying a namespace not in the TM watchlist returns FailedPrecondition, confirming the only gate is the watchlist check.
Impact
Any pod operator in the cluster can intercept services in namespaces they have no Kubernetes RBAC access to, receiving all traffic and environment variables. In the default cluster-wide Traffic Manager deployment all namespaces are managed. Secrets mounted as environment variables (database passwords, API keys, service account tokens) are exfiltrated with no audit trail on the victim namespace.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/telepresenceio/telepresence"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.31.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102340"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-09T21:59:49Z",
"nvd_published_at": "2026-11-04T21:17:40Z",
"severity": "HIGH"
},
"details": "## Summary\n\nTelepresence\u0027s Traffic Manager gRPC API (port 8081) requires no authentication. Any pod with cluster-network access to the Traffic Manager can register as a client in an arbitrary managed namespace and create intercepts against services in that namespace, regardless of Kubernetes RBAC. On interception the victim pod\u0027s complete container environment (secrets, tokens, API keys) is delivered to the attacker. Tested on HEAD v2.28.0, commit b2231a4.\n\n## Details\n\nThe gRPC server is started with no auth interceptor (pkg/grpc/server/server.go). The connection uses plaintext: `grpc.WithTransportCredentials(insecure.NewCredentials())`.\n\n`ArriveAsClient` stores the caller-supplied `Namespace` without verifying the caller is in that namespace. The only gate is whether the namespace is in the Traffic Manager\u0027s watchlist (`ManagesNamespace`):\n\n```go\n// cmd/traffic/cmd/manager/service.go:181-201\nfunc (s *service) ArriveAsClient(..., client *rpc.ClientInfo) (*rpc.SessionInfo, error) {\n if !s.State().ManagesNamespace(ctx, client.Namespace) {\n return nil, status.Error(codes.FailedPrecondition, ...)\n }\n // No SAR, no bearer token, no kubeconfig check\n return \u0026rpc.SessionInfo{SessionId: string(s.state.AddClient(client, ...))}, nil\n}\n```\n\n`CreateIntercept` calls `managedTargetNamespace()` which also only checks `ManagesNamespace(target_ns)` \u2014 never that the target equals the client\u0027s own registered namespace (service.go:929). A session registered in namespace A can intercept namespace B as long as B is also watched. On interception, the victim pod\u0027s full container environment is forwarded via `intercept.Environment = rIReq.Environment`.\n\n## Proof of Concept\n\nFrom any pod in the cluster:\n\n```go\nconn, _ := grpc.NewClient(\"traffic-manager.ambassador:8081\",\n grpc.WithTransportCredentials(insecure.NewCredentials()))\nmgr := rpc.NewManagerClient(conn)\n\nsession, _ := mgr.ArriveAsClient(ctx, \u0026rpc.ClientInfo{\n Name: \"attacker@pod\", Namespace: \"payments\",\n InstallId: uuid.NewString(), Product: \"telepresence\", Version: \"2.20.0\",\n})\n\nmgr.CreateIntercept(ctx, \u0026rpc.CreateInterceptRequest{\n Session: session,\n InterceptSpec: \u0026rpc.InterceptSpec{\n Name: \"steal\", Agent: \"payments-api\", Namespace: \"payments\",\n Mechanism: \"tcp\", Client: \"attacker@pod\",\n },\n})\n```\n\nSupplying a namespace not in the TM watchlist returns FailedPrecondition, confirming the only gate is the watchlist check.\n\n## Impact\n\nAny pod operator in the cluster can intercept services in namespaces they have no Kubernetes RBAC access to, receiving all traffic and environment variables. In the default cluster-wide Traffic Manager deployment all namespaces are managed.\nSecrets mounted as environment variables (database passwords, API keys, service account tokens) are exfiltrated with no audit trail on the victim namespace.",
"id": "GHSA-j8j4-rw65-56r6",
"modified": "2026-11-09T21:59:49Z",
"published": "2026-11-09T21:59:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/telepresenceio/telepresence/security/advisories/GHSA-j8j4-rw65-56r6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102340"
},
{
"type": "WEB",
"url": "https://github.com/telepresenceio/telepresence/pull/4217"
},
{
"type": "WEB",
"url": "https://github.com/telepresenceio/telepresence/commit/04ec3464fe8878fdc96420cdc8036edefa0dc9ae"
},
{
"type": "WEB",
"url": "https://github.com/telepresenceio/telepresence/commit/36458b65a010d2b316af48cd90e193ba190785d9"
},
{
"type": "WEB",
"url": "https://github.com/telepresenceio/telepresence/commit/6871235b674a6e843908d09696354c4b0f91578c"
},
{
"type": "PACKAGE",
"url": "https://github.com/telepresenceio/telepresence"
},
{
"type": "WEB",
"url": "https://github.com/telepresenceio/telepresence/releases/tag/v2.31.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Telepresence: Traffic Manager gRPC has no auth \u2014 any pod claims arbitrary namespace and intercepts services, receiving victim environment secrets"
}
GHSA-J8JW-7JP2-FVJ5
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-11 21:31Missing Authorization vulnerability in Pixar Labs Master Addons for Elementor allows Privilege Abuse.
This issue affects Master Addons for Elementor: from n/a through 3.2.2.
{
"affected": [],
"aliases": [
"CVE-2026-62089"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T19:17:42Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in Pixar Labs Master Addons for Elementor allows Privilege Abuse.\n\nThis issue affects Master Addons for Elementor: from n/a through 3.2.2.",
"id": "GHSA-j8jw-7jp2-fvj5",
"modified": "2026-09-11T21:31:17Z",
"published": "2026-09-11T21:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62089"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/master-addons/vulnerability/wordpress-master-addons-for-elementor-plugin-3-2-2-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:H",
"type": "CVSS_V3"
}
]
}
GHSA-J8JX-64CG-5V4F
Vulnerability from github – Published: 2023-06-07 03:30 – Updated: 2024-04-04 04:38The Welcart e-Commerce plugin for WordPress is vulnerable to authorization bypass due to missing capability checks on the download_orderdetail_list(), change_orderlist(), and download_member_list() functions called via admin_init hooks in versions up to, and including, 2.2.7. This makes it possible for unauthenticated attackers to download lists of members, products and orders.
{
"affected": [],
"aliases": [
"CVE-2021-4355"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T02:15:13Z",
"severity": "MODERATE"
},
"details": "The Welcart e-Commerce plugin for WordPress is vulnerable to authorization bypass due to missing capability checks on the download_orderdetail_list(), change_orderlist(), and download_member_list() functions called via admin_init hooks in versions up to, and including, 2.2.7. This makes it possible for unauthenticated attackers to download lists of members, products and orders.",
"id": "GHSA-j8jx-64cg-5v4f",
"modified": "2024-04-04T04:38:14Z",
"published": "2023-06-07T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4355"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/wordpress-welcart-e-commerce-plugin-fixed-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/671f5ba5-1f18-49fa-aa97-eaebdb3417bb?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J8MJ-5FPW-2PC8
Vulnerability from github – Published: 2023-11-06 18:30 – Updated: 2023-11-06 18:30An authorization issue affecting GitLab EE affecting all versions from 14.7 prior to 16.3.6, 16.4 prior to 16.4.2, and 16.5 prior to 16.5.1, allowed a user to run jobs in protected environments, bypassing any required approvals.
{
"affected": [],
"aliases": [
"CVE-2023-4700"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-06T18:15:08Z",
"severity": "LOW"
},
"details": "An authorization issue affecting GitLab EE affecting all versions from 14.7 prior to 16.3.6, 16.4 prior to 16.4.2, and 16.5 prior to 16.5.1, allowed a user to run jobs in protected environments, bypassing any required approvals.",
"id": "GHSA-j8mj-5fpw-2pc8",
"modified": "2023-11-06T18:30:19Z",
"published": "2023-11-06T18:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4700"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2129826"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/421937"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J8P6-F6H2-JC6F
Vulnerability from github – Published: 2026-11-04 00:32 – Updated: 2026-11-04 00:32SourceHut meta.sr.ht 0.56.11 before 0.89.0 contains an authorization bypass vulnerability that allows unauthenticated attackers to register accounts when public registration is disabled. Attackers can obtain a CSRF token from /login and POST credentials to /register/step2, which invokes the unchecked GraphQL RegisterAccount mutation to create accounts.
{
"affected": [],
"aliases": [
"CVE-2026-121728"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-03T23:17:36Z",
"severity": "MODERATE"
},
"details": "SourceHut meta.sr.ht 0.56.11 before 0.89.0 contains an authorization bypass vulnerability that allows unauthenticated attackers to register accounts when public registration is disabled. Attackers can obtain a CSRF token from /login and POST credentials to /register/step2, which invokes the unchecked GraphQL RegisterAccount mutation to create accounts.",
"id": "GHSA-j8p6-f6h2-jc6f",
"modified": "2026-11-04T00:32:17Z",
"published": "2026-11-04T00:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-121728"
},
{
"type": "WEB",
"url": "https://blog.arusekk.pl/posts/srht-disabled-registration-bypass"
},
{
"type": "WEB",
"url": "https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/1ea24685a76f6456245d0bc7fe6accf6231c4044"
},
{
"type": "WEB",
"url": "https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/e471ffe75bb6ef11366e46c3b721dd0278f746b5"
},
{
"type": "WEB",
"url": "https://git.sr.ht/~sircmpwn/meta.sr.ht/refs/0.89.0"
},
{
"type": "WEB",
"url": "https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/0.88.9/item/metasrht/blueprints/auth.py#L121"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sourcehut-meta-sr-ht-0.56.11-before-0.89.0-registration-authorization-bypass-via-register-step2"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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-J8PH-6CV6-W3VQ
Vulnerability from github – Published: 2025-02-01 06:31 – Updated: 2025-02-01 06:31The RapidLoad – Optimize Web Vitals Automatically plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ajax_deactivate() function in all versions up to, and including, 2.4.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to reset some of the plugin's settings.
{
"affected": [],
"aliases": [
"CVE-2024-13651"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-01T04:15:30Z",
"severity": "MODERATE"
},
"details": "The RapidLoad \u2013 Optimize Web Vitals Automatically plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the ajax_deactivate() function in all versions up to, and including, 2.4.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to reset some of the plugin\u0027s settings.",
"id": "GHSA-j8ph-6cv6-w3vq",
"modified": "2025-02-01T06:31:00Z",
"published": "2025-02-01T06:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13651"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3232560%40unusedcss\u0026new=3232560%40unusedcss\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/87f9f052-2963-4548-9ff8-91dc2b4ecb43?source=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:N",
"type": "CVSS_V3"
}
]
}
GHSA-J8R6-V8QR-PF69
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:32Firejail before 0.9.44.4 and 0.9.38.x LTS before 0.9.38.8 LTS does not consider the .Xauthority case during its attempt to prevent accessing user files with an euid of zero, which allows local users to conduct sandbox-escape attacks via vectors involving a symlink and the --private option.
{
"affected": [],
"aliases": [
"CVE-2017-5180"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-09T18:59:00Z",
"severity": "HIGH"
},
"details": "Firejail before 0.9.44.4 and 0.9.38.x LTS before 0.9.38.8 LTS does not consider the .Xauthority case during its attempt to prevent accessing user files with an euid of zero, which allows local users to conduct sandbox-escape attacks via vectors involving a symlink and the --private option.",
"id": "GHSA-j8r6-v8qr-pf69",
"modified": "2025-04-20T03:32:39Z",
"published": "2022-05-13T01:46:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5180"
},
{
"type": "WEB",
"url": "https://firejail.wordpress.com/download-2/release-notes"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201701-62"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2017/01/04/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95298"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J8V8-G9CX-5QF4
Vulnerability from github – Published: 2026-07-07 20:57 – Updated: 2026-07-07 20:57Am I affected?
Users are affected if all of these hold:
- They install and register the
@better-auth/scimplugin (plugins: [scim()]). - They create SCIM providers without an
organizationId, that is, non-organization ("personal") providers. Organization-scoped providers are not affected because they enforce organization membership and role. - Their application's deployment has more than one authenticated user, so one account can target another user's provider.
- They have not set
providerOwnership: { enabled: true }.
The SCIM management endpoints first shipped in 1.5.0, so every stable release from 1.5.0 onward is affected, and the stable line is not patched. On the pre-release line, builds through 1.7.0-beta.3 are affected, and 1.7.0-beta.4 carries the fix.
Fix:
- Upgrade to
@better-auth/scim@1.7.0-beta.4(then1.7.0). This is a breaking change: it removes theproviderOwnershipoption, makes owner binding mandatory, and adds a permanentscimProvider.userIdcolumn. - Run the schema migration after upgrading (
npx auth migrate). Connections created before the upgrade carry no owner and become unreachable through the management endpoints, so reclaim them at the database level. - The
1.6.xstable line is not patched. If developers stay on it, apply the workaround below.
Summary
@better-auth/scim does not bind non-organization SCIM providers to their creator in the default configuration. Any authenticated user can manage another user's non-org provider, including reading its metadata, listing connections, regenerating its SCIM bearer token, and deleting the connection. Regenerating the token rotates it: the legitimate token stops working and the attacker holds a valid one.
Details
The plugin tracks provider ownership through an opt-in providerOwnership option and a scimProvider.userId column. Both default to off. When ownership is disabled, a non-org provider row is created without a userId, and the management access check denies access only when a stored owner id is present and differs from the caller:
// non-organization branch of the access check
} else if (provider.userId && provider.userId !== userId) {
throw new APIError("FORBIDDEN", { message: "You must be the owner to access this provider" });
}
Because the default row has no userId, the condition is false and the request is allowed. The same gap reaches every management operation: token generation and regeneration, single-provider read, the connection list (which returns providers where p.userId === userId || !p.userId), and provider deletion.
The most sensitive operation is token regeneration. If Alice creates a non-org provider corp-idp, Bob can call the same generate-token endpoint with providerId: "corp-idp". The existing row passes the ownerless access check, so the plugin deletes it, creates a fresh row, and returns a new SCIM bearer token to Bob. Alice's previous token is now invalid, and Bob's token authenticates against that provider's SCIM API routes.
This requires no organization membership and no elevated role. It is reachable in the default scim() configuration whenever non-organization providers are used.
Proof of concept
Two authenticated users, Alice and Bob, in a default scim() setup:
- Alice signs in and creates a non-org provider:
POST /scim/generate-tokenwith{ "providerId": "corp-idp" }. - Bob signs in and reads Alice's provider:
GET /scim/get-provider-connection?providerId=corp-idpreturns200with{ "providerId": "corp-idp" }. - Bob regenerates the token:
POST /scim/generate-tokenwith{ "providerId": "corp-idp" }returns201and a newscimToken. - Alice's old token is rejected at
GET /scim/v2/Users(401); Bob's regenerated token is accepted (200).
The behavior is reproducible through Better Auth's public API surface with two distinct sessions.
Patches
Fixed in @better-auth/scim@1.7.0-beta.4 (then 1.7.0). The fix makes owner binding mandatory: generateSCIMToken records the creator's userId on every personal connection, and the management endpoints grant access only to that owner. Organization-scoped connections keep their existing membership and role checks. The 1.6.x stable line is not patched.
This release is breaking. It removes the providerOwnership option, owner binding can no longer be disabled, and the scimProvider.userId column becomes a permanent part of the schema, so run npx auth migrate after upgrading. Connections created before the upgrade carry no owner and fail closed; reclaim them by deleting scimProvider rows that have neither organizationId nor userId, or by setting userId to the intended owner, then regenerating tokens.
Workarounds
Until a patched version is available:
- Set
providerOwnership: { enabled: true }when registering the plugin, then run the schema update so thescimProvider.userIdcolumn exists (npx auth generateornpx auth migrate). New non-org providers are then owner-bound and non-owners are denied. Providers created before enabling ownership stay ownerless until recreated. - Or scope every SCIM provider to an organization by always passing
organizationId. Organization providers enforce membership and role and are not exposed. - Or restrict access to the SCIM management endpoints at the edge while non-org providers remain ownerless.
Impact
Any authenticated user can take over non-organization SCIM providers created by other users when the plugin runs with its default ownership configuration. An attacker can discover non-org provider connections, read provider metadata, regenerate another user's SCIM token (invalidating the legitimate one), authenticate to the SCIM API routes with the new token, manage SCIM-provisioned users subject to the enabled SCIM functionality, and delete the provider connection.
Credit
Reported by Jvr2022 through a private GitHub Security Advisory.
Resources
- CWE-862 Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
- CWE-639 Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
- SCIM 2.0 Protocol (RFC 7644): https://datatracker.ietf.org/doc/html/rfc7644
- OAuth 2.0 Bearer Token Usage (RFC 6750): https://datatracker.ietf.org/doc/html/rfc6750
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@better-auth/scim"
},
"ranges": [
{
"events": [
{
"introduced": "1.5.0"
},
{
"fixed": "1.7.0-beta.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-07T20:57:05Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Am I affected?\n\nUsers are affected if all of these hold:\n\n- They install and register the `@better-auth/scim` plugin (`plugins: [scim()]`).\n- They create SCIM providers without an `organizationId`, that is, non-organization (\"personal\") providers. Organization-scoped providers are not affected because they enforce organization membership and role.\n- Their application\u0027s deployment has more than one authenticated user, so one account can target another user\u0027s provider.\n- They have not set `providerOwnership: { enabled: true }`.\n\nThe SCIM management endpoints first shipped in `1.5.0`, so every stable release from `1.5.0` onward is affected, and the stable line is not patched. On the pre-release line, builds through `1.7.0-beta.3` are affected, and `1.7.0-beta.4` carries the fix.\n\nFix:\n\n1. Upgrade to `@better-auth/scim@1.7.0-beta.4` (then `1.7.0`). This is a breaking change: it removes the `providerOwnership` option, makes owner binding mandatory, and adds a permanent `scimProvider.userId` column.\n2. Run the schema migration after upgrading (`npx auth migrate`). Connections created before the upgrade carry no owner and become unreachable through the management endpoints, so reclaim them at the database level.\n3. The `1.6.x` stable line is not patched. If developers stay on it, apply the workaround below.\n\n### Summary\n\n`@better-auth/scim` does not bind non-organization SCIM providers to their creator in the default configuration. Any authenticated user can manage another user\u0027s non-org provider, including reading its metadata, listing connections, regenerating its SCIM bearer token, and deleting the connection. Regenerating the token rotates it: the legitimate token stops working and the attacker holds a valid one.\n\n### Details\n\nThe plugin tracks provider ownership through an opt-in `providerOwnership` option and a `scimProvider.userId` column. Both default to off. When ownership is disabled, a non-org provider row is created without a `userId`, and the management access check denies access only when a stored owner id is present and differs from the caller:\n\n```ts\n// non-organization branch of the access check\n} else if (provider.userId \u0026\u0026 provider.userId !== userId) {\n throw new APIError(\"FORBIDDEN\", { message: \"You must be the owner to access this provider\" });\n}\n```\n\nBecause the default row has no `userId`, the condition is false and the request is allowed. The same gap reaches every management operation: token generation and regeneration, single-provider read, the connection list (which returns providers where `p.userId === userId || !p.userId`), and provider deletion.\n\nThe most sensitive operation is token regeneration. If Alice creates a non-org provider `corp-idp`, Bob can call the same generate-token endpoint with `providerId: \"corp-idp\"`. The existing row passes the ownerless access check, so the plugin deletes it, creates a fresh row, and returns a new SCIM bearer token to Bob. Alice\u0027s previous token is now invalid, and Bob\u0027s token authenticates against that provider\u0027s SCIM API routes.\n\nThis requires no organization membership and no elevated role. It is reachable in the default `scim()` configuration whenever non-organization providers are used.\n\n### Proof of concept\n\nTwo authenticated users, Alice and Bob, in a default `scim()` setup:\n\n1. Alice signs in and creates a non-org provider: `POST /scim/generate-token` with `{ \"providerId\": \"corp-idp\" }`.\n2. Bob signs in and reads Alice\u0027s provider: `GET /scim/get-provider-connection?providerId=corp-idp` returns `200` with `{ \"providerId\": \"corp-idp\" }`.\n3. Bob regenerates the token: `POST /scim/generate-token` with `{ \"providerId\": \"corp-idp\" }` returns `201` and a new `scimToken`.\n4. Alice\u0027s old token is rejected at `GET /scim/v2/Users` (`401`); Bob\u0027s regenerated token is accepted (`200`).\n\nThe behavior is reproducible through Better Auth\u0027s public API surface with two distinct sessions.\n\n### Patches\n\nFixed in `@better-auth/scim@1.7.0-beta.4` (then `1.7.0`). The fix makes owner binding mandatory: `generateSCIMToken` records the creator\u0027s `userId` on every personal connection, and the management endpoints grant access only to that owner. Organization-scoped connections keep their existing membership and role checks. The `1.6.x` stable line is not patched.\n\nThis release is breaking. It removes the `providerOwnership` option, owner binding can no longer be disabled, and the `scimProvider.userId` column becomes a permanent part of the schema, so run `npx auth migrate` after upgrading. Connections created before the upgrade carry no owner and fail closed; reclaim them by deleting `scimProvider` rows that have neither `organizationId` nor `userId`, or by setting `userId` to the intended owner, then regenerating tokens.\n\n### Workarounds\n\nUntil a patched version is available:\n\n- Set `providerOwnership: { enabled: true }` when registering the plugin, then run the schema update so the `scimProvider.userId` column exists (`npx auth generate` or `npx auth migrate`). New non-org providers are then owner-bound and non-owners are denied. Providers created before enabling ownership stay ownerless until recreated.\n- Or scope every SCIM provider to an organization by always passing `organizationId`. Organization providers enforce membership and role and are not exposed.\n- Or restrict access to the SCIM management endpoints at the edge while non-org providers remain ownerless.\n\n### Impact\n\nAny authenticated user can take over non-organization SCIM providers created by other users when the plugin runs with its default ownership configuration. An attacker can discover non-org provider connections, read provider metadata, regenerate another user\u0027s SCIM token (invalidating the legitimate one), authenticate to the SCIM API routes with the new token, manage SCIM-provisioned users subject to the enabled SCIM functionality, and delete the provider connection.\n\n### Credit\n\nReported by Jvr2022 through a private GitHub Security Advisory.\n\n### Resources\n\n- CWE-862 Missing Authorization: https://cwe.mitre.org/data/definitions/862.html\n- CWE-639 Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html\n- SCIM 2.0 Protocol (RFC 7644): https://datatracker.ietf.org/doc/html/rfc7644\n- OAuth 2.0 Bearer Token Usage (RFC 6750): https://datatracker.ietf.org/doc/html/rfc6750",
"id": "GHSA-j8v8-g9cx-5qf4",
"modified": "2026-07-07T20:57:06Z",
"published": "2026-07-07T20:57:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-j8v8-g9cx-5qf4"
},
{
"type": "PACKAGE",
"url": "https://github.com/better-auth/better-auth"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.7.0-beta.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "@better-auth/scim: Account/provider takeover via missing owner binding on non-org SCIM providers"
}
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.