Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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.

5659 vulnerabilities reference this CWE, most recent first.

GHSA-2529-45PR-JCRG

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

Unintended Proxy or Intermediary ('Confused Deputy') (CWE-441) in Kibana can lead to unauthorized information exposure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Under certain conditions, a lower-privileged user can cause data from sources they are not authorized to access to be processed using another user's privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T20:17:01Z",
    "severity": "MODERATE"
  },
  "details": "Unintended Proxy or Intermediary (\u0027Confused Deputy\u0027) (CWE-441) in Kibana can lead to unauthorized information exposure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Under certain conditions, a lower-privileged user can cause data from sources they are not authorized to access to be processed using another user\u0027s privileges.",
  "id": "GHSA-2529-45pr-jcrg",
  "modified": "2026-07-21T21:32:39Z",
  "published": "2026-07-21T21:32:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49092"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-9-4-3-security-update-esa-2026-54/388553"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-254H-GVGQ-X2XG

Vulnerability from github – Published: 2024-09-12 18:31 – Updated: 2024-09-12 18:31
VLAI
Details

An issue was discovered in GitLab-EE starting with version 13.3 before 17.1.7, 17.2 before 17.2.5, and 17.3 before 17.3.2 that would allow an attacker to modify an on-demand DAST scan without permissions and leak variables.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-2743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-12T17:15:04Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in GitLab-EE starting with version 13.3 before 17.1.7, 17.2 before 17.2.5, and 17.3 before 17.3.2 that would allow an attacker to modify an on-demand DAST scan without permissions and leak variables.",
  "id": "GHSA-254h-gvgq-x2xg",
  "modified": "2024-09-12T18:31:41Z",
  "published": "2024-09-12T18:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2743"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2411756"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/451014"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-25G4-P347-X748

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2023-10-27 11:34
VLAI
Summary
Improper authorization due to caching in Jenkins Role-based Authorization Strategy Plugin
Details

Role-based Authorization Strategy Plugin 2.12 and newer uses a cache to speed up permission lookups. Role-based Authorization Strategy Plugin 3.0 and earlier this cache is not invalidated properly when an administrator changes the permission configuration. This can result in permissions being granted long after the configuration was changed to no longer grant them. Role-based Authorization Strategy Plugin 3.1 properly invalidates the cache on configuration changes.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:role-strategy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12"
            },
            {
              "fixed": "3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-2286"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-21T02:15:49Z",
    "nvd_published_at": "2020-10-08T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Role-based Authorization Strategy Plugin 2.12 and newer uses a cache to speed up permission lookups. Role-based Authorization Strategy Plugin 3.0 and earlier this cache is not invalidated properly when an administrator changes the permission configuration. This can result in permissions being granted long after the configuration was changed to no longer grant them. Role-based Authorization Strategy Plugin 3.1 properly invalidates the cache on configuration changes.",
  "id": "GHSA-25g4-p347-x748",
  "modified": "2023-10-27T11:34:02Z",
  "published": "2022-05-24T17:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2286"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2020-10-08/#SECURITY-1767"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/10/08/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper authorization due to caching in Jenkins Role-based Authorization Strategy Plugin"
}

GHSA-25JX-22X6-2CX2

Vulnerability from github – Published: 2022-11-15 12:00 – Updated: 2025-07-07 18:32
VLAI
Details

