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.

6795 vulnerabilities reference this CWE, most recent first.

GHSA-VQPP-QF88-72P9

Vulnerability from github – Published: 2026-09-07 18:31 – Updated: 2026-09-07 18:31
VLAI
Details

In JetBrains YouTrack before 2026.2.18634 improper permission checks allowed read-only users to create and modify whiteboard cards

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-86493"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-07T17:17:27Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains YouTrack before 2026.2.18634 improper permission checks allowed read-only users to create and modify whiteboard cards",
  "id": "GHSA-vqpp-qf88-72p9",
  "modified": "2026-09-07T18:31:33Z",
  "published": "2026-09-07T18:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86493"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQX2-FGX2-5WQ9

Vulnerability from github – Published: 2026-04-16 21:28 – Updated: 2026-04-27 16:08
VLAI
Summary
Official Clerk JavaScript SDKs: Middleware-based route protection bypass
Details

Summary

createRouteMatcher in @clerk/nextjs, @clerk/nuxt, and @clerk/astro can be bypassed by certain crafted requests, allowing them to skip middleware gating and reach downstream handlers.

Sessions are not compromised and no existing user can be impersonated - the bypass only affects the middleware-level gating decision.

Who is affected

All apps using createRouteMatcher should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps you understand whether you are potentially affected, but is not a reason to delay the upgrade.

Apps relying only on middleware gating via createRouteMatcher are affected, because a crafted request can skip middleware checks and reach downstream handlers (API routes, server components, etc.). This middleware pattern permits the bypass:

// Next.js example, equivalent patterns exist in Nuxt and Astro
const isProtectedRoute = createRouteMatcher(['/admin(.*)']);

export default clerkMiddleware(async (auth, req) => {
  if (isProtectedRoute(req)) {
    await auth.protect();
  }
});

That said, the bypass is limited to the middleware-level route-matching gate. clerkMiddleware still authenticates the request and auth() reflects the real authentication state of the caller. Auth checks performed inside your route handlers, server components, or server actions continue to work correctly and are not affected. Whether your app is affected in practice depends on whether you have those downstream checks.

External APIs that authenticate each request with a token are also unaffected on those endpoints, since token verification runs independently.

Additionally, this common middleware pattern correctly blocks the bypass at the middleware layer:

// Next.js example, equivalent patterns exist in Nuxt and Astro
const isPublicRoute = createRouteMatcher(['/docs(.*)']);

export default clerkMiddleware(async (auth, req) => {
  if (!isPublicRoute(req)) {
    await auth.protect();
  }
});

