Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5660 vulnerabilities reference this CWE, most recent first.

GHSA-643Q-778F-W3WX

Vulnerability from github – Published: 2024-10-25 00:33 – Updated: 2024-10-29 18:30
VLAI
Details

Money Manager EX WebApp (web-money-manager-ex) 1.2.2 is vulnerable to Incorrect Access Control. The redirect_if_not_loggedin function in functions_security.php fails to terminate script execution after redirecting unauthenticated users. This flaw allows an unauthenticated attacker to upload arbitrary files, potentially leading to Remote Code Execution.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-41617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-24T22:15:03Z",
    "severity": "CRITICAL"
  },
  "details": "Money Manager EX WebApp (web-money-manager-ex) 1.2.2 is vulnerable to Incorrect Access Control. The `redirect_if_not_loggedin` function in `functions_security.php` fails to terminate script execution after redirecting unauthenticated users. This flaw allows an unauthenticated attacker to upload arbitrary files, potentially leading to Remote Code Execution.",
  "id": "GHSA-643q-778f-w3wx",
  "modified": "2024-10-29T18:30:35Z",
  "published": "2024-10-25T00:33:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moneymanagerex/web-money-manager-ex/issues/51"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moneymanagerex/web-money-manager-ex/commit/f2850b295ee21bc299799343a3bc4d004d05651d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moneymanagerex/web-money-manager-ex/releases/tag/v1.2.3"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/JaOrlT9G3yo?t=88"
    }
  ],
  "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-647H-9MH3-P4P7

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details

An exploitable improper authorization vulnerability exists in miner_setGasPrice API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-12116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-19T23:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable improper authorization vulnerability exists in miner_setGasPrice API of cpp-ethereum\u0027s JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.",
  "id": "GHSA-647h-9mh3-p4p7",
  "modified": "2022-05-13T01:01:38Z",
  "published": "2022-05-13T01:01:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12116"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0468"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-649P-MMHF-85C7

Vulnerability from github – Published: 2026-07-21 21:43 – Updated: 2026-07-21 21:43
VLAI
Summary
Gitea: Cached Per-Branch Permission Check in Pre-Receive Hook Allows Full Repository Write
Details

Vulnerability Header

Field Value
Vulnerability Title Cached Per-Branch Permission Check in Pre-Receive Hook Allows Full Repository Write
Severity Rating High
Bug Category Authorization Bypass
Location routers/private/hook_pre_receive.go:55-64, CanWriteCode()
Affected Versions 1.25.5

Executive Summary

The pre-receive hook in Gitea evaluates the CanMaintainerWriteToBranch permission only once per git push session and caches the result for all subsequent refs in the same batch. An attacker who has a legitimate per-branch write grant (e.g., via an open pull request with "Allow edits from maintainers" enabled) can batch-push that branch together with any other ref. The cached true from the first ref is reused for all following refs, allowing the attacker to overwrite protected branches (including main), create arbitrary new branches, and push tags. This effectively escalates a single-branch maintainer-edit grant into full repository write access.

Root Cause Analysis

Technical Description

When processing a multi-ref git push, the HookPreReceive handler at hook_pre_receive.go:107 iterates over all incoming refs. For each branch ref, preReceiveBranch (:140) updates ctx.branchName to the current branch (:142) and then calls AssertCanWriteCode() (:144).

CanWriteCode() (:55-64) checks whether the user can write to the repository. On the first call, it evaluates issues_model.CanMaintainerWriteToBranch(ctx, userPerm, ctx.branchName, user) and stores the result in a boolean flag (canWriteCode) with a guard (checkedCanWriteCode). On all subsequent calls within the same batch, it returns the cached boolean without re-evaluating against the now-different ctx.branchName.

This means the permission check is branch-specific in its inputs but session-scoped in its caching — a classic check-vs-use divergence.

A second contributing factor is the AGit-flow relaxation at routers/web/repo/githttp.go:190-192 (and routers/private/serv.go:337-338), which downgrades the outer receive-pack access gate from Write to Read when git.DefaultFeatures().SupportProcReceive is true (git ≥ 2.29). This allows a user with only Read access on a repository to initiate a receive-pack session, deferring all authorization to the pre-receive hook — which contains the caching bug described above.

First Faulty Condition