The Tenda AC1200 V-W15Ev2 V15.11.0.10(1576) router is vulnerable to improper authorization / improper session management that allows the router login page to be bypassed. This leads to authenticated attackers having the ability to read the routers syslog.log file which contains the MD5 password of the Administrator's user account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-40843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-15T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Tenda AC1200 V-W15Ev2 V15.11.0.10(1576) router is vulnerable to improper authorization / improper session management that allows the router login page to be bypassed. This leads to authenticated attackers having the ability to read the routers syslog.log file which contains the MD5 password of the Administrator\u0027s user account.",
  "id": "GHSA-25jx-22x6-2cx2",
  "modified": "2025-07-07T18:32:11Z",
  "published": "2022-11-15T12:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40843"
    },
    {
      "type": "WEB",
      "url": "https://boschko.ca/tenda_ac1200_router"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-25PW-4H6W-QWVM

Vulnerability from github – Published: 2026-03-03 22:54 – Updated: 2026-03-30 13:47
VLAI
Summary
OpenClaw has a BlueBubbles group allowlist mismatch via DM pairing-store fallback
Details

Summary

In openclaw@2026.2.25, BlueBubbles group authorization could incorrectly treat DM pairing-store identities as group allowlist identities when dmPolicy=pairing and groupPolicy=allowlist.

A sender that was only DM-paired (not explicitly present in groupAllowFrom) could pass group sender checks for message and reaction ingress.

Per OpenClaw's SECURITY.md trust model, this is a constrained authorization-consistency issue, not a multi-tenant boundary bypass or host-privilege escalation.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version at triage time: 2026.2.25
  • Affected versions: <= 2026.2.25
  • Patched versions: >= 2026.2.26 (planned next release)

Technical Details

Root cause was DM/group allowlist composition where DM pairing-store identities could flow into group authorization decisions.

Fix approach: - centralize DM/group authorization composition via shared resolvers - remove local DM/group list recomposition at channel callsites - add cross-channel regression coverage for message + reaction ingress - add CI guard to block future pairing-store leakage into group auth composition

Impact

  • Affects deployments using BlueBubbles with groupPolicy=allowlist and dmPolicy=pairing when pairing-store entries are present.
  • Could allow DM-authorized identities to be treated as group-authorized without explicit groupAllowFrom membership.
  • Does not bypass gateway auth, sandbox boundaries, or create new host-level privilege beyond existing DM authorization.

Fix Commit(s)

  • 051fdcc428129446e7c084260f837b7284279ce9

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.26) so once npm 2026.2.26 is published, this advisory can be published without further content edits.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T22:54:46Z",
    "nvd_published_at": "2026-03-19T22:16:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nIn `openclaw@2026.2.25`, BlueBubbles group authorization could incorrectly treat DM pairing-store identities as group allowlist identities when `dmPolicy=pairing` and `groupPolicy=allowlist`.\n\nA sender that was only DM-paired (not explicitly present in `groupAllowFrom`) could pass group sender checks for message and reaction ingress.\n\nPer OpenClaw\u0027s `SECURITY.md` trust model, this is a constrained authorization-consistency issue, not a multi-tenant boundary bypass or host-privilege escalation.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version at triage time: `2026.2.25`\n- Affected versions: `\u003c= 2026.2.25`\n- Patched versions: `\u003e= 2026.2.26` (planned next release)\n\n### Technical Details\nRoot cause was DM/group allowlist composition where DM pairing-store identities could flow into group authorization decisions.\n\nFix approach:\n- centralize DM/group authorization composition via shared resolvers\n- remove local DM/group list recomposition at channel callsites\n- add cross-channel regression coverage for message + reaction ingress\n- add CI guard to block future pairing-store leakage into group auth composition\n\n### Impact\n- Affects deployments using BlueBubbles with `groupPolicy=allowlist` and `dmPolicy=pairing` when pairing-store entries are present.\n- Could allow DM-authorized identities to be treated as group-authorized without explicit `groupAllowFrom` membership.\n- Does **not** bypass gateway auth, sandbox boundaries, or create new host-level privilege beyond existing DM authorization.\n\n### Fix Commit(s)\n- `051fdcc428129446e7c084260f837b7284279ce9`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`) so once npm `2026.2.26` is published, this advisory can be published without further content edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-25pw-4h6w-qwvm",
  "modified": "2026-03-30T13:47:34Z",
  "published": "2026-03-03T22:54:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-25pw-4h6w-qwvm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32006"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/051fdcc428129446e7c084260f837b7284279ce9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1aadf26f9acc399affabd859937a09468a9c5cb4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-dm-pairing-store-fallback-in-group-allowlist"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has a BlueBubbles group allowlist mismatch via DM pairing-store fallback"
}