@clerk/shared is usually not imported directly in application code, but if you import createPathMatcher from an affected @clerk/shared version, you are also affected. Run npm why @clerk/shared (or your package manager's equivalent) to check your installed version.

Recommended actions

Install the patched version for your framework (pick the one matching your current major):

@clerk/nextjs - v7.x: fixed in 7.2.1 - v6.x: fixed in 6.39.2 - v5.x: fixed in 5.7.6

@clerk/nuxt - v2.x: fixed in 2.2.2 - v1.x: fixed in 1.13.28

@clerk/astro - v3.x: fixed in 3.0.15 - v2.x: fixed in 2.17.10 - v1.x: fixed in 1.5.7

@clerk/shared - v4.x: fixed in 4.8.1 - v3.x: fixed in 3.47.4 - v2.x: fixed in 2.22.1

Workaround

If you cannot upgrade immediately, adding server-side auth checks (auth()) inside your route handlers, server components, or server actions provides defense-in-depth against this bypass.

Timeline

This issue was reported on 13 APR 2026, patched on 15 APR 2026, and publicly disclosed on 15 APR 2026.

Thanks to Christiaan Swiers for the responsible disclosure of this vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.7.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "1.13.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.1"
            },
            {
              "fixed": "1.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/shared"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.20.17"
            },
            {
              "fixed": "2.22.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0-snapshot.vb87a27f"
            },
            {
              "fixed": "6.39.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.17.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-snapshot.v20241206174604"
            },
            {
              "fixed": "2.17.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/shared"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-canary.v20250225091530"
            },
            {
              "fixed": "3.47.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/shared"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:28:26Z",
    "nvd_published_at": "2026-04-24T21:16:18Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`createRouteMatcher` in `@clerk/nextjs`, `@clerk/nuxt`, and `@clerk/astro` can be bypassed by certain crafted requests, allowing them to skip middleware gating and reach downstream handlers.\n\nSessions are not compromised and no existing user can be impersonated - the bypass only affects the middleware-level gating decision.\n\n## Who is affected\n\nAll apps using `createRouteMatcher` should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps you understand whether you are potentially affected, but is not a reason to delay the upgrade.\n\nApps relying only on middleware gating via `createRouteMatcher` are affected, because a crafted request can skip middleware checks and reach downstream handlers (API routes, server components, etc.). This middleware pattern permits the bypass:\n\n```ts\n// Next.js example, equivalent patterns exist in Nuxt and Astro\nconst isProtectedRoute = createRouteMatcher([\u0027/admin(.*)\u0027]);\n\nexport default clerkMiddleware(async (auth, req) =\u003e {\n  if (isProtectedRoute(req)) {\n    await auth.protect();\n  }\n});\n```\n\nThat said, the bypass is limited to the middleware-level route-matching gate. `clerkMiddleware` still authenticates the request and `auth()` reflects the real authentication state of the caller. Auth checks performed inside your route handlers, server components, or server actions continue to work correctly and are not affected. Whether your app is affected in practice depends on whether you have those downstream checks.\n\nExternal APIs that authenticate each request with a token are also unaffected on those endpoints, since token verification runs independently.\n\nAdditionally, this common middleware pattern correctly blocks the bypass at the middleware layer:\n\n```ts\n// Next.js example, equivalent patterns exist in Nuxt and Astro\nconst isPublicRoute = createRouteMatcher([\u0027/docs(.*)\u0027]);\n\nexport default clerkMiddleware(async (auth, req) =\u003e {\n  if (!isPublicRoute(req)) {\n    await auth.protect();\n  }\n});\n```\n\n`@clerk/shared` is usually not imported directly in application code, but if you import `createPathMatcher` from an affected `@clerk/shared` version, you are also affected. Run `npm why @clerk/shared` (or your package manager\u0027s equivalent) to check your installed version.\n\n## Recommended actions\n\nInstall the patched version for your framework (pick the one matching your current major):\n\n**`@clerk/nextjs`**\n- v7.x: fixed in `7.2.1`\n- v6.x: fixed in `6.39.2`\n- v5.x: fixed in `5.7.6`\n\n**`@clerk/nuxt`**\n- v2.x: fixed in `2.2.2`\n- v1.x: fixed in `1.13.28`\n\n**`@clerk/astro`**\n- v3.x: fixed in `3.0.15`\n- v2.x: fixed in `2.17.10`\n- v1.x: fixed in `1.5.7`\n\n**`@clerk/shared`**\n- v4.x: fixed in `4.8.1`\n- v3.x: fixed in `3.47.4`\n- v2.x: fixed in `2.22.1`\n\n## Workaround\n\nIf you cannot upgrade immediately, adding server-side auth checks (`auth()`) inside your route handlers, server components, or server actions provides defense-in-depth against this bypass.\n\n## Timeline\n\nThis issue was reported on 13 APR 2026, patched on 15 APR 2026, and publicly disclosed on 15 APR 2026.\n\nThanks to [Christiaan Swiers](https://github.com/YouGina) for the responsible disclosure of this vulnerability.",
  "id": "GHSA-vqx2-fgx2-5wq9",
  "modified": "2026-04-27T16:08:38Z",
  "published": "2026-04-16T21:28:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/clerk/javascript/security/advisories/GHSA-vqx2-fgx2-5wq9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41248"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/clerk/javascript"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Official Clerk JavaScript SDKs: Middleware-based route protection bypass"
}

GHSA-VQX8-9XXW-F2M7

Vulnerability from github – Published: 2026-03-03 19:16 – Updated: 2026-03-30 13:37
VLAI
Summary
OpenClaw's voice-call Twilio webhook replay could bypass manager dedupe because normalized event IDs were randomized per parse
Details

Impact

Twilio webhook replay events could bypass voice-call manager dedupe because normalized event IDs were randomized per parse. A replayed event could be treated as new and trigger duplicate or stale call-state transitions.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Vulnerable versions: <= 2026.2.22-2
  • Patched version (released): >= 2026.2.23

Remediation

The fix preserves provider event IDs through normalization, adds bounded replay dedupe in webhook security validation, and enforces per-call turn-token checks on call-state transitions.

