CWE-863
Allowed-with-ReviewIncorrect 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:32Unintended 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.
{
"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:31An 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.
{
"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:34Role-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.
{
"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:32The 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.
{
"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:47Summary
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=allowlistanddmPolicy=pairingwhen pairing-store entries are present. - Could allow DM-authorized identities to be treated as group-authorized without explicit
groupAllowFrommembership. - 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.
{
"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:30The 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.
{
"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:59A 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.
{
"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:16An authorization bypass vulnerability in Monitorr v1.7.6m in Monitorr/assets/config/_installation/_register.php allows an unauthorized person to create valid credentials.
{
"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:00An 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.
{
"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:39Summary
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.go—issueTracker()(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
- Attacker precondition: Attacker is added as a repository collaborator with write access (
AccessMode == AccessModeWrite). - API call:
PATCH /api/v1/repos/OWNER/REPO/issue-trackerwithAuthorization: token WRITER_TOKENand body{"enable_external_tracker":true,"external_tracker_url":"https://attacker.example/phish"}. - Middleware:
reqRepoWriter()checksc.Repo.IsWriter()→AccessMode >= AccessModeWrite→ passes. - Handler:
issueTracker()setsrepo.EnableExternalTracker = trueandrepo.ExternalTrackerURL = "https://attacker.example/phish", then callsdatabase.UpdateRepository(repo, false). No admin check occurs. - 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.
{
"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
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.