GHSA-25VQ-XHX7-64Q5

Vulnerability from github – Published: 2025-11-01 06:30 – Updated: 2025-11-01 06:30
VLAI
Details

The Folderly plugin for WordPress is vulnerable to unauthorized modification of data due to an insufficient capability check on the /wp-json/folderly/v1/config/clear-all-data REST API endpoint in all versions up to, and including, 0.3. This makes it possible for authenticated attackers, with Author-level access and above, to clear all data like terms and categories.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-01T06:15:40Z",
    "severity": "MODERATE"
  },
  "details": "The Folderly plugin for WordPress is vulnerable to unauthorized modification of data due to an insufficient capability check on the /wp-json/folderly/v1/config/clear-all-data REST API endpoint in all versions up to, and including, 0.3. This makes it possible for authenticated attackers, with Author-level access and above, to clear all data like terms and categories.",
  "id": "GHSA-25vq-xhx7-64q5",
  "modified": "2025-11-01T06:30:36Z",
  "published": "2025-11-01T06:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12038"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3384176/folderly/trunk/includes/Rest#file0"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/81d43850-c6aa-4340-a0e0-41e04e958848?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-25X7-989G-366H

Vulnerability from github – Published: 2023-06-21 21:30 – Updated: 2024-04-04 04:59
VLAI
Details

A logic error in SiLabs Z/IP Gateway SDK 7.18.02 and earlier allows authentication to be bypassed, remote administration of Z-Wave controllers, and S0/S2 encryption keys to be recovered.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-0971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-268",
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-21T20:15:09Z",
    "severity": "HIGH"
  },
  "details": "A logic error in SiLabs Z/IP Gateway SDK 7.18.02 and earlier allows authentication to be bypassed, remote administration of Z-Wave controllers, and S0/S2 encryption keys to be recovered.",
  "id": "GHSA-25x7-989g-366h",
  "modified": "2024-04-04T04:59:31Z",
  "published": "2023-06-21T21:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0971"
    },
    {
      "type": "WEB",
      "url": "https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/0698Y00000V6HZzQAN?operationContext=S1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2623-9JVF-X9V2

Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-10-07 18:16
VLAI
Details

An authorization bypass vulnerability in Monitorr v1.7.6m in Monitorr/assets/config/_installation/_register.php allows an unauthorized person to create valid credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-28872"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-12T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An authorization bypass vulnerability in Monitorr v1.7.6m in Monitorr/assets/config/_installation/_register.php allows an unauthorized person to create valid credentials.",
  "id": "GHSA-2623-9jvf-x9v2",
  "modified": "2022-10-07T18:16:03Z",
  "published": "2022-05-24T17:47:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28872"
    },
    {
      "type": "WEB",
      "url": "https://lyhinslab.org/index.php/2020/09/12/how-the-white-box-hacking-works-authorization-bypass-and-remote-code-execution-in-monitorr-1-7-6"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/48981"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/163263/Monitorr-1.7.6m-Bypass-Information-Disclosure-Shell-Upload.html"
    }
  ],
  "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-266X-3X8X-XJ7X

Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-07-15 00:00
VLAI
Details