Fix Commit(s)

  • 1d28da55a5d0ff409e34999e0961157e9db0a2ab

Release Process Note

patched_versions is pre-set to the released version (2026.2.23) This advisory now reflects released fix version 2026.2.23.2.23`.

OpenClaw thanks @jiseoung for reporting.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T19:16:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\nTwilio webhook replay events could bypass voice-call manager dedupe because normalized event IDs were randomized per parse. A replayed event could be treated as new and trigger duplicate or stale call-state transitions.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Vulnerable versions: `\u003c= 2026.2.22-2`\n- Patched version (released): `\u003e= 2026.2.23`\n\n## Remediation\nThe fix preserves provider event IDs through normalization, adds bounded replay dedupe in webhook security validation, and enforces per-call turn-token checks on call-state transitions.\n\n## Fix Commit(s)\n- 1d28da55a5d0ff409e34999e0961157e9db0a2ab\n\n## Release Process Note\n`patched_versions` is pre-set to the released version (`2026.2.23`) This advisory now reflects released fix version `2026.2.23`.2.23`.\n\nOpenClaw thanks @jiseoung for reporting.",
  "id": "GHSA-vqx8-9xxw-f2m7",
  "modified": "2026-03-30T13:37:03Z",
  "published": "2026-03-03T19:16:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vqx8-9xxw-f2m7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32053"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1d28da55a5d0ff409e34999e0961157e9db0a2ab"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-twilio-webhook-replay-bypass-via-randomized-event-id-normalization"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s voice-call Twilio webhook replay could bypass manager dedupe because normalized event IDs were randomized per parse"
}

GHSA-VR2X-7687-H6QV

Vulnerability from github – Published: 2023-02-28 23:25 – Updated: 2023-03-01 01:55
VLAI
Summary
api-platform/core's secured properties may be accessible within collections
Details

Impact

Resource properties secured with the security option of the ApiPlatform\Metadata\ApiProperty attribute can be disclosed to unauthorized users. The problem affects most serialization formats, including raw JSON, which is enabled by default when installing API Platform. Custom serialization formats may also be impacted. Only collection endpoints are affected by the issue, item endpoints are not. The JSON-LD format is not affected by the issue.

The result of the security rule is only executed for the first item of the collection. The result of the rule is then cached and reused for the next items. This bug can leak data to unauthorized users when the rule depends on the value of a property of the item. This bug can also hide properties that should be displayed to authorized users.

Patches

This issue impacts the 2.7, 3.0 and 3.1 branches. Upgrade to v2.7.10, v3.0.12 or v3.1.3.

Workarounds

Replace the cache_key of the context array of the Serializer inside a custom normalizer that works on objects if the security option of the ApiPlatform\Metadata\ApiProperty attribute is used.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.7.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-25575"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-842",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-28T23:25:54Z",
    "nvd_published_at": "2023-02-28T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nResource properties secured with the `security` option of the `ApiPlatform\\Metadata\\ApiProperty` attribute can be disclosed to unauthorized users. The problem affects most serialization formats, including raw JSON, which is enabled by default when installing API Platform. Custom serialization formats may also be impacted. Only collection endpoints are affected by the issue, item endpoints are not. The JSON-LD format is not affected by the issue.\n\nThe result of the security rule is only executed for the first item of the collection. The result of the rule is then cached and reused for the next items. This bug can leak data to unauthorized users when the rule depends on the value of a property of the item. This bug can also hide properties that should be displayed to authorized users.\n\n### Patches\n\nThis issue impacts the 2.7, 3.0 and 3.1 branches. Upgrade to v2.7.10, v3.0.12 or v3.1.3.\n\n### Workarounds\n\nReplace the `cache_key` of the context array of the Serializer inside a custom normalizer that works on objects if the security option of the `ApiPlatform\\Metadata\\ApiProperty` attribute is used.",
  "id": "GHSA-vr2x-7687-h6qv",
  "modified": "2023-03-01T01:55:31Z",
  "published": "2023-02-28T23:25:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/api-platform/core/security/advisories/GHSA-vr2x-7687-h6qv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25575"
    },
    {
      "type": "WEB",
      "url": "https://github.com/api-platform/core/commit/5723d68369722feefeb11e42528d9580db5dd0fb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/api-platform/core/CVE-2023-25575.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/api-platform/core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/api-platform/core/releases/tag/v2.7.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/api-platform/core/releases/tag/v3.0.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/api-platform/core/releases/tag/v3.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "api-platform/core\u0027s secured properties may be accessible within collections"
}

