| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in Raera - Ankara Web Design and Digital Advertising Agency Destekz allows SQL Injection.
This issue affects Destekz: through 02062026. NOTE: The vendor was contacted and it was learned that the product is not supported. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Raera - Ankara Web Design and Digital Advertising Agency Destekz allows Reflected XSS.
This issue affects Destekz: through 02062026. NOTE: The vendor was contacted and it was learned that the product is not supported. |
| A vulnerability exists in the Kong Konnect Model Context Protocol (MCP) server prior to version 1.0.0, which could allow a remote attacker to perform an indirect prompt injection attack and execute unintended API requests. |
| Gitea versions up to and including 1.26.1 allow repository archive downloads to bypass token scope checks on the web archive download endpoint. |
| Gitea versions before 1.26.0 allow API users to fork a repository into an organization without first passing the CanCreateOrgRepo check, which can expose organization secrets. |
| 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 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 |
| Plack::Middleware::OAuth versions through 0.10 for Perl do not support the OAuth 2.0 state parameter.
RequestTokenV2 builds the provider authorization redirect without issuing a state value, and AccessTokenV2 exchanges the callback code and registers the resulting token into the session (register_session) without verifying that the callback corresponds to an authorization request this session initiated.
Any application that uses this middleware for OAuth 2.0 login is exposed to login cross-site request forgery: because the callback is not bound to the session that began the flow, an attacker who starts an authorization with their own provider account can deliver the resulting callback to a victim, causing the victim's session to complete the attacker's authorization and associating the attacker's provider identity and access token with that session. Where the application persists this as an account link, the attacker may retain access to the victim's account through their own provider credentials. |