An improper authorization vulnerability in Palo Alto Networks Cortex XSOAR enables a remote unauthenticated attacker with network access to the Cortex XSOAR server to perform unauthorized actions through the REST API. This issue impacts: Cortex XSOAR 6.1.0 builds later than 1016923 and earlier than 1271064; Cortex XSOAR 6.2.0 builds earlier than 1271065. This issue does not impact Cortex XSOAR 5.5.0, Cortex XSOAR 6.0.0, Cortex XSOAR 6.0.1, or Cortex XSOAR 6.0.2 versions. All Cortex XSOAR instances hosted by Palo Alto Networks are upgraded to resolve this vulnerability. No additional action is required for these instances.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-3044"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-22T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An improper authorization vulnerability in Palo Alto Networks Cortex XSOAR enables a remote unauthenticated attacker with network access to the Cortex XSOAR server to perform unauthorized actions through the REST API. This issue impacts: Cortex XSOAR 6.1.0 builds later than 1016923 and earlier than 1271064; Cortex XSOAR 6.2.0 builds earlier than 1271065. This issue does not impact Cortex XSOAR 5.5.0, Cortex XSOAR 6.0.0, Cortex XSOAR 6.0.1, or Cortex XSOAR 6.0.2 versions. All Cortex XSOAR instances hosted by Palo Alto Networks are upgraded to resolve this vulnerability. No additional action is required for these instances.",
  "id": "GHSA-266x-3x8x-xj7x",
  "modified": "2022-07-15T00:00:18Z",
  "published": "2022-05-24T19:05:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3044"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2021-3044"
    }
  ],
  "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-268J-37XF-PP52

Vulnerability from github – Published: 2026-06-23 17:03 – Updated: 2026-07-21 13:39
VLAI
Summary
Gogs's write-level collaborators can mutate admin-only repository settings via API
Details

Summary

Three API endpoints — PATCH /api/v1/repos/:owner/:repo/issue-tracker, PATCH /api/v1/repos/:owner/:repo/wiki, and POST /api/v1/repos/:owner/:repo/mirror-sync — are gated by reqRepoWriter() rather than reqRepoAdmin(). The equivalent operations in the web UI sit behind reqRepoAdmin, which requires AccessMode >= AccessModeAdmin. A write-level collaborator (who has AccessMode == AccessModeWrite < AccessModeAdmin) can therefore call these API endpoints directly to disable the native issue tracker or wiki, inject attacker-controlled external tracker/wiki URLs that redirect all repository visitors, or trigger mirror sync — none of which they are authorized to do.

Severity

High (CVSS 3.1: 7.1)

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

  • Attack Vector: Network — the API endpoints are reachable over HTTP/S.
  • Attack Complexity: Low — a single API call is sufficient; no chaining or race condition required.
  • Privileges Required: Low — only write-level collaborator access to the targeted repository is needed. The attacker does not need repo-admin or site-admin privileges.
  • User Interaction: None — the attacker acts unilaterally.
  • Scope: Unchanged — the impact is contained to the targeted repository's settings and its visitors.
  • Confidentiality Impact: None — the attacker does not read confidential data directly.
  • Integrity Impact: High — the attacker permanently mutates repository configuration, including injecting an external URL that redirects all visitors who click the Issues or Wiki tabs to an attacker-controlled site.
  • Availability Impact: Low — disabling the native issue tracker or wiki reduces the availability of those features for all repository participants.

Affected component

  • internal/route/api/v1/api.go — route registration (lines 365–367)
  • internal/route/api/v1/repo_repo.goissueTracker() (line 400), wiki() (line 437), mirrorSync() (line 463)

CWE

  • CWE-863: Incorrect Authorization
  • CWE-269: Improper Privilege Management

Description

Three admin-equivalent API endpoints are protected by write-level middleware

api.go:365-367 registers the three settings endpoints with reqRepoWriter():

// internal/route/api/v1/api.go:365-367
m.Patch("/issue-tracker", reqRepoWriter(), bind(editIssueTrackerRequest{}), issueTracker)
m.Patch("/wiki", reqRepoWriter(), bind(editWikiRequest{}), wiki)
m.Post("/mirror-sync", reqRepoWriter(), mirrorSync)

reqRepoWriter() (defined at api.go:131-138) passes any user whose repository AccessMode >= AccessModeWrite:

func reqRepoWriter() macaron.Handler {
    return func(c *context.Context) {
        if !c.Repo.IsWriter() {
            c.Status(http.StatusForbidden)
            return
        }
    }
}