GHSA-VR4Q-P49J-HQ95

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

An issue was discovered in freakchicken kafkaUI-lite 1.2.11 allows attackers on the same network to gain escalated privileges for the nodes running on it.

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-2023-27716"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-12T21:15:22Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in freakchicken kafkaUI-lite 1.2.11 allows attackers on the same network to gain escalated privileges for the nodes running on it.",
  "id": "GHSA-vr4q-p49j-hq95",
  "modified": "2024-04-04T04:44:30Z",
  "published": "2023-06-12T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27716"
    },
    {
      "type": "WEB",
      "url": "https://github.com/G-H-Z/CVE/blob/main/CVE-2023-27716"
    }
  ],
  "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-VR5R-FRMJ-8FWP

Vulnerability from github – Published: 2024-09-11 15:31 – Updated: 2024-09-11 15:31
VLAI
Details

An access control vulnerability was discovered in the Reports section due to a specific access restriction not being properly enforced for users with limited privileges.

If a logged-in user with reporting privileges learns how to create a specific application request, they might be able to make limited changes to the reporting configuration. This could result in a partial loss of data integrity. In Guardian/CMC instances with a reporting configuration, there could be limited Denial of Service (DoS) impacts, as the reports may not reach their intended destination, and there could also be limited information disclosure impacts. Furthermore, modifying the destination SMTP server for the reports could lead to the compromise of external credentials, as they might be sent to an unauthorized server.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-4465"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-11T15:15:18Z",
    "severity": "MODERATE"
  },
  "details": "An access control vulnerability was discovered in the Reports section due to a specific access restriction not being properly enforced for users with limited privileges.\n\n\n\nIf a logged-in user with reporting privileges learns how to create a specific application request, they might be able to make limited changes to the reporting configuration. This could result in a partial loss of data integrity. In Guardian/CMC instances with a reporting configuration, there could be limited Denial of Service (DoS) impacts, as the reports may not reach their intended destination, and there could also be limited information disclosure impacts. Furthermore, modifying the destination SMTP server for the reports could lead to the compromise of external credentials, as they might be sent to an unauthorized server.",
  "id": "GHSA-vr5r-frmj-8fwp",
  "modified": "2024-09-11T15:31:12Z",
  "published": "2024-09-11T15:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4465"
    },
    {
      "type": "WEB",
      "url": "https://security.nozominetworks.com/NN-2024:2-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:H/SI:H/SA:H/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-VRC4-QVRW-2552

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

An improper authorization vulnerability [CWE-285] in FortiClient for Windows versions 7.0.1 and below and 6.4.2 and below may allow a local unprivileged attacker to escalate their privileges to SYSTEM via the named pipe responsible for Forticlient updates.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-36183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-02T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper authorization vulnerability [CWE-285] in FortiClient for Windows versions 7.0.1 and below and 6.4.2 and below may allow a local unprivileged attacker to escalate their privileges to SYSTEM via the named pipe responsible for Forticlient updates.",
  "id": "GHSA-vrc4-qvrw-2552",
  "modified": "2022-05-24T19:19:24Z",
  "published": "2022-05-24T19:19:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36183"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/advisory/FG-IR-20-079"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRFH-RJ4Q-RMHR

Vulnerability from github – Published: 2026-05-08 20:00 – Updated: 2026-06-09 11:52
VLAI
Summary
Read-Only Open WebUI Users Can Modify Collaborative Documents via Socket.IO
Details

Read-Only Users Can Modify Collaborative Documents via Socket.IO

Affected Component

Socket.IO collaborative document editing handler: - backend/open_webui/socket/main.py (lines 667-721, ydoc:document:update handler)

Affected Versions

Current main branch and likely all versions with collaborative note editing.

Description

The ydoc:document:update Socket.IO event handler checks whether the sender is a member of the document's Socket.IO room (line 678) but does not verify that the sender has write permission. Users with read-only access join the document room via ydoc:document:join, which only requires read permission (line 520). Once in the room, the user can emit ydoc:document:update events that modify the in-memory Yjs document state and are broadcast to all other collaborators in real time.

The document_save_handler (line 600) correctly checks write permission before persisting to the database, so the attacker cannot directly save changes. However, the tampered content is visible to all collaborators, and if any user with write access saves the document, the injected content is persisted.

# ydoc:document:update handler (line 667) — only checks room membership, not write permission
async def on_document_update(sid, data):
    document_id = normalize_document_id(data.get('document_id', ''))
    # ...
    room = f'doc_{document_id}'
    if room not in sio.rooms(sid):  # Room membership check only
        return
    # Applies update to Yjs state and broadcasts to all users
    YDOC_MANAGER.apply_update(document_id, update)
    await sio.emit('ydoc:document:update', {...}, room=room, skip_sid=sid)

Compare with ydoc:document:join (line 520) which checks permission:

# Only checks READ permission — so read-only users join the room
if not has_access(user_id, type, id, 'read', db=db):
    return

CVSS 3.1 Breakdown

Metric Value Rationale
Attack Vector Network (N) Exploited remotely via Socket.IO events
Attack Complexity Low (L) No special conditions; attacker emits a standard Socket.IO event
Privileges Required Low (L) Requires a valid user account with read access to the shared note
User Interaction None (N) Modifications appear in real time without victim action; however, persistence requires a write-access user to save
Scope Unchanged (U) Impact is within the collaborative document context
Confidentiality None (N) No data disclosure beyond what read access already provides
Integrity Low (L) In-memory document state is modified and broadcast; persistence is indirect (requires another user to save)
Availability Low (L) Collaborative editing session can be disrupted with invalid content

Attack Scenario

  1. User A creates a note and shares it with User B with read permission.
  2. User B opens the note, which triggers ydoc:document:join — the server checks read permission and adds User B to the document room.
  3. User B emits ydoc:document:update with a crafted Yjs update payload via the Socket.IO connection (bypassing any frontend read-only enforcement).
  4. The server applies the update to the Yjs document state and broadcasts it to all collaborators.
  5. User A sees the injected content appear in their editor in real time.
  6. If User A saves the document (intentionally or via autosave), the tampered content is persisted to the database — User A's save passes the write permission check since User A is the owner.

Impact

  • Read-only users can inject, modify, or delete content in collaborative documents
  • Modifications are broadcast in real time to all collaborators, causing confusion or disruption
  • If a write-access user saves (including autosave), the tampered content is permanently persisted
  • Undermines the read/write permission model for collaborative editing

Preconditions

  • Attacker must have a valid user account with read access to a shared note
  • The note must be open for collaborative editing (at least one other user viewing it, or the attacker can wait for a write-access user to open and save)

Consolidation

This advisory covers read-only users modifying collaborative notes over Socket.IO. Two handlers were affected, both fixed in v0.9.0:

  • ydoc:document:update — checked only room membership, not write permission, so a read-only collaborator could inject in-memory document updates broadcast to other collaborators (persistence indirect). @Classic298.
  • document_save_handler — checked permission='read' while persisting via Notes.update_note_by_id, so a read-only collaborator could persist note changes directly. Reported by @hacnho

One CVE for the consolidated advisory.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.12"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T20:00:57Z",
    "nvd_published_at": "2026-05-15T20:16:48Z",
    "severity": "MODERATE"
  },
  "details": "# Read-Only Users Can Modify Collaborative Documents via Socket.IO\n\n## Affected Component\n\nSocket.IO collaborative document editing handler:\n- `backend/open_webui/socket/main.py` (lines 667-721, `ydoc:document:update` handler)\n\n## Affected Versions\n\nCurrent main branch and likely all versions with collaborative note editing.\n\n## Description\n\nThe `ydoc:document:update` Socket.IO event handler checks whether the sender is a member of the document\u0027s Socket.IO room (line 678) but does not verify that the sender has **write** permission. Users with read-only access join the document room via `ydoc:document:join`, which only requires `read` permission (line 520). Once in the room, the user can emit `ydoc:document:update` events that modify the in-memory Yjs document state and are broadcast to all other collaborators in real time.\n\nThe `document_save_handler` (line 600) correctly checks `write` permission before persisting to the database, so the attacker cannot directly save changes. However, the tampered content is visible to all collaborators, and if any user with write access saves the document, the injected content is persisted.\n\n```python\n# ydoc:document:update handler (line 667) \u2014 only checks room membership, not write permission\nasync def on_document_update(sid, data):\n    document_id = normalize_document_id(data.get(\u0027document_id\u0027, \u0027\u0027))\n    # ...\n    room = f\u0027doc_{document_id}\u0027\n    if room not in sio.rooms(sid):  # Room membership check only\n        return\n    # Applies update to Yjs state and broadcasts to all users\n    YDOC_MANAGER.apply_update(document_id, update)\n    await sio.emit(\u0027ydoc:document:update\u0027, {...}, room=room, skip_sid=sid)\n```\n\nCompare with `ydoc:document:join` (line 520) which checks permission:\n\n```python\n# Only checks READ permission \u2014 so read-only users join the room\nif not has_access(user_id, type, id, \u0027read\u0027, db=db):\n    return\n```\n\n## CVSS 3.1 Breakdown\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network (N) | Exploited remotely via Socket.IO events |\n| Attack Complexity | Low (L) | No special conditions; attacker emits a standard Socket.IO event |\n| Privileges Required | Low (L) | Requires a valid user account with read access to the shared note |\n| User Interaction | None (N) | Modifications appear in real time without victim action; however, persistence requires a write-access user to save |\n| Scope | Unchanged (U) | Impact is within the collaborative document context |\n| Confidentiality | None (N) | No data disclosure beyond what read access already provides |\n| Integrity | Low (L) | In-memory document state is modified and broadcast; persistence is indirect (requires another user to save) |\n| Availability | Low (L) | Collaborative editing session can be disrupted with invalid content |\n\n## Attack Scenario\n\n1. User A creates a note and shares it with User B with **read** permission.\n2. User B opens the note, which triggers `ydoc:document:join` \u2014 the server checks read permission and adds User B to the document room.\n3. User B emits `ydoc:document:update` with a crafted Yjs update payload via the Socket.IO connection (bypassing any frontend read-only enforcement).\n4. The server applies the update to the Yjs document state and broadcasts it to all collaborators.\n5. User A sees the injected content appear in their editor in real time.\n6. If User A saves the document (intentionally or via autosave), the tampered content is persisted to the database \u2014 User A\u0027s save passes the write permission check since User A is the owner.\n\n## Impact\n\n- Read-only users can inject, modify, or delete content in collaborative documents\n- Modifications are broadcast in real time to all collaborators, causing confusion or disruption\n- If a write-access user saves (including autosave), the tampered content is permanently persisted\n- Undermines the read/write permission model for collaborative editing\n\n## Preconditions\n\n- Attacker must have a valid user account with read access to a shared note\n- The note must be open for collaborative editing (at least one other user viewing it, or the attacker can wait for a write-access user to open and save)\n\n## Consolidation\n\nThis advisory covers read-only users modifying collaborative notes over Socket.IO. Two handlers were affected, both fixed in v0.9.0:\n\n- `ydoc:document:update` \u2014 checked only room membership, not write permission, so a read-only collaborator could inject in-memory document updates broadcast to other collaborators (persistence indirect). @Classic298.\n- `document_save_handler` \u2014 checked `permission=\u0027read\u0027` while persisting via `Notes.update_note_by_id`, so a read-only collaborator could persist note changes directly. Reported by @hacnho \n\nOne CVE for the consolidated advisory.",
  "id": "GHSA-vrfh-rj4q-rmhr",
  "modified": "2026-06-09T11:52:49Z",
  "published": "2026-05-08T20:00:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-vrfh-rj4q-rmhr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44564"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Read-Only Open WebUI Users Can Modify Collaborative Documents via Socket.IO"
}