File routers/private/hook_pre_receive.go
Line 55-64
Condition CanWriteCode() evaluates the branch-specific CanMaintainerWriteToBranch check only on the first invocation and caches the result, reusing it for all subsequent refs in the batch regardless of which branch they target.

Trace Analysis

The following is the path from the attacker's git push to the authorization fault:

  1. POST /{owner}/{repo}.git/git-receive-pack → routers/web/repo/githttp.go:437 (ServiceReceivePack) → httpBase() (:60)

  2. Access gate is downgraded from Write to Read at :190-192 due to AGit-flow support.

  3. git receive-pack invokes the pre-receive hook → cmd/hook.go:184 (runHookPreReceive) → modules/private/hook.go:96 (HookPreReceive) → internal API → routers/private/hook_pre_receive.go:107 (HookPreReceive)

  4. Loop at :117 iterates over all refs in the batch. For each branch ref, preReceiveBranch (:140) sets ctx.branchName at :142.

  5. Fault: AssertCanWriteCode() (:144) → CanWriteCode() (:55-64).

  6. First ref (feature-branch): checkedCanWriteCode is false → evaluates CanMaintainerWriteToBranch(ctx, userPerm, "feature-branch", user) → returns true (legitimate grant) → caches result.

  7. Second ref (main): checkedCanWriteCode is already true → returns cached true without re-evaluating against "main".

  8. Hook returns 200 → git receive-pack accepts all refs → main is overwritten in the victim's repository.

Exploitability Assessment

Attack Vector & Reachability

Attack vector Network
Authentication required Low
User interaction required Required. Victim must enable "Allow edits from maintainers" on their PR
Reachable in default config Yes
Entry point git push over smart-HTTP or SSH with multiple refs in a single operation

The attacker gains full write access to the victim's repository — equivalent to having push permissions on all refs. By controlling the order of refs in the batch (e.g., naming the granted branch so it sorts first), the attacker reliably ensures the legitimate ref is evaluated before the target. This is not a race condition; it is deterministic.

Reproduction Steps

Environment The issue was reproduced using Gitea v1.25.5 on Ubuntu 24.04.4 LTS.

Prerequisites: * a Gitea instance with two users, attacker and victim.

# 1. Attacker creates a repository (e.g., a popular open-source project)
curl -X POST "http://attacker:pw@<gitea>/api/v1/user/repos" \
  -H "Content-Type: application/json" \
  -d '{"name": "project", "auto_init": true}'

# 2. Victim forks attacker's repository (standard contributor workflow)
curl -X POST "http://victim:pw@<gitea>/api/v1/repos/attacker/project/forks" \
  -H "Content-Type: application/json" \
  -d '{}'

# 3. Victim creates a feature branch on their fork and commits a change
curl -X POST "http://victim:pw@<gitea>/api/v1/repos/victim/project/branches" \
  -H "Content-Type: application/json" \
  -d '{"new_branch_name": "feature-branch", "old_branch_name": "main"}'

curl -X POST "http://victim:pw@<gitea>/api/v1/repos/victim/project/contents/contribution.txt" \
  -H "Content-Type: application/json" \
  -d '{"message": "Add contribution", "content": "'$(echo -n "victim contribution" | base64)'", "branch": "feature-branch"}'

# 4. Victim opens a PR from their feature branch into attacker/project
#    with "Allow edits from maintainers" enabled
curl -X POST "http://victim:pw@<gitea>/api/v1/repos/attacker/project/pulls" \
  -H "Content-Type: application/json" \
  -d '{"title": "Feature PR", "head": "victim:feature-branch", "base": "main", "allow_maintainer_edit": true}'

At this point, the attacker (as maintainer of the base repo attacker/project) has a per-branch write grant on the victim's fork, scoped to the feature-branch branch only.

Attack

The attacker works from their own repo (attacker/project)

# 5. Attacker clones their own repo
git clone http://attacker:pw@<gitea>/attacker/project.git && cd project

# 6. Attacker fetches the victim's PR branch
git fetch -u http://<gitea>/victim/project feature-branch:victim-feature-branch
git checkout victim-feature-branch

# 7. Attacker adds a commit to the PR branch
echo "legitimate change" > feature.txt && git add . && git commit -m "PR update"