The handlers themselves perform no additional privilege check before mutating state:

// internal/route/api/v1/repo_repo.go:400-428
func issueTracker(c *context.APIContext, form editIssueTrackerRequest) {
    _, repo := parseOwnerAndRepo(c)
    ...
    if form.EnableExternalTracker != nil {
        repo.EnableExternalTracker = *form.EnableExternalTracker
    }
    if form.ExternalTrackerURL != nil {
        repo.ExternalTrackerURL = *form.ExternalTrackerURL   // ← attacker-controlled URL written directly
    }
    ...
    database.UpdateRepository(repo, false)   // ← no admin check before this call
}

The wiki() handler (lines 437–461) follows the same pattern, writing repo.ExternalWikiURL directly and calling UpdateRepository with no admin gate.

The web UI imposes a stricter admin requirement for the same operations

cmd/gogs/web.go:472 wraps the entire /settings subtree with reqRepoAdmin:

// cmd/gogs/web.go:425-472
m.Group("/:username/:reponame", func() {
    m.Group("/settings", func() {
        m.Combo("").Get(repo.Settings).
            Post(bindIgnErr(form.RepoSetting{}), repo.SettingsPost)
        ...
    }, ...)
}, reqSignIn, context.RepoAssignment(), reqRepoAdmin, context.RepoRef())

context.RequireRepoAdmin() (defined at context/repo.go:434-441) requires AccessMode >= AccessModeAdmin:

func RequireRepoAdmin() macaron.Handler {
    return func(c *Context) {
        if !c.IsLogged || (!c.Repo.IsAdmin() && !c.User.IsAdmin) {
            c.NotFound()
            return
        }
    }
}

In the access mode hierarchy, AccessModeWrite < AccessModeAdmin. A write-level collaborator satisfies reqRepoWriter() but does not satisfy RequireRepoAdmin(). The API path provides the write-level collaborator with capabilities that the UI correctly withholds.

Full execution chain

  1. Attacker precondition: Attacker is added as a repository collaborator with write access (AccessMode == AccessModeWrite).
  2. API call: PATCH /api/v1/repos/OWNER/REPO/issue-tracker with Authorization: token WRITER_TOKEN and body {"enable_external_tracker":true,"external_tracker_url":"https://attacker.example/phish"}.
  3. Middleware: reqRepoWriter() checks c.Repo.IsWriter()AccessMode >= AccessModeWrite → passes.
  4. Handler: issueTracker() sets repo.EnableExternalTracker = true and repo.ExternalTrackerURL = "https://attacker.example/phish", then calls database.UpdateRepository(repo, false). No admin check occurs.
  5. Impact: All visitors to the repository who click the "Issues" tab are redirected to the attacker's server. The native issue tracker is bypassed permanently until a repo admin reverses the change.

Proof of Concept

# Precondition: attacker is a collaborator with WRITE access, not repo admin.

# 1) Redirect the Issues tab to an attacker-controlled phishing page
curl -i -X PATCH "https://TARGET/api/v1/repos/OWNER/REPO/issue-tracker" \
  -H "Authorization: token WRITER_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"enable_issues":false,"enable_external_tracker":true,"external_tracker_url":"https://attacker.example/phish"}'
# Expected: HTTP 204 No Content

# 2) Redirect the Wiki tab to an attacker-controlled page
curl -i -X PATCH "https://TARGET/api/v1/repos/OWNER/REPO/wiki" \
  -H "Authorization: token WRITER_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"enable_wiki":false,"enable_external_wiki":true,"external_wiki_url":"https://attacker.example/phish-wiki"}'
# Expected: HTTP 204 No Content

# 3) Force a mirror sync on a mirrored repository (potential resource abuse)
curl -i -X POST "https://TARGET/api/v1/repos/OWNER/REPO/mirror-sync" \
  -H "Authorization: token WRITER_TOKEN"
# Expected: HTTP 202 Accepted