GHSA-VRGC-533G-V7R4

Vulnerability from github – Published: 2022-06-07 00:00 – Updated: 2022-06-14 00:00
VLAI
Details

Incorrect authorization in GitLab EE affecting all versions from 12.0 before 14.9.5, all versions starting from 14.10 before 14.10.4, all versions starting from 15.0 before 15.0.1 allowed an attacker already in possession of a valid Project Deploy Token to misuse it from any location even when IP address restrictions were configured

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-1936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-06T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in GitLab EE affecting all versions from 12.0 before 14.9.5, all versions starting from 14.10 before 14.10.4, all versions starting from 15.0 before 15.0.1 allowed an attacker already in possession of a valid Project Deploy Token to misuse it from any location even when IP address restrictions were configured",
  "id": "GHSA-vrgc-533g-v7r4",
  "modified": "2022-06-14T00:00:28Z",
  "published": "2022-06-07T00:00:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1936"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1936.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/363638"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRHC-JJFC-M3M3

Vulnerability from github – Published: 2026-07-21 21:02 – Updated: 2026-07-21 21:02
VLAI
Summary
Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)
Details

Description

Gitea's OAuth2 sign-in callback reactivates a deactivated user account (IsActive=false) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without offline_access). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using "the stored refresh token is empty" as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets IsActive=true and grants a full session, silently undoing the administrator's action. This is the exact behavior #38009 was written to prevent. (ProhibitLogin, the hard ban, is enforced separately and is not affected.)

