| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Gitea versions before 1.25.5 allow draft release data or attachments to be accessed without the required write permission. |
| Gitea versions up to and including 1.26.2 allow repository RSS and Atom feed endpoints to bypass API access token scope checks, exposing private repository commit data to tokens without the required repository scope. |
| Gitea versions up to and including 1.26.1 have insufficient permission checks for Composer package source links, which can expose private or internal package source information. |
| Gitea 1.25.5 caches a branch-specific write-permission result across multiple refs in one pre-receive hook session, allowing a per-branch maintainer-edit grant to be reused for other refs and escalate to full repository write access. |
| Gitea versions before 1.25.5 accept malformed or injected forwarded-proto values when detecting public URLs, allowing spoofed canonical URL generation. |
| Gitea versions before 1.26.0 do not fail closed on bufio.Scanner errors while processing pre-receive hook input, allowing oversized input to bypass branch-protection checks. |
| Gitea versions up to and including 1.26.1 do not enforce repository-unit authorization on issue-template API endpoints. |
| Gitea versions up to and including 1.26.1 allow OAuth2 access token scope enforcement to be bypassed through HTTP Basic authentication. |
| Gitea versions before 1.25.5 use release tag names and asset names as filesystem path components when dumping release assets, allowing specially crafted names to affect dump output paths. |
| Gitea versions from 1.25.0 before 1.26.0 allow stored cross-site scripting through the extensionsRequired field in glTF files rendered by the 3D file viewer. |
| Gitea versions up to and including 1.26.2 allow Git LFS object reuse to authorize private source objects for users who have repository access but lack Code-unit access. |
| Gitea versions up to and including 1.26.1 allow Git smart HTTP requests authenticated with bearer tokens to bypass repository token scope checks. |
| A vulnerability in keras-team/keras version 3.14.0 allows for arbitrary code execution due to improper handling of deserialization in the `Lambda` layer. Specifically, the `_raise_for_lambda_deserialization()` function fails to enforce the safe-mode guard when `safe_mode` is set to `None`, which is the default value when `from_config()` is called outside of a `SafeModeScope` context. This logic error conflates `None` (unset/default-deny) with `False` (explicitly disabled), bypassing the guard and allowing attacker-controlled `marshal` bytecode to be deserialized. Affected call sites include `keras.layers.deserialize(config)`, `keras.models.clone_model(model)`, and any direct invocation of `Lambda.from_config(config)` without an enclosing `SafeModeScope(True)`. This vulnerability can be exploited to achieve arbitrary OS-level code execution in the context of the server or user process. |
| SSRF via HTTP Redirect in Repository Migration |
| Notification API leaks private issue metadata after access revocation |
| Unauthenticated ReDoS via CODEOWNERS pattern matching allows denial of service |
| Improper authorization on OAuth sign-in callback silently re-enables administrator-disabled accounts |
| LFS authentication bypass via malformed SSH sub-verb allows unauthorized read access to private repositories |
| Permanent Fork PR Workflow Approval Gate Bypass |
| Gitea Actions Artifacts V4 signed URL HMAC ambiguity allows cross-repository artifact read and cross-task upload-state write |