Impact

  • A write-level collaborator can permanently replace the native issue tracker with an external URL under attacker control, redirecting all repository visitors who follow the Issues link to a phishing or malware-serving page.
  • The same redirect attack applies to the Wiki tab via the external wiki URL setting.
  • Both redirects remain active until a repo admin or owner manually reverses the setting; the attacker has no way to be removed from having already made the change.
  • Mirror sync can be triggered repeatedly, potentially causing unnecessary load on the upstream mirror source or consuming network resources.
  • All three operations are silent — no notification is sent to repo admins when these settings change via the API.

Recommended remediation

Option 1: Change middleware to reqRepoAdmin() on all three endpoints (preferred)

Replace reqRepoWriter() with reqRepoAdmin() at the route registration level. This is a one-line change per endpoint and aligns the API authorization with the web UI's established policy.

// internal/route/api/v1/api.go:365-367
m.Patch("/issue-tracker", reqRepoAdmin(), bind(editIssueTrackerRequest{}), issueTracker)
m.Patch("/wiki", reqRepoAdmin(), bind(editWikiRequest{}), wiki)
m.Post("/mirror-sync", reqRepoAdmin(), mirrorSync)

Option 2: Add an explicit admin check inside the handlers

Add c.Repo.IsAdmin() checks at the top of issueTracker(), wiki(), and mirrorSync(). This is less preferred because it duplicates middleware logic in handler code, but it provides defense-in-depth if the route middleware is ever accidentally changed.