No special privileges are required beyond being the deactivated user and being able to sign in through the source.

Root Cause

routers/web/auth/oauth.go (the handleOAuth2SignIn reactivation gate):

if !u.IsActive {
    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)
    if err != nil { ctx.ServerError("GetExternalLogin", err); return }
    isDisabledByAutoSync := hasExt && extLogin.RefreshToken == ""   // wrong signal
    if isDisabledByAutoSync {
        opts.IsActive = optional.Some(true)                          // reactivates the account
    }
}

The assumption that RefreshToken == "" is produced only by the auto-sync cron is false:

  • The cron's disable path is unreachable for sources without refresh tokens. services/auth/source/oauth2/source_sync.go returns early: if !provider.RefreshTokenAvailable() { return ... }, so it never disables (or touches the tokens of) such users.
  • The stored token is exactly what the provider returned, with no synthesizing: services/externalaccount/user.go stores RefreshToken: gothUser.RefreshToken. When the provider issues none, this is "" from the first login.
  • GitHub never issues a refresh token: goth hardcodes func (p *Provider) RefreshTokenAvailable() bool { return false } (providers/github/github.go). OIDC/OAuth2 without offline_access likewise store "".

So for a GitHub (or no-refresh-token) source, RefreshToken == "" is the state of every user, including one an administrator deactivated, and the gate reactivates them.