# 8. Attacker also prepares a malicious commit on main
git checkout main
echo "MALICIOUS CONTENT" > PWNED && git add . && git commit -m "pwned"

# 9. Attacker pushes both refs to the victim's fork in a single operation — this is the exploit
git push http://attacker:pw@<gitea>/victim/project.git victim-feature-branch:feature-branch main:main

# 10. The change on both refs is visible regardless of PR status

Expected result: main should be rejected ("User permission denied for writing").

Actual result: Both refs are accepted. victim/project:main now contains the attacker's malicious commit.

# Verify: victim checks their fork's main branch
curl "http://victim:pw@<gitea>/api/v1/repos/victim/project/contents/PWNED?ref=main"
# Returns attacker's "MALICIOUS CONTENT" — main has been overwritten

The same technique also works for pushing arbitrary tags (refs/tags/*) and creating new branches.

Recommended Fix

Remove the caching in CanWriteCode() — the CanMaintainerWriteToBranch check must be evaluated for every ref in the batch, not cached after the first call. The checkedCanWriteCode / canWriteCode fields on preReceiveContext and the guard in CanWriteCode() at hook_pre_receive.go:55-64 should be removed, so the permission is evaluated fresh each time preReceiveBranch or preReceiveTag calls it. loadPusherAndPermission() already has its own caching (loadedPusher), so the per-call cost is limited to the CanMaintainerWriteToBranch query.

See diff.patch for the proposed fix.

Patch provenance: AI-generated, human-reviewed.

Attribution

This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by Adrian Denkiewicz at Doyensec in collaboration with Anthropic Research.

For CVE credits and public acknowledgments: Doyensec in collaboration with Claude and Anthropic Research

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27775"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:43:11Z",
    "nvd_published_at": "2026-07-03T21:16:59Z",
    "severity": "HIGH"
  },
  "details": "## Vulnerability Header\n\n| Field               | Value                                                                               |\n| ------------------- | ----------------------------------------------------------------------------------- |\n| Vulnerability Title | Cached Per-Branch Permission Check in Pre-Receive Hook Allows Full Repository Write |\n| Severity Rating     | High                                                                                |\n| Bug Category        | Authorization Bypass                                                                |\n| Location            | `routers/private/hook_pre_receive.go:55-64`, `CanWriteCode()`                       |\n| Affected Versions   | 1.25.5                                                                              |\n\n## Executive Summary\n\nThe pre-receive hook in Gitea evaluates the `CanMaintainerWriteToBranch` permission only once per `git push` session and caches the result for all subsequent refs in the same batch. An attacker who has a legitimate per-branch write grant (e.g., via an open pull request with \"Allow edits from maintainers\" enabled) can batch-push that branch together with any other ref. The cached `true` from the first ref is reused for all following refs, allowing the attacker to overwrite protected branches (including `main`), create arbitrary new branches, and push tags. This effectively escalates a single-branch maintainer-edit grant into full repository write access.\n\n## Root Cause Analysis\n\n### Technical Description\n\nWhen processing a multi-ref `git push`, the `HookPreReceive` handler at `hook_pre_receive.go:107` iterates over all incoming refs. For each branch ref, `preReceiveBranch` (`:140`) updates `ctx.branchName` to the current branch (`:142`) and then calls `AssertCanWriteCode()` (`:144`).\n\n`CanWriteCode()` (`:55-64`) checks whether the user can write to the repository. On the first call, it evaluates `issues_model.CanMaintainerWriteToBranch(ctx, userPerm, ctx.branchName, user)` and stores the result in a boolean flag (`canWriteCode`) with a guard (`checkedCanWriteCode`). On all subsequent calls within the same batch, it returns the cached boolean without re-evaluating against the now-different `ctx.branchName`.\n\nThis means the permission check is branch-specific in its inputs but session-scoped in its caching \u2014 a classic check-vs-use divergence.\n\nA second contributing factor is the AGit-flow relaxation at `routers/web/repo/githttp.go:190-192` (and `routers/private/serv.go:337-338`), which downgrades the outer `receive-pack` access gate from `Write` to `Read` when `git.DefaultFeatures().SupportProcReceive` is true (git \u2265 2.29). This allows a user with only Read access on a repository to initiate a `receive-pack` session, deferring all authorization to the pre-receive hook \u2014 which contains the caching bug described above.\n\n### First Faulty Condition\n\n| File      | `routers/private/hook_pre_receive.go` |\n| --------- | ------------------------------------- |\n| Line      | 55-64                                 |\n| Condition | `CanWriteCode()` evaluates the branch-specific `CanMaintainerWriteToBranch` check only on the first invocation and caches the result, reusing it for all subsequent refs in the batch regardless of which branch they target. |\n\n### Trace Analysis\n\nThe following is the path from the attacker\u0027s `git push` to the authorization fault:\n\n1. `POST /{owner}/{repo}.git/git-receive-pack` \u2192 `routers/web/repo/githttp.go:437` (`ServiceReceivePack`) \u2192 `httpBase()` (`:60`)\n   - Access gate is downgraded from Write to Read at `:190-192` due to AGit-flow support.\n\n2. `git receive-pack` invokes the pre-receive hook \u2192 `cmd/hook.go:184` (`runHookPreReceive`) \u2192 `modules/private/hook.go:96` (`HookPreReceive`) \u2192 internal API \u2192 `routers/private/hook_pre_receive.go:107` (`HookPreReceive`)\n\n3. Loop at `:117` iterates over all refs in the batch. For each branch ref, `preReceiveBranch` (`:140`) sets `ctx.branchName` at `:142`.\n\n4. **Fault**: `AssertCanWriteCode()` (`:144`) \u2192 `CanWriteCode()` (`:55-64`).\n   - First ref (`feature-branch`): `checkedCanWriteCode` is false \u2192 evaluates `CanMaintainerWriteToBranch(ctx, userPerm, \"feature-branch\", user)` \u2192 returns `true` (legitimate grant) \u2192 caches result.\n   - Second ref (`main`): `checkedCanWriteCode` is already true \u2192 returns cached `true` **without re-evaluating** against `\"main\"`.\n\n5. Hook returns 200 \u2192 `git receive-pack` accepts all refs \u2192 `main` is overwritten in the victim\u0027s repository.\n\n## Exploitability Assessment\n\n### Attack Vector \u0026 Reachability\n\n| Attack vector               | Network                                                                             |\n| --------------------------- | ----------------------------------------------------------------------------------- |\n| Authentication required     | Low                                                                                 |\n| User interaction required   | Required. Victim must enable \"Allow edits from maintainers\" on their PR             |\n| Reachable in default config | Yes                                                                                 |\n| Entry point                 | `git push` over smart-HTTP or SSH with multiple refs in a single operation          |\n\nThe attacker gains full write access to the victim\u0027s repository \u2014 equivalent to having push permissions on all refs. By controlling the order of refs in the batch (e.g., naming the granted branch so it sorts first), the attacker reliably ensures the legitimate ref is evaluated before the target. This is not a race condition; it is deterministic.\n\n### Reproduction Steps\n\n**Environment**\nThe issue was reproduced using Gitea v1.25.5 on Ubuntu 24.04.4 LTS.\n\n**Prerequisites:** \n* a Gitea instance with two users, `attacker` and `victim`.\n\n```bash\n# 1. Attacker creates a repository (e.g., a popular open-source project)\ncurl -X POST \"http://attacker:pw@\u003cgitea\u003e/api/v1/user/repos\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"name\": \"project\", \"auto_init\": true}\u0027\n\n# 2. Victim forks attacker\u0027s repository (standard contributor workflow)\ncurl -X POST \"http://victim:pw@\u003cgitea\u003e/api/v1/repos/attacker/project/forks\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{}\u0027\n\n# 3. Victim creates a feature branch on their fork and commits a change\ncurl -X POST \"http://victim:pw@\u003cgitea\u003e/api/v1/repos/victim/project/branches\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"new_branch_name\": \"feature-branch\", \"old_branch_name\": \"main\"}\u0027\n\ncurl -X POST \"http://victim:pw@\u003cgitea\u003e/api/v1/repos/victim/project/contents/contribution.txt\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"message\": \"Add contribution\", \"content\": \"\u0027$(echo -n \"victim contribution\" | base64)\u0027\", \"branch\": \"feature-branch\"}\u0027\n\n# 4. Victim opens a PR from their feature branch into attacker/project\n#    with \"Allow edits from maintainers\" enabled\ncurl -X POST \"http://victim:pw@\u003cgitea\u003e/api/v1/repos/attacker/project/pulls\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"title\": \"Feature PR\", \"head\": \"victim:feature-branch\", \"base\": \"main\", \"allow_maintainer_edit\": true}\u0027\n```\n\nAt this point, the attacker (as maintainer of the base repo `attacker/project`) has a per-branch write grant on the victim\u0027s fork, scoped to the `feature-branch` branch only.\n\n**Attack**\n\nThe attacker works from their own repo (`attacker/project`)\n```bash\n# 5. Attacker clones their own repo\ngit clone http://attacker:pw@\u003cgitea\u003e/attacker/project.git \u0026\u0026 cd project\n\n# 6. Attacker fetches the victim\u0027s PR branch\ngit fetch -u http://\u003cgitea\u003e/victim/project feature-branch:victim-feature-branch\ngit checkout victim-feature-branch\n\n# 7. Attacker adds a commit to the PR branch\necho \"legitimate change\" \u003e feature.txt \u0026\u0026 git add . \u0026\u0026 git commit -m \"PR update\"\n\n# 8. Attacker also prepares a malicious commit on main\ngit checkout main\necho \"MALICIOUS CONTENT\" \u003e PWNED \u0026\u0026 git add . \u0026\u0026 git commit -m \"pwned\"\n\n# 9. Attacker pushes both refs to the victim\u0027s fork in a single operation \u2014 this is the exploit\ngit push http://attacker:pw@\u003cgitea\u003e/victim/project.git victim-feature-branch:feature-branch main:main\n\n# 10. The change on both refs is visible regardless of PR status\n```\n\n**Expected result**: \n`main` should be rejected (\"User permission denied for writing\").\n\n**Actual result**: \nBoth refs are accepted. `victim/project:main` now contains the attacker\u0027s malicious commit.\n\n```bash\n# Verify: victim checks their fork\u0027s main branch\ncurl \"http://victim:pw@\u003cgitea\u003e/api/v1/repos/victim/project/contents/PWNED?ref=main\"\n# Returns attacker\u0027s \"MALICIOUS CONTENT\" \u2014 main has been overwritten\n```\n\nThe same technique also works for pushing arbitrary tags (`refs/tags/*`) and creating new branches.\n\n## Recommended Fix\n\nRemove the caching in `CanWriteCode()` \u2014 the `CanMaintainerWriteToBranch` check must be evaluated for every ref in the batch, not cached after the first call. The `checkedCanWriteCode` / `canWriteCode` fields on `preReceiveContext` and the guard in `CanWriteCode()` at `hook_pre_receive.go:55-64` should be removed, so the permission is evaluated fresh each time `preReceiveBranch` or `preReceiveTag` calls it. `loadPusherAndPermission()` already has its own caching (`loadedPusher`), so the per-call cost is limited to the `CanMaintainerWriteToBranch` query.\n\nSee [diff.patch](https://github.com/user-attachments/files/28831842/diff.patch) for the proposed fix.\n\nPatch provenance: AI-generated, human-reviewed.\n\n## Attribution\n\nThis vulnerability was discovered by Claude, Anthropic\u0027s AI assistant, and triaged by **Adrian Denkiewicz** at **Doyensec** in collaboration with Anthropic Research.\n\nFor CVE credits and public acknowledgments: **Doyensec in collaboration with Claude and Anthropic Research**",
  "id": "GHSA-649p-mmhf-85c7",
  "modified": "2026-07-21T21:43:11Z",
  "published": "2026-07-21T21:43:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-649p-mmhf-85c7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27775"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/99f8b3d9a1d32f4c39828e07971455a18191e0b9"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.3"
    }
  ],
  "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"
    }
  ],
  "summary": "Gitea: Cached Per-Branch Permission Check in Pre-Receive Hook Allows Full Repository Write"
}

GHSA-64H4-QMC6-6GW9

Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-07-22 21:32
VLAI
Details

An authenticated user with limited read privileges may be able to access documents from collections they are not authorized to read, due to an inconsistency in how the $graphLookup aggregation stage is evaluated during authorization and during execution. Affected scenarios involve collections referenced within existing view pipeline definitions.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-13060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T20:16:43Z",
    "severity": "HIGH"
  },
  "details": "An authenticated user with limited read privileges may be able to access documents from collections they are not authorized to read, due to an inconsistency in how the $graphLookup aggregation stage is evaluated during authorization and during execution. Affected scenarios involve collections referenced within existing view pipeline definitions.",
  "id": "GHSA-64h4-qmc6-6gw9",
  "modified": "2026-07-22T21:32:06Z",
  "published": "2026-07-22T21:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13060"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-127357"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-64X3-QR9C-W6JW

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38
VLAI
Details

Gitlab Community Edition version 10.3 is vulnerable to an improper authorization issue in the Oauth sign-in component resulting in unauthorized user login.

Severity
8.8 (High)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-0926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-21T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "Gitlab Community Edition version 10.3 is vulnerable to an improper authorization issue in the Oauth sign-in component resulting in unauthorized user login.",
  "id": "GHSA-64x3-qr9c-w6jw",
  "modified": "2022-05-13T01:38:24Z",
  "published": "2022-05-13T01:38:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0926"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/2018/01/16/gitlab-10-dot-3-dot-4-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab-ce/issues/32198"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4145"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-64XH-79J6-R5V8

Vulnerability from github – Published: 2026-07-22 22:06 – Updated: 2026-07-22 22:06
VLAI
Summary
n8n: Bypass "Allowed HTTP Request Domains" Credential Restriction in Multiple AI and LLM Nodes
Details

Impact

The credential "Allowed HTTP Request Domains" allowlist was intended to restrict which hosts a credential's secret could be sent to, protecting shared credentials from users who could use but not view them. Several AI/LLM nodes did not enforce this allowlist when a user-supplied base or endpoint URL was set. A low-privileged workflow editor with use-only access to such a shared credential could point one of these nodes at an attacker-controlled host and cause the credential secret to be transmitted there, then reuse it against the underlying service.

Only instances where a credential has "Allowed HTTP Request Domains" configured and is shared with non-owner users are affected.

Patches

The issue has been fixed in n8n versions 2.31.5 and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict workflow creation and editing permissions to fully trusted users only. - Restrict credential sharing to fully trusted users only. - Audit credentials with domain restrictions for unexpected sharing relationships.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.32.0"
            },
            {
              "fixed": "2.32.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.31.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:06:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nThe credential \"Allowed HTTP Request Domains\" allowlist was intended to restrict which hosts a credential\u0027s secret could be sent to, protecting shared credentials from users who could use but not view them. Several AI/LLM nodes did not enforce this allowlist when a user-supplied base or endpoint URL was set. A low-privileged workflow editor with use-only access to such a shared credential could point one of these nodes at an attacker-controlled host and cause the credential secret to be transmitted there, then reuse it against the underlying service.\n\nOnly instances where a credential has \"Allowed HTTP Request Domains\" configured and is shared with non-owner users are affected.\n\n## Patches\nThe issue has been fixed in n8n versions 2.31.5 and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict workflow creation and editing permissions to fully trusted users only.\n- Restrict credential sharing to fully trusted users only.\n- Audit credentials with domain restrictions for unexpected sharing relationships.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-64xh-79j6-r5v8",
  "modified": "2026-07-22T22:06:06Z",
  "published": "2026-07-22T22:06:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-64xh-79j6-r5v8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/f69dfc6dd2178a14ea1624d2e1d403c2e755042f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.31.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.32.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Bypass \"Allowed HTTP Request Domains\" Credential Restriction in Multiple AI and LLM Nodes"
}

GHSA-652X-M2GR-HPPM

Vulnerability from github – Published: 2025-07-30 16:21 – Updated: 2025-07-30 16:21
VLAI
Summary
OAuth2-Proxy's `--gitlab-group` GitLab Group Authorization config flag stopped working in v7.0.0
Details

The --gitlab-group flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release.

Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in --gitlab-group added to the new X-Forwarded-Groups header to the upstream application.

While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the --gitlab-group config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed.

Impact

This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of --gitlab-group membership restrictions.

Patches

This is patched in v7.1.0

Workarounds

There is no workaround for the Group membership bug. But --gitlab-project can be set to use Project membership as the authorization checks instead of groups; it is not broken.

Severity
5.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oauth2-proxy/oauth2-proxy/v7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21411"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-30T16:21:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "The `--gitlab-group` flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release.\n\nRegardless of the flag settings, authorization wasn\u0027t restricted. Additionally, any authenticated users had whichever groups were set in `--gitlab-group` added to the new `X-Forwarded-Groups` header to the upstream application.\n\nWhile adding GitLab project based authorization support in #630, a bug was introduced where the user session\u0027s groups field was populated with the `--gitlab-group` config entries instead of pulling the individual user\u0027s group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed.\n\n### Impact\nThis impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of `--gitlab-group` membership restrictions.\n\n### Patches\nThis is patched in v7.1.0\n\n### Workarounds\nThere is no workaround for the Group membership bug. But `--gitlab-project` can be set to use Project membership as the authorization checks instead of groups; it is not broken.",
  "id": "GHSA-652x-m2gr-hppm",
  "modified": "2025-07-30T16:21:04Z",
  "published": "2025-07-30T16:21:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-652x-m2gr-hppm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21411"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/commit/0279fa7dff1752f1710707dbd1ffac839de8bbfc"
    },
    {
      "type": "WEB",
      "url": "https://docs.gitlab.com/ee/user/group"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v7.1.0"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/github.com/oauth2-proxy/oauth2-proxy/v7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OAuth2-Proxy\u0027s `--gitlab-group` GitLab Group Authorization config flag stopped working in v7.0.0"
}

GHSA-656H-6G23-9XP5

Vulnerability from github – Published: 2025-12-10 06:30 – Updated: 2025-12-10 18:30
VLAI
Details

Unprotected service in the AudioLink component allows a local attacker to overwrite system files via unauthorized service invocation.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-9056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-10T04:15:58Z",
    "severity": "MODERATE"
  },
  "details": "Unprotected service in the AudioLink component allows a local attacker to overwrite system files via unauthorized service invocation.",
  "id": "GHSA-656h-6g23-9xp5",
  "modified": "2025-12-10T18:30:25Z",
  "published": "2025-12-10T06:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9056"
    },
    {
      "type": "WEB",
      "url": "https://security.tecno.com/SRC/securityUpdates"
    }
  ],
  "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-656Q-C3HC-863W

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details

An exploitable improper authorization vulnerability exists in miner_setEtherbase API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass.

Severity
8.1 (High)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-12115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-19T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable improper authorization vulnerability exists in miner_setEtherbase API of cpp-ethereum\u0027s JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass.",
  "id": "GHSA-656q-c3hc-863w",
  "modified": "2022-05-13T01:01:38Z",
  "published": "2022-05-13T01:01:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12115"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0467"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6574-P8RP-GXQH

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46
VLAI
Details

Red Hat 3scale (aka RH-3scale) API Management Platform (AMP) before 2.0.0 would permit creation of an access token without a client secret. An attacker could use this flaw to circumvent authentication controls and gain access to restricted APIs. NOTE: some sources have a typo in which CVE-2017-7512 maps to an OpenVPN vulnerability. The proper CVE ID for that OpenVPN vulnerability is CVE-2017-7521. Specifically, CVE-2017-7521 is the correct CVE ID for TWO closely related findings in OpenVPN. Any source that lists BOTH CVE-2017-7512 and CVE-2017-7521 for OpenVPN should have listed ONLY CVE-2017-7521.

Severity
9.8 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-7512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-07T22:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Red Hat 3scale (aka RH-3scale) API Management Platform (AMP) before 2.0.0 would permit creation of an access token without a client secret. An attacker could use this flaw to circumvent authentication controls and gain access to restricted APIs. NOTE: some sources have a typo in which CVE-2017-7512 maps to an OpenVPN vulnerability. The proper CVE ID for that OpenVPN vulnerability is CVE-2017-7521. Specifically, CVE-2017-7521 is the correct CVE ID for TWO closely related findings in OpenVPN. Any source that lists BOTH CVE-2017-7512 and CVE-2017-7521 for OpenVPN should have listed ONLY CVE-2017-7521.",
  "id": "GHSA-6574-p8rp-gxqh",
  "modified": "2022-05-13T01:46:59Z",
  "published": "2022-05-13T01:46:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7512"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:1712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/cve-2017-7512"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1457997"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
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.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list