func issueTracker(c *context.APIContext, form editIssueTrackerRequest) {
    if !c.Repo.IsAdmin() {
        c.Status(http.StatusForbidden)
        return
    }
    ...
}

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52808"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T17:03:07Z",
    "nvd_published_at": "2026-06-24T21:16:56Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThree API endpoints \u2014 `PATCH /api/v1/repos/:owner/:repo/issue-tracker`, `PATCH /api/v1/repos/:owner/:repo/wiki`, and `POST /api/v1/repos/:owner/:repo/mirror-sync` \u2014 are gated by `reqRepoWriter()` rather than `reqRepoAdmin()`. The equivalent operations in the web UI sit behind `reqRepoAdmin`, which requires `AccessMode \u003e= AccessModeAdmin`. A write-level collaborator (who has `AccessMode == AccessModeWrite \u003c AccessModeAdmin`) can therefore call these API endpoints directly to disable the native issue tracker or wiki, inject attacker-controlled external tracker/wiki URLs that redirect all repository visitors, or trigger mirror sync \u2014 none of which they are authorized to do.\n\n## Severity\n\n**High** (CVSS 3.1: 7.1)\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L`\n\n- **Attack Vector:** Network \u2014 the API endpoints are reachable over HTTP/S.\n- **Attack Complexity:** Low \u2014 a single API call is sufficient; no chaining or race condition required.\n- **Privileges Required:** Low \u2014 only write-level collaborator access to the targeted repository is needed. The attacker does not need repo-admin or site-admin privileges.\n- **User Interaction:** None \u2014 the attacker acts unilaterally.\n- **Scope:** Unchanged \u2014 the impact is contained to the targeted repository\u0027s settings and its visitors.\n- **Confidentiality Impact:** None \u2014 the attacker does not read confidential data directly.\n- **Integrity Impact:** High \u2014 the attacker permanently mutates repository configuration, including injecting an external URL that redirects all visitors who click the Issues or Wiki tabs to an attacker-controlled site.\n- **Availability Impact:** Low \u2014 disabling the native issue tracker or wiki reduces the availability of those features for all repository participants.\n\n\n## Affected component\n\n- `internal/route/api/v1/api.go` \u2014 route registration (lines 365\u2013367)\n- `internal/route/api/v1/repo_repo.go` \u2014 `issueTracker()` (line 400), `wiki()` (line 437), `mirrorSync()` (line 463)\n\n## CWE\n\n- **CWE-863**: Incorrect Authorization\n- **CWE-269**: Improper Privilege Management\n\n## Description\n\n### Three admin-equivalent API endpoints are protected by write-level middleware\n\n`api.go:365-367` registers the three settings endpoints with `reqRepoWriter()`:\n\n```go\n// internal/route/api/v1/api.go:365-367\nm.Patch(\"/issue-tracker\", reqRepoWriter(), bind(editIssueTrackerRequest{}), issueTracker)\nm.Patch(\"/wiki\", reqRepoWriter(), bind(editWikiRequest{}), wiki)\nm.Post(\"/mirror-sync\", reqRepoWriter(), mirrorSync)\n```\n\n`reqRepoWriter()` (defined at `api.go:131-138`) passes any user whose repository `AccessMode \u003e= AccessModeWrite`:\n\n```go\nfunc reqRepoWriter() macaron.Handler {\n    return func(c *context.Context) {\n        if !c.Repo.IsWriter() {\n            c.Status(http.StatusForbidden)\n            return\n        }\n    }\n}\n```\n\nThe handlers themselves perform no additional privilege check before mutating state:\n\n```go\n// internal/route/api/v1/repo_repo.go:400-428\nfunc issueTracker(c *context.APIContext, form editIssueTrackerRequest) {\n    _, repo := parseOwnerAndRepo(c)\n    ...\n    if form.EnableExternalTracker != nil {\n        repo.EnableExternalTracker = *form.EnableExternalTracker\n    }\n    if form.ExternalTrackerURL != nil {\n        repo.ExternalTrackerURL = *form.ExternalTrackerURL   // \u2190 attacker-controlled URL written directly\n    }\n    ...\n    database.UpdateRepository(repo, false)   // \u2190 no admin check before this call\n}\n```\n\nThe `wiki()` handler (lines 437\u2013461) follows the same pattern, writing `repo.ExternalWikiURL` directly and calling `UpdateRepository` with no admin gate.\n\n### The web UI imposes a stricter admin requirement for the same operations\n\n`cmd/gogs/web.go:472` wraps the entire `/settings` subtree with `reqRepoAdmin`:\n\n```go\n// cmd/gogs/web.go:425-472\nm.Group(\"/:username/:reponame\", func() {\n    m.Group(\"/settings\", func() {\n        m.Combo(\"\").Get(repo.Settings).\n            Post(bindIgnErr(form.RepoSetting{}), repo.SettingsPost)\n        ...\n    }, ...)\n}, reqSignIn, context.RepoAssignment(), reqRepoAdmin, context.RepoRef())\n```\n\n`context.RequireRepoAdmin()` (defined at `context/repo.go:434-441`) requires `AccessMode \u003e= AccessModeAdmin`:\n\n```go\nfunc RequireRepoAdmin() macaron.Handler {\n    return func(c *Context) {\n        if !c.IsLogged || (!c.Repo.IsAdmin() \u0026\u0026 !c.User.IsAdmin) {\n            c.NotFound()\n            return\n        }\n    }\n}\n```\n\nIn the access mode hierarchy, `AccessModeWrite \u003c AccessModeAdmin`. A write-level collaborator satisfies `reqRepoWriter()` but does not satisfy `RequireRepoAdmin()`. The API path provides the write-level collaborator with capabilities that the UI correctly withholds.\n\n### Full execution chain\n\n1. **Attacker precondition**: Attacker is added as a repository collaborator with write access (`AccessMode == AccessModeWrite`).\n2. **API call**: `PATCH /api/v1/repos/OWNER/REPO/issue-tracker` with `Authorization: token WRITER_TOKEN` and body `{\"enable_external_tracker\":true,\"external_tracker_url\":\"https://attacker.example/phish\"}`.\n3. **Middleware**: `reqRepoWriter()` checks `c.Repo.IsWriter()` \u2192 `AccessMode \u003e= AccessModeWrite` \u2192 passes.\n4. **Handler**: `issueTracker()` sets `repo.EnableExternalTracker = true` and `repo.ExternalTrackerURL = \"https://attacker.example/phish\"`, then calls `database.UpdateRepository(repo, false)`. No admin check occurs.\n5. **Impact**: All visitors to the repository who click the \"Issues\" tab are redirected to the attacker\u0027s server. The native issue tracker is bypassed permanently until a repo admin reverses the change.\n\n## Proof of Concept\n\n```bash\n# Precondition: attacker is a collaborator with WRITE access, not repo admin.\n\n# 1) Redirect the Issues tab to an attacker-controlled phishing page\ncurl -i -X PATCH \"https://TARGET/api/v1/repos/OWNER/REPO/issue-tracker\" \\\n  -H \"Authorization: token WRITER_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  --data \u0027{\"enable_issues\":false,\"enable_external_tracker\":true,\"external_tracker_url\":\"https://attacker.example/phish\"}\u0027\n# Expected: HTTP 204 No Content\n\n# 2) Redirect the Wiki tab to an attacker-controlled page\ncurl -i -X PATCH \"https://TARGET/api/v1/repos/OWNER/REPO/wiki\" \\\n  -H \"Authorization: token WRITER_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  --data \u0027{\"enable_wiki\":false,\"enable_external_wiki\":true,\"external_wiki_url\":\"https://attacker.example/phish-wiki\"}\u0027\n# Expected: HTTP 204 No Content\n\n# 3) Force a mirror sync on a mirrored repository (potential resource abuse)\ncurl -i -X POST \"https://TARGET/api/v1/repos/OWNER/REPO/mirror-sync\" \\\n  -H \"Authorization: token WRITER_TOKEN\"\n# Expected: HTTP 202 Accepted\n```\n\n## Impact\n\n- A write-level collaborator can permanently replace the native issue tracker with an external URL under attacker control, redirecting all repository visitors who follow the Issues link to a phishing or malware-serving page.\n- The same redirect attack applies to the Wiki tab via the external wiki URL setting.\n- Both redirects remain active until a repo admin or owner manually reverses the setting; the attacker has no way to be removed from having already made the change.\n- Mirror sync can be triggered repeatedly, potentially causing unnecessary load on the upstream mirror source or consuming network resources.\n- All three operations are silent \u2014 no notification is sent to repo admins when these settings change via the API.\n\n## Recommended remediation\n\n### Option 1: Change middleware to `reqRepoAdmin()` on all three endpoints (preferred)\n\nReplace `reqRepoWriter()` with `reqRepoAdmin()` at the route registration level. This is a one-line change per endpoint and aligns the API authorization with the web UI\u0027s established policy.\n\n```go\n// internal/route/api/v1/api.go:365-367\nm.Patch(\"/issue-tracker\", reqRepoAdmin(), bind(editIssueTrackerRequest{}), issueTracker)\nm.Patch(\"/wiki\", reqRepoAdmin(), bind(editWikiRequest{}), wiki)\nm.Post(\"/mirror-sync\", reqRepoAdmin(), mirrorSync)\n```\n\n### Option 2: Add an explicit admin check inside the handlers\n\nAdd `c.Repo.IsAdmin()` checks at the top of `issueTracker()`, `wiki()`, and `mirrorSync()`. This is less preferred because it duplicates middleware logic in handler code, but it provides defense-in-depth if the route middleware is ever accidentally changed.\n\n```go\nfunc issueTracker(c *context.APIContext, form editIssueTrackerRequest) {\n    if !c.Repo.IsAdmin() {\n        c.Status(http.StatusForbidden)\n        return\n    }\n    ...\n}\n```\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-268j-37xf-pp52",
  "modified": "2026-07-21T13:39:55Z",
  "published": "2026-06-23T17:03:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-268j-37xf-pp52"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52808"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/pull/8327"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/6283462119bd8894f1599d70339b5e823f99954a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gogs\u0027s write-level collaborators can mutate admin-only repository settings via API"
}

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.