Cloudreve v4's WOPI integration has a vulnerability where access tokens are improperly validated. The token format includes a session ID and a random secret suffix, but the system only validates the session ID prefix and ignores the secret suffix. Additionally, viewer sessions created for view-only actions can still perform write operations if the underlying file permissions allow it. This flaw allows an attacker with a valid session ID to forge tokens and write to files they should only be able to view.
This update includes the following RPMs:
cosign:
* cosign-3.1.2-0.2.hum1 (aarch64, x86_64)
* cosign-3.1.2-0.2.hum1.src (src)
Security Fix(es):
cosign:
* CVE-2026-56852
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-cxjq-mrr5-89rv. This link is maintained to preserve external references.
## Original Description
Traefik versions <= v2.11.51, >= v3.6.0 <= v3.6.22, and >= v3.7.0 <= v3.7.6 contain an authentication bypass via path traversal in the ReplacePathRegex middleware. When ReplacePathRegex is configured with a regex that captures user-controlled path segments without a mandatory path separator (e.g. regex "^/api(.*)", replacement "/$1"), the middleware forwards the replaced path to the backend without validating that it matches its normalized form. An unauthenticated remote attacker can send a crafted request (e.g. GET /api../admin) that produces an un-normalized path such as /../admin, which a backend that normalizes paths resolves to a protected route, bypassing authentication middleware. Fixed in v2.11.52, v3.6.23, and v3.7.7.
Gitea versions prior to 1.27.0 contain a vulnerability in the Arch package registry implementation where authenticated users with package publishing permissions can upload Arch package archives with an unbounded number of file entries. This causes resource amplification, leading to excessive consumption of CPU, memory, database storage, and repository index generation resources. The vulnerability impacts availability but does not affect confidentiality or integrity. A patch is available to address this issue.
Gitea versions prior to 1.27.0 contain a denial of service vulnerability in the Debian package registry parser. This flaw allows authenticated users with write access to upload malicious .deb packages that trigger excessive memory consumption through unbounded decompression. Additionally, inefficient O(N²) string concatenation in the parser causes high CPU usage, potentially stalling the server. The vulnerability can be exploited by any authenticated user with write permissions to the package registry.
Gitea versions prior to 1.27.0 contain a denial of service vulnerability in the NPM package tag API endpoint. The issue arises from an unbounded io.ReadAll call that reads the entire HTTP request body into memory without size limits. Authenticated users with write access to their package namespace can exploit this by sending a large request, causing the server process to crash due to out-of-memory conditions. This crash results in a persistent denial of service that can survive automatic restarts. The vulnerability has a moderate severity with a CVSS score of 6.5. A patch is available to address this issue.
Gitea versions prior to 1.27.0 contain a vulnerability where a fork pull-request Actions workflow can read a third private repository if that repository trusts the fork's base repository owner as a collaborative owner. This occurs due to a missing permission guard against fork pull-requests in the collaborative-owner branch, resulting in unauthorized read access. The vulnerability leads to a confidentiality breach exposing the full source code of a private repository to an untrusted fork PR author. A patch is available to address this issue.
Gitea contains a vulnerability in its API path for changing repository visibility from public to private. When this change is made via the REST API, stale watch records are not cleared, allowing users who lost access to still see metadata of the now-private repository in their subscription list. This leads to exposure of repository metadata and inflated watcher counts. The issue affects versions from v1.25.4 up to but not including v1.27.0. The severity is medium with limited confidentiality impact and no integrity or availability impact.
Gitea versions prior to 1.27.0 contain a vulnerability in the organization-level Actions API that allows any member of the organization to enumerate workflow runs and jobs across all repositories within that organization. This includes private repositories and repositories where the user lacks explicit permissions. The issue is due to missing repository-level access control checks in the API endpoints, which rely solely on organization membership for authorization.
Gitea versions prior to 1.27.0 have a vulnerability where webhook authorization headers, although stored encrypted in the database, are decrypted and returned in plaintext through certain API endpoints. This exposure allows repository or site administrators to view sensitive authorization headers such as Bearer tokens, Basic authentication credentials, and API keys set by other admins. The vulnerability affects multiple API endpoints that return webhook details and compromises the intended encryption-at-rest protection by revealing secrets in API responses.
Multiple security vulnerabilities in grpc-go affect the xDS RBAC authorization engine and HTTP/2 transport server. These include an authorization bypass due to unsupported RBAC policy matchers being ignored, a denial of service via high CPU consumption from HTTP/2 rapid reset mitigation bypass, and a server panic caused by parsing crafted RBAC policies with unsupported fields inside NOT rules. These issues can lead to unauthorized access, service crashes, or resource exhaustion. All vulnerabilities are fixed in grpc-go version 1.82.1.
A vulnerability in Gitea prior to version 1.27.0 allows personal access tokens restricted to the public-only scope to bypass intended access controls and retrieve private organization membership and permission details for the token owner's account. This occurs because certain API endpoints do not consistently enforce the public-only token restriction, exposing private organization data indirectly. The issue affects endpoints such as GET /api/v1/user/orgs and GET /api/v1/users/{username}/orgs/{org}/permissions, while direct access to private organizations remains blocked. A fix is available in Gitea version 1.27.0.
Gitea versions prior to 1.27.0 contain a server-side request forgery (SSRF) vulnerability in migration asset downloads and OAuth avatar updates. This occurs because certain code paths use unfiltered http.Get() calls that bypass the hostmatcher protection, allowing attackers with migration permissions to access internal services, cloud metadata endpoints, and local files via file:// URLs. The vulnerability enables theft of sensitive data such as cloud instance metadata and local configuration files containing credentials. A fix is available in version 1.27.0.
Gitea versions prior to 1.27.0 have a vulnerability where the 'public-only' API token restriction is not properly enforced on team API routes. This flaw allows a 'public-only' token, which should only access public repositories and organizations, to retrieve private team repository metadata and private team activity feed entries. The issue arises because the organization visibility check is bypassed due to missing context loading, and repository-level filtering is not applied. This vulnerability is confirmed in Gitea 1.26.2 and nightly builds and is fixed in version 1.27.0.
An incomplete fix in Gitea allows any authenticated user to enumerate all members of a private organization via the /members API endpoint. This issue affects versions up to and including 1.26.4 and the main branch. The vulnerability arises because the ListMembers function lacks a proper visibility check, exposing private member information to unauthorized users. A fix is available in version 1.27.0.
Gitea version prior to 1.26.4 contains an improper authorization vulnerability in the OAuth2 sign-in callback. When a user authenticates via a linked external identity provider, the system silently re-enables accounts that were disabled by an administrator, bypassing the intended administrative disable action. This allows the user to regain full access, including read/write permissions to repositories and organizations, by simply completing the OAuth callback. This flaw undermines the disable account feature used for incident response in SSO deployments.
Gitea Notification API in versions prior to 1.26.4 leaks private issue and pull request metadata through the 'subject' field of notification threads after a user's access to a private repository has been revoked. While the 'repository' field is correctly nulled, the 'subject' field still exposes sensitive information such as issue titles, URLs, state, and comment activity. This allows users who lost access to continue observing ongoing activity on private issues or pull requests via notifications.
Gitea versions prior to 1.27.0 contain two Server-Side Request Forgery (SSRF) vulnerabilities. The first involves an IP address classifier that fails to block certain address families, notably CGNAT (100.64.0.0/10), allowing authenticated users to create webhooks targeting internal CGNAT hosts and retrieve their HTTP responses. The second vulnerability allows unauthenticated users to trigger arbitrary GET requests to internal IPs via the OpenID sign-in form, which lacks IP filtering and authentication. Both issues are confirmed in version 1.26.2 and fixed in version 1.27.0.
Gitea versions prior to 1.27.0 contain a denial-of-service vulnerability in the Locale middleware that processes the Accept-Language HTTP header. The vulnerability arises because the middleware calls golang.org/x/text/language.ParseAcceptLanguage on unfiltered Accept-Language headers, which can contain large malformed language tag lists. The parser exhibits quadratic-time complexity when processing inputs with many underscore (_) separators, leading to excessive CPU consumption. This can be exploited by unauthenticated attackers sending crafted Accept-Language headers to cause high CPU usage and service degradation.
Gitea versions prior to 1.27.0 have a denial of service vulnerability in the SSH key ingestion endpoint. The flaw is due to an O(N²) string concatenation loop in the SSH2 key normalization function that lacks input size limits. An authenticated user can submit a maliciously large SSH2 formatted key, causing excessive CPU and memory usage that may take the server offline. This vulnerability is identified as CVE-2026-56657 and is classified as a moderate severity issue. A patch is available to address this vulnerability.