Proof of Concept

Setup: - A Gitea instance with a GitHub authentication source (Admin Panel -> Authentication Sources -> OAuth2 -> GitHub), or any OAuth2/OIDC source configured without offline_access. - Account V: a normal user who has signed in at least once through that source (an external_login_user row exists with empty refresh_token).

Steps: 1. As an administrator, open Admin Panel -> Users -> V and uncheck "Activated" (is_active=false). Confirm V's requests now bounce to the activation page. 2. As V, sign in again via "Sign in with GitHub" and complete the provider flow. 3. V lands in the application with a working session. SELECT is_active FROM "user" WHERE lower_name='v'; now returns true.

Expected (intended by #38009): V stays is_active=false and is routed to the activation page. Actual: V is is_active=true with a full session — the administrator's deactivation is undone.

- GitHub user, ADMIN deactivated                 refreshToken=""    -> REACTIVATED + session granted   <<< admin action undone
- OIDC user w/ refresh token, ADMIN deactivated  refreshToken="..." -> stays disabled  (control)
- OIDC user, AUTO-SYNC cron disabled             refreshToken=""    -> REACTIVATED (intended)
RESULT: BYPASS CONFIRMED.

Gitea's own regression test TestOAuth2CallbackReactivationGating ("auto-sync-disabled user is reactivated") sets RefreshToken="" and asserts reactivation after a full OIDC callback — that state is identical to a GitHub-source user an administrator deactivated.

Impact

Any Gitea instance using a GitHub authentication source (one of the most common) or an OIDC/OAuth2 source without refresh tokens, that relies on the "Activated" toggle to disable accounts, is affected. A deactivated user restores their own account to active and obtains a session, regaining whatever access the account had. Deactivation does not clear IsAdmin, so a deactivated administrator regains admin access. Bound: accounts disabled with "Prohibit Login" stay blocked; this defeats the IsActive=false deactivation only.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T21:02:10Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Description\n\nGitea\u0027s OAuth2 sign-in callback reactivates a deactivated user account (`IsActive=false`) when the user signs in through an authentication source that does not issue refresh tokens (notably GitHub, and any OIDC/OAuth2 source configured without `offline_access`). PR #38009 added a gate intended to reactivate users only when the OAuth2 auto-sync cron had disabled them, using \"the stored refresh token is empty\" as the signal. That signal is wrong: for sources that never issue refresh tokens, an empty refresh token is the normal state of every user, so the gate cannot distinguish a cron-disabled account from one an administrator deliberately deactivated. The next time the administrator-deactivated user signs in through the provider, Gitea sets `IsActive=true` and grants a full session, silently undoing the administrator\u0027s action. This is the exact behavior #38009 was written to prevent. (`ProhibitLogin`, the hard ban, is enforced separately and is not affected.)\n\nNo special privileges are required beyond being the deactivated user and being able to sign in through the source.\n\n### Root Cause\n\n`routers/web/auth/oauth.go` (the `handleOAuth2SignIn` reactivation gate):\n\n```go\nif !u.IsActive {\n    extLogin, hasExt, err := user_model.GetExternalLogin(ctx, authSource.ID, gothUser.UserID)\n    if err != nil { ctx.ServerError(\"GetExternalLogin\", err); return }\n    isDisabledByAutoSync := hasExt \u0026\u0026 extLogin.RefreshToken == \"\"   // wrong signal\n    if isDisabledByAutoSync {\n        opts.IsActive = optional.Some(true)                          // reactivates the account\n    }\n}\n```\n\nThe assumption that `RefreshToken == \"\"` is produced only by the auto-sync cron is false:\n\n- The cron\u0027s disable path is unreachable for sources without refresh tokens. `services/auth/source/oauth2/source_sync.go` returns early: `if !provider.RefreshTokenAvailable() { return ... }`, so it never disables (or touches the tokens of) such users.\n- The stored token is exactly what the provider returned, with no synthesizing: `services/externalaccount/user.go` stores `RefreshToken: gothUser.RefreshToken`. When the provider issues none, this is `\"\"` from the first login.\n- GitHub never issues a refresh token: `goth` hardcodes `func (p *Provider) RefreshTokenAvailable() bool { return false }` (`providers/github/github.go`). OIDC/OAuth2 without `offline_access` likewise store `\"\"`.\n\nSo for a GitHub (or no-refresh-token) source, `RefreshToken == \"\"` is the state of every user, including one an administrator deactivated, and the gate reactivates them.\n\n### Proof of Concept\n\nSetup:\n- A Gitea instance with a GitHub authentication source (Admin Panel -\u003e Authentication Sources -\u003e OAuth2 -\u003e GitHub), or any OAuth2/OIDC source configured without `offline_access`.\n- Account V: a normal user who has signed in at least once through that source (an `external_login_user` row exists with empty `refresh_token`).\n\nSteps:\n1. As an administrator, open Admin Panel -\u003e Users -\u003e V and uncheck \"Activated\" (`is_active=false`). Confirm V\u0027s requests now bounce to the activation page.\n2. As V, sign in again via \"Sign in with GitHub\" and complete the provider flow.\n3. V lands in the application with a working session. `SELECT is_active FROM \"user\" WHERE lower_name=\u0027v\u0027;` now returns `true`.\n\nExpected (intended by #38009): V stays `is_active=false` and is routed to the activation page.\nActual: V is `is_active=true` with a full session \u2014 the administrator\u0027s deactivation is undone.\n\n```\n- GitHub user, ADMIN deactivated                 refreshToken=\"\"    -\u003e REACTIVATED + session granted   \u003c\u003c\u003c admin action undone\n- OIDC user w/ refresh token, ADMIN deactivated  refreshToken=\"...\" -\u003e stays disabled  (control)\n- OIDC user, AUTO-SYNC cron disabled             refreshToken=\"\"    -\u003e REACTIVATED (intended)\nRESULT: BYPASS CONFIRMED.\n```\n\nGitea\u0027s own regression test `TestOAuth2CallbackReactivationGating` (\"auto-sync-disabled user is reactivated\") sets `RefreshToken=\"\"` and asserts reactivation after a full OIDC callback \u2014 that state is identical to a GitHub-source user an administrator deactivated.\n\n### Impact\n\nAny Gitea instance using a GitHub authentication source (one of the most common) or an OIDC/OAuth2 source without refresh tokens, that relies on the \"Activated\" toggle to disable accounts, is affected. A deactivated user restores their own account to active and obtains a session, regaining whatever access the account had. Deactivation does not clear `IsAdmin`, so a deactivated administrator regains admin access. Bound: accounts disabled with \"Prohibit Login\" stay blocked; this defeats the `IsActive=false` deactivation only.",
  "id": "GHSA-vrhc-jjfc-m3m3",
  "modified": "2026-07-21T21:02:10Z",
  "published": "2026-07-21T21:02:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-vrhc-jjfc-m3m3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)"
}
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