Summary: Crash when tunneling TCP over HTTP in Envoy

Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions of Envoy a crash occurs when configured for :ref:`upstream tunneling <envoy_v3_api_field_extensions.filters.network.tcp_proxy.v3.TcpProxy.tunneling_config>` and the downstream connection disconnects while the the upstream connection or http/2 stream is still being established. There are no workarounds for this issue. Users are advised to upgrade.


Summary: Incorrect configuration handling allows TLS session re-use without re-validation in Envoy

Envoy is an open source edge and service proxy, designed for cloud-native applications. Envoy's tls allows re-use when some cert validation settings have changed from their default configuration. The only workaround for this issue is to ensure that default tls settings are used. Users are advised to upgrade.


Summary: Incorrect handling of internal redirects results in crash in Envoy

Envoy is an open source edge and service proxy, designed for cloud-native applications. The envoy common router will segfault if an internal redirect selects a route configured with direct response or redirect actions. This will result in a denial of service. As a workaround turn off internal redirects if direct response entries are configured on the same listener.


Summary: X.509 subjectAltName matching bypass in Envoy

Envoy is an open source edge and service proxy, designed for cloud-native applications. The default_validator.cc implementation used to implement the default certificate validation routines has a "type confusion" bug when processing subjectAltNames. This processing allows, for example, an rfc822Name or uniformResourceIndicator to be authenticated as a domain name. This confusion allows for the bypassing of nameConstraints, as processed by the underlying OpenSSL/BoringSSL implementation, exposing the possibility of impersonation of arbitrary servers. As a result Envoy will trust upstream certificates that should not be trusted.


Summary: X.509 Extended Key Usage and Trust Purposes bypass in Envoy

Envoy is an open source edge and service proxy, designed for cloud-native applications. In affected versions Envoy does not restrict the set of certificates it accepts from the peer, either as a TLS client or a TLS server, to only those certificates that contain the necessary extendedKeyUsage (id-kp-serverAuth and id-kp-clientAuth, respectively). This means that a peer may present an e-mail certificate (e.g. id-kp-emailProtection), either as a leaf certificate or as a CA in the chain, and it will be accepted for TLS. This is particularly bad when combined with the issue described in pull request #630, in that it allows a Web PKI CA that is intended only for use with S/MIME, and thus exempted from audit or supervision, to issue TLS certificates that will be accepted by Envoy. As a result Envoy will trust upstream certificates that should not be trusted. There are no known workarounds to this issue. Users are advised to upgrade.


Summary: Crash when a cluster is deleted in Envoy

Envoy is an open source edge and service proxy, designed for cloud-native applications. When a cluster is deleted via Cluster Discovery Service (CDS) all idle connections established to endpoints in that cluster are disconnected. A recursion was introduced in the procedure of disconnecting idle connections that can lead to stack exhaustion and abnormal process termination when a cluster has a large number of idle connections. This infinite recursion causes Envoy to crash. Users are advised to upgrade.


Summary: Segmentation fault leading to crash in Envoy

Envoy is a cloud-native high-performance proxy. Versions of envoy prior to 1.22.1 are subject to a segmentation fault in the GrpcHealthCheckerImpl. Envoy can perform various types of upstream health checking. One of them uses gRPC. Envoy also has a feature which can “hold” (prevent removal) upstream hosts obtained via service discovery until configured active health checking fails. If an attacker controls an upstream host and also controls service discovery of that host (via DNS, the EDS API, etc.), an attacker can crash Envoy by forcing removal of the host from service discovery, and then failing the gRPC health check request. This will crash Envoy via a null pointer dereference. Users are advised to upgrade to resolve this vulnerability. Users unable to upgrade may disable gRPC health checking and/or replace it with a different health checking type as a mitigation.


Summary: Zip bomb vulnerability in Envoy

Envoy is a cloud-native high-performance proxy. In versions prior to 1.22.1 secompressors accumulate decompressed data into an intermediate buffer before overwriting the body in the decode/encodeBody. This may allow an attacker to zip bomb the decompressor by sending a small highly compressed payload. Maliciously constructed zip files may exhaust system memory and cause a denial of service. Users are advised to upgrade. Users unable to upgrade may consider disabling decompression.


Summary: Trivial authentication bypass in Envoy

Envoy is a cloud-native high-performance proxy. In versions prior to 1.22.1 the OAuth filter implementation does not include a mechanism for validating access tokens, so by design when the HMAC signed cookie is missing a full authentication flow should be triggered. However, the current implementation assumes that access tokens are always validated thus allowing access in the presence of any access token attached to the request. Users are advised to upgrade. There is no known workaround for this issue.


Summary: Use after free in Envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. In versions prior to 1.22.1 if Envoy attempts to send an internal redirect of an HTTP request consisting of more than HTTP headers, there’s a lifetime bug which can be triggered. If while replaying the request Envoy sends a local reply when the redirect headers are processed, the downstream state indicates that the downstream stream is not complete. On sending the local reply, Envoy will attempt to reset the upstream stream, but as it is actually complete, and deleted, this result in a use-after-free. Users are advised to upgrade. Users unable to upgrade are advised to disable internal redirects if crashes are observed.


Summary: Reachable assertion in Envoy

Envoy is a cloud-native high-performance proxy. In versions prior to 1.22.1 the OAuth filter would try to invoke the remaining filters in the chain after emitting a local response, which triggers an ASSERT() in newer versions and corrupts memory on earlier versions. continueDecoding() shouldn’t ever be called from filters after a local reply has been sent. Users are advised to upgrade. There are no known workarounds for this issue.


Summary: Envoy client may fake the header `x-envoy-original-path`

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, the client may bypass JSON Web Token (JWT) checks and forge fake original paths. The header `x-envoy-original-path` should be an internal header, but Envoy does not remove this header from the request at the beginning of request processing when it is sent from an untrusted client. The faked header would then be used for trace logs and grpc logs, as well as used in the URL used for `jwt_authn` checks if the `jwt_authn` filter is used, and any other upstream use of the x-envoy-original-path header. Attackers may forge a trusted `x-envoy-original-path` header. Versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9 have patches for this issue.


Summary: Envoy gRPC client produces invalid protobuf when an HTTP header with non-UTF8 value is received.

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, escalation of privileges is possible when `failure_mode_allow: true` is configured for `ext_authz` filter. For affected components that are used for logging and/or visibility, requests may not be logged by the receiving service.

When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this could have resulted in other unforeseen errors such as a lack of visibility into requests.

As of versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy by default sanitizes the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a `!` character. This behavioral change can be temporarily reverted by setting runtime guard `envoy.reloadable_features.service_sanitize_non_utf8_strings` to false. As a workaround, one may set `failure_mode_allow: false` for `ext_authz`.


Summary: Envoy forwards invalid Http2/Http3 downstream headers

Envoy is an open source edge and service proxy designed for cloud-native applications. Compliant HTTP/1 service should reject malformed request lines. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, There is a possibility that non compliant HTTP/1 service may allow malformed requests, potentially leading to a bypass of security policies. This issue is fixed in versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9.


Summary: Envoy may crash when a large request body is processed in Lua filter

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, the Lua filter is vulnerable to denial of service. Attackers can send large request bodies for routes that have Lua filter enabled and trigger crashes.

As of versions versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy no longer invokes the Lua coroutine if the filter has been reset. As a workaround for those whose Lua filter is buffering all requests/ responses, mitigate by using the buffer filter to avoid triggering the local reply in the Lua filter.


Summary: Envoy doesn't escape HTTP header values

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy does not sanitize or escape request properties when generating request headers. This can lead to characters that are illegal in header values to be sent to the upstream service. In the worst case, it can cause upstream service to interpret the original request as two pipelined requests, possibly bypassing the intent of Envoy’s security policy. Versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9 contain a patch. As a workaround, disable adding request headers based on the downstream request properties, such as downstream certificate properties.


Summary: Envoy may crash when a redirect url without a state param is received in the oauth filter

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, the OAuth filter assumes that a `state` query param is present on any response that looks like an OAuth redirect response. Sending it a request with the URI path equivalent to the redirect path, without the `state` parameter, will lead to abnormal termination of Envoy process. Versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9 contain a patch. The issue can also be mitigated by locking down OAuth traffic, disabling the filter, or by filtering traffic before it reaches the OAuth filter (e.g. via a lua script).


Summary: Envoy vulnerable to OAuth2 credentials exploit with permanent validity

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, a malicious client is able to construct credentials with permanent validity in some specific scenarios. This is caused by the some rare scenarios in which HMAC payload can be always valid in OAuth2 filter's check. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12 have a fix for this issue. As a workaround, avoid wildcards/prefix domain wildcards in the host's domain configuration.


Summary: Envoy's gRPC access log crash caused by the listener draining

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, gRPC access loggers using listener's global scope can cause a `use-after-free` crash when the listener is drained. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12 have a fix for this issue. As a workaround, disable gRPC access log or stop listener update.


Summary: Envoy vulnerable to CORS filter segfault when origin header is removed

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, the CORS filter will segfault and crash Envoy when the `origin` header is removed and deleted between `decodeHeaders`and `encodeHeaders`. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12 have a fix for this issue. As a workaround, do not remove the `origin` header in the Envoy configuration.


Summary: Envoy vulnerable to incorrect handling of HTTP requests and responses with mixed case schemes

Envoy is an open source edge and service proxy designed for cloud-native applications. Envoy allows mixed-case schemes in HTTP/2, however, some internal scheme checks are case-sensitive. Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, this can lead to the rejection of requests with mixed-case schemes such as `htTp` or `htTps`, or the bypassing of some requests such as `https` in unencrypted connections. With a fix in versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, Envoy will now lowercase scheme values by default, and change the internal scheme checks that were case-sensitive to be case-insensitive. There are no known workarounds for this issue.


Summary: Envoy vulnerable to HTTP/2 memory leak in nghttp2 codec

Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy’s HTTP/2 codec may leak a header map and bookkeeping structures upon receiving `RST_STREAM` immediately followed by the `GOAWAY` frames from an upstream server. In nghttp2, cleanup of pending requests due to receipt of the `GOAWAY` frame skips de-allocation of the bookkeeping structure and pending compressed header. The error return [code path] is taken if connection is already marked for not sending more requests due to `GOAWAY` frame. The clean-up code is right after the return statement, causing memory leak. Denial of service through memory exhaustion. This vulnerability was patched in versions(s) 1.26.3, 1.25.8, 1.24.9, 1.23.11.


The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.


Summary: Envoy crashes when idle and request per try timeout occur within the backoff interval

Envoy is a high-performance edge/middle/service proxy. Envoy will crash when certain timeouts happen within the same interval. The crash occurs when the following are true: 1. hedge_on_per_try_timeout is enabled, 2. per_try_idle_timeout is enabled (it can only be done in configuration), 3. per-try-timeout is enabled, either through headers or configuration and its value is equal, or within the backoff interval of the per_try_idle_timeout. This issue has been addressed in released 1.29.1, 1.28.1, 1.27.3, and 1.26.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Excessive CPU usage when URI template matcher is configured using regex in Envoy

Envoy is a high-performance edge/middle/service proxy. The regex expression is compiled for every request and can result in high CPU usage and increased request latency when multiple routes are configured with such matchers. This issue has been addressed in released 1.29.1, 1.28.1, 1.27.3, and 1.26.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Envoy ext auth can be bypassed when Proxy protocol filter sets invalid UTF-8 metadata

Envoy is a high-performance edge/middle/service proxy. External authentication can be bypassed by downstream connections. Downstream clients can force invalid gRPC requests to be sent to ext_authz, circumventing ext_authz checks when failure_mode_allow is set to true. This issue has been addressed in released 1.29.1, 1.28.1, 1.27.3, and 1.26.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Envoy crashes when using an address type that isn’t supported by the OS

Envoy is a high-performance edge/middle/service proxy. Envoy crashes in Proxy protocol when using an address type that isn’t supported by the OS. Envoy is susceptible to crashing on a host with IPv6 disabled and a listener config with proxy protocol enabled when it receives a request where the client presents its IPv6 address.  It is valid for a client to present its IPv6 address to a target server even though the whole chain is connected via IPv4. This issue has been addressed in released 1.29.1, 1.28.1, 1.27.3, and 1.26.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Envoy incorrectly accepts HTTP 200 response for entering upgrade mode

Envoy is a cloud-native, open source edge and service proxy. A theoretical request smuggling vulnerability exists through Envoy if a server can be tricked into adding an upgrade header into a response. Per RFC https://www.rfc-editor.org/rfc/rfc7230#section-6.7 a server sends 101 when switching protocols. Envoy incorrectly accepts a 200 response from a server when requesting a protocol upgrade, but 200 does not indicate protocol switch. This opens up the possibility of request smuggling through Envoy if the server can be tricked into adding the upgrade header to the response.


Summary: Crash in proxy protocol when command type of LOCAL in Envoy

Envoy is a high-performance edge/middle/service proxy. When PPv2 is enabled both on a listener and subsequent cluster, the Envoy instance will segfault when attempting to craft the upstream PPv2 header. This occurs when the downstream request has a command type of LOCAL and does not have the protocol block. This issue has been addressed in releases 1.29.1, 1.28.1, 1.27.3, and 1.26.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: HTTP/2: memory exhaustion due to CONTINUATION frame flood

Envoy is a cloud-native, open-source edge and service proxy. In versions 1.29.0 and 1.29.1, theEnvoy HTTP/2 protocol stack is vulnerable to the flood of CONTINUATION frames. Envoy's HTTP/2 codec does not reset a request when header map limits have been exceeded. This allows an attacker to send an sequence of CONTINUATION frames without the END_HEADERS bit set causing unlimited memory consumption. This can lead to denial of service through memory exhaustion. Users should upgrade to versions 1.29.2 to mitigate the effects of the CONTINUATION flood. Note that this vulnerability is a regression in Envoy version 1.29.0 and 1.29.1 only. As a workaround, downgrade to version 1.28.1 or earlier or disable HTTP/2 protocol for downstream connections.


Summary: HTTP/2: CPU exhaustion due to CONTINUATION frame flood

Envoy is a cloud-native, open source edge and service proxy. The HTTP/2 protocol stack in Envoy versions prior to 1.29.3, 1.28.2, 1.27.4, and 1.26.8 are vulnerable to CPU exhaustion due to flood of CONTINUATION frames. Envoy's HTTP/2 codec allows the client to send an unlimited number of CONTINUATION frames even after exceeding Envoy's header map limits. This allows an attacker to send a sequence of CONTINUATION frames without the END_HEADERS bit set causing CPU utilization, consuming approximately 1 core per 300Mbit/s of traffic and culminating in denial of service through CPU exhaustion. Users should upgrade to version 1.29.3, 1.28.2, 1.27.4, or 1.26.8 to mitigate the effects of the CONTINUATION flood. As a workaround, disable HTTP/2 protocol for downstream connections.


Summary: Envoy RELEASE_ASSERT using auto_sni with :authority header > 255 bytes

Envoy is a cloud-native, open source edge and service proxy. When an upstream TLS cluster is used with `auto_sni` enabled, a request containing a `host`/`:authority` header longer than 255 characters triggers an abnormal termination of Envoy process. Envoy does not gracefully handle an error when setting SNI for outbound TLS connection. The error can occur when Envoy attempts to use the `host`/`:authority` header value longer than 255 characters as SNI for outbound TLS connection. SNI length is limited to 255 characters per the standard. Envoy always expects this operation to succeed and abnormally aborts the process when it fails. This vulnerability is fixed in 1.30.1, 1.29.4, 1.28.3, and 1.27.5.


Summary: Envoy affected by a crash in EnvoyQuicServerStream::OnInitialHeadersComplete()

Envoy is a cloud-native, open source edge and service proxy. A crash was observed in `EnvoyQuicServerStream::OnInitialHeadersComplete()` with following call stack. It is a use-after-free caused by QUICHE continuing push request headers after `StopReading()` being called on the stream. As after `StopReading()`, the HCM's `ActiveStream` might have already be destroyed and any up calls from QUICHE could potentially cause use after free.


Summary: Envoy crashes in QuicheDataReader::PeekVarInt62Length()

Envoy is a cloud-native, open source edge and service proxy. There is a crash at `QuicheDataReader::PeekVarInt62Length()`. It is caused by integer underflow in the `QuicStreamSequencerBuffer::PeekRegion()` implementation.


Summary: Envoy can enter an endless loop while decompressing Brotli data with extra input

Envoy is a cloud-native, open source edge and service proxy. Envoyproxy with a Brotli filter can get into an endless loop during decompression of Brotli data with extra input.


Summary: Envoy affected by a crash (use-after-free) in EnvoyQuicServerStream

Envoy is a cloud-native, open source edge and service proxy. There is a use-after-free in `HttpConnectionManager` (HCM) with `EnvoyQuicServerStream` that can crash Envoy. An attacker can exploit this vulnerability by sending a request without `FIN`, then a `RESET_STREAM` frame, and then after receiving the response, closing the connection.


Summary: Envoy can crash due to uncaught nlohmann JSON exception

Envoy is a cloud-native, open source edge and service proxy. Due to how Envoy invoked the nlohmann JSON library, the library could throw an uncaught exception from downstream data if incomplete UTF-8 strings were serialized. The uncaught exception would cause Envoy to crash.


Summary: Envoy OOM vector from HTTP async client with unbounded response buffer for mirror response

Envoy is a cloud-native, open source edge and service proxy. Envoy exposed an out-of-memory (OOM) vector from the mirror response, since async HTTP client will buffer the response with an unbounded buffer.


Summary: Envoy Proxy use after free when route hash policy is configured with cookie attributes

Envoy is a cloud-native, open source edge and service proxy. Prior to versions 1.30.4, 1.29.7, 1.28.5, and 1.27.7. Envoy references already freed memory when route hash policy is configured with cookie attributes. Note that this vulnerability has been fixed in the open as the effect would be immediately apparent if it was configured. Memory allocated for holding attribute values is freed after configuration was parsed. During request processing Envoy will attempt to copy content of de-allocated memory into request cookie header. This can lead to arbitrary content of Envoy's memory to be sent to the upstream service or abnormal process termination. This vulnerability is fixed in Envoy versions v1.30.4, v1.29.7, v1.28.5, and v1.27.7. As a workaround, do not use cookie attributes in route action hash policy.


Summary: Potential manipulate `x-envoy` headers from external sources in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. A security vulnerability in Envoy allows external clients to manipulate Envoy headers, potentially leading to unauthorized access or other malicious actions within the mesh. This issue arises due to Envoy's default configuration of internal trust boundaries, which considers all RFC1918 private address ranges as internal. The default behavior for handling internal addresses in Envoy has been changed. Previously, RFC1918 IP addresses were automatically considered internal, even if the internal_address_config was empty.  The default configuration of Envoy will continue to trust internal addresses while in this release and it will not trust them by default in next release. If you have tooling such as probes on your private network which need to be treated as trusted (e.g. changing arbitrary x-envoy headers) please explicitly include those addresses or CIDR ranges into `internal_address_config`. Successful exploitation could allow attackers to bypass security controls, access sensitive data, or disrupt services within the mesh, like Istio. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: oghttp2 crash on OnBeginHeadersForStream in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy's 1.31 is using `oghttp` as the default HTTP/2 codec, and there are potential bugs around stream management in the codec. To resolve this Envoy will switch off the `oghttp2` by default. The impact of this issue is that envoy will crash. This issue has been addressed in release version 1.31.2. All users are advised to upgrade. There are no known workarounds for this issue.


Summary: Malicious log injection via access logs in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. A vulnerability has been identified in Envoy that allows malicious attackers to inject unexpected content into access logs. This is achieved by exploiting the lack of validation for the `REQUESTED_SERVER_NAME` field for access loggers. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Jwt filter crash in the clear route cache with remote JWKs in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. Jwt filter will lead to an Envoy crash when clear route cache with remote JWKs. In the following case: 1. remote JWKs are used, which requires async header processing; 2. clear_route_cache is enabled on the provider; 3. header operations are enabled in JWT filter, e.g. header to claims feature; 4. the routing table is configured in a way that the JWT header operations modify requests to not match any route. When these conditions are met, a crash is triggered in the upstream code due to nullptr reference conversion from route(). The root cause is the ordering of continueDecoding and clearRouteCache. This issue has been addressed in versions 1.31.2, 1.30.6, and 1.29.9. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Envoy crashes for LocalReply in http async client

Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy will crash when the http async client is handling `sendLocalReply` under some circumstance, e.g., websocket upgrade, and requests mirroring. The http async client will crash during the `sendLocalReply()` in http async client, one reason is http async client is duplicating the status code, another one is the destroy of router is called at the destructor of the async stream, while the stream is deferred deleted at first. There will be problems that the stream decoder is destroyed but its reference is called in `router.onDestroy()`, causing segment fault. This will impact ext_authz if the `upgrade` and `connection` header are allowed, and request mirrorring. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.


Summary: Happy Eyeballs: Validate that additional_address are IP addresses instead of crashing when sorting in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. When additional address are not ip addresses, then the Happy Eyeballs sorting algorithm will crash in data plane. This issue has been addressed in releases 1.32.2, 1.31.4, and 1.30.8. Users are advised to upgrade. Users unable to upgrade may disable Happy Eyeballs and/or change the IP configuration.


Summary: HTTP/1: sending overload crashes when the request is reset beforehand in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions `sendOverloadError` is going to assume the active request exists when `envoy.load_shed_points.http1_server_abort_dispatch` is configured. If `active_request` is nullptr, only onMessageBeginImpl() is called. However, the `onMessageBeginImpl` will directly return ok status if the stream is already reset leading to the nullptr reference. The downstream reset can actually happen during the H/2 upstream reset. As a result envoy may crash. This issue has been addressed in releases 1.32.3, 1.31.5, 1.30.9, and 1.29.12. Users are advised to upgrade. Users unable to upgrade may disable `http1_server_abort_dispatch` load shed point and/or use a high threshold.


Summary: HTTP/1.1 multiple issues with envoy.reloadable_features.http1_balsa_delay_reset in envoy

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions envoy  does not properly handle http 1.1 non-101 1xx responses. This can lead to downstream failures in networked devices. This issue has been addressed in versions 1.31.5 and 1.32.3. Users are advised to upgrade. There are no known workarounds for this issue.


A flaw was found in Envoy. It is possible to modify or manipulate headers from external clients when pass-through routes are used for the ingress gateway. This issue could allow a malicious user to forge what is logged by Envoy as a requested path and cause the Envoy proxy to make requests to internal-only services or arbitrary external systems. This is a regression of the fix for CVE-2023-27487.


Summary: Envoy crashes when HTTP ext_proc processes local replies

Envoy is a cloud-native high-performance edge/middle/service proxy. Prior to 1.33.1, 1.32.4, 1.31.6, and 1.30.10, Envoy's ext_proc HTTP filter is at risk of crashing if a local reply is sent to the external server due to the filter's life time issue. A known situation is the failure of a websocket handshake will trigger a local reply leading to the crash of Envoy. This vulnerability is fixed in 1.33.1, 1.32.4, 1.31.6, and 1.30.10.


Summary: Envoy vulnerable to bypass of RBAC uri_template permission

Envoy is a cloud-native edge/middle/service proxy. Prior to versions 1.34.1, 1.33.3, 1.32.6, and 1.31.8, Envoy's URI template matcher incorrectly excludes the `*` character from a set of valid characters in the URI path. As a result URI path containing the `*` character will not match a URI template expressions. This can result in bypass of RBAC rules when configured using the `uri_template` permissions. This vulnerability is fixed in Envoy versions v1.34.1, v1.33.3, v1.32.6, v1.31.8. As a workaround, configure additional RBAC permissions using `url_path` with `safe_regex` expression.


Summary: Envoy: Race condition in Dynamic Forward Proxy leads to use-after-free and segmentation faults

Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. Versions 1.34.0 through 1.34.4 and 1.35.0 contain a use-after-free (UAF) vulnerability in the DNS cache, causing abnormal process termination. The vulnerability is in Envoy's Dynamic Forward Proxy implementation, occurring when a completion callback for a DNS resolution triggers new DNS resolutions or removes existing pending resolutions. This condition may occur when the following conditions are met: dynamic Forwarding Filter is enabled, the `envoy.reloadable_features.dfp_cluster_resolves_hosts` runtime flag is enabled, and the Host header is modified between the Dynamic Forwarding Filter and Router filters. This issue is resolved in versions 1.34.5 and 1.35.1. To work around this issue, set the envoy.reloadable_features.dfp_cluster_resolves_hosts runtime flag to false.


Summary: Envoy: oAuth2 Filter Signout route will not clear cookies because of missing "secure;" flag

Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In versions below 1.32.10 and 1.33.0 through 1.33.6, 1.34.0 through 1.34.4 and 1.35.0, insufficient Session Expiration in the Envoy OAuth2 filter leads to failed logout operations. When configured with __Secure- or __Host- prefixed cookie names, the filter fails to append the required Secure attribute to the Set-Cookie header during deletion. Modern browsers ignore this invalid request, causing the session cookie to persist. This allows a user to remain logged in after they believe they have logged out, creating a session hijacking risk on shared computers. The current implementation iterates through the configured cookie names to generate deletion headers but does not check for these prefixes. This failure to properly construct the deletion header means the user's session cookies are never removed by the browser, leaving the session active and allowing the next user of the same browser to gain unauthorized access to the original user's account and data. This is fixed in versions 1.32.10, 1.33.7, 1.34.5 and 1.35.1.


Summary: Envoy allows large requests and responses to cause TCP connection pool crash

Envoy is a cloud-native, open source edge and service proxy. Prior to 1.36.1, 1.35.5, 1.34.9, and 1.33.10, large requests and responses can potentially trigger TCP connection pool crashes due to flow control management in Envoy. It will happen when the connection is closing but upstream data is still coming, resulting in a buffer watermark callback nullptr reference. The vulnerability impacts TCP proxy and HTTP 1 & 2 mixed use cases based on ALPN. This vulnerability is fixed in 1.36.1, 1.35.5, 1.34.9, and 1.33.10.


Summary: Envoy Lua filter use-after-free when oversized rewritten response body causes crash

Envoy is an open source edge and service proxy. Envoy versions earlier than 1.36.2, 1.35.6, 1.34.10, and 1.33.12 contain a use-after-free vulnerability in the Lua filter. When a Lua script executing in the response phase rewrites a response body so that its size exceeds the configured per_connection_buffer_limit_bytes (default 1MB), Envoy generates a local reply whose headers override the original response headers, leaving dangling references and causing a crash. This results in denial of service. Updating to versions 1.36.2, 1.35.6, 1.34.10, or 1.33.12 fixes the issue. Increasing per_connection_buffer_limit_bytes (and for HTTP/2 the initial_stream_window_size) or increasing per_request_buffer_limit_bytes / request_body_buffer_limit can reduce the likelihood of triggering the condition but does not correct the underlying memory safety flaw.


Envoy is a high-performance edge/middle/service proxy. In 1.33.12, 1.34.10, 1.35.6, 1.36.2, and earlier, Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails. This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object. The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.


Summary: Envoy forwards early CONNECT data in TCP proxy mode

Envoy is a high-performance edge/middle/service proxy. In 1.33.12, 1.34.10, 1.35.6, 1.36.2, and earlier, when Envoy is configured in TCP proxy mode to handle CONNECT requests, it accepts client data before issuing a 2xx response and forwards that data to the upstream TCP connection. If a forwarding proxy upstream from Envoy then responds with a non-2xx status, this can cause a de-synchronized CONNECT tunnel state. By default Envoy continues to allow early CONNECT data to avoid disrupting existing deployments. The envoy.reloadable_features.reject_early_connect_data runtime flag can be set to reject CONNECT requests that send data before a 2xx response when intermediaries upstream from Envoy may reject establishment of a CONNECT tunnel.


Summary: Envoy’s TLS certificate matcher for `match_typed_subject_alt_names` may incorrectly treat certificates containing an embedded null byte

Envoy is a high-performance edge/middle/service proxy. In 1.33.12, 1.34.10, 1.35.6, 1.36.2, and earlier, Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.


Summary: Envoy has an RBAC Header Validation Bypass via Multi-Value Header Concatenation

Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, the Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it validates HTTP headers when multiple values are present for the same header name. Instead of validating each header value individually, Envoy concatenates all values into a single comma-separated string. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms. This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.


Summary: Envoy has an off-by-one write in JsonEscaper::escapeString()

Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, an off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string. This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.


Summary: Crash for scoped ip address in Envoy during DNS

Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter. This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.


Summary: Envoy HTTP: filter chain execution on reset streams causing UAF crash

Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, a logic vulnerability in Envoy's HTTP connection manager (FilterManager) that allows for Zombie Stream Filter Execution. This issue creates a "Use-After-Free" (UAF) or state-corruption window where filter callbacks are invoked on an HTTP stream that has already been logically reset and cleaned up. The vulnerability resides in source/common/http/filter_manager.cc within the FilterManager::decodeData method. The ActiveStream object remains valid in memory during the deferred deletion window. If a DATA frame arrives on this stream immediately after the reset (e.g., in the same packet processing cycle), the HTTP/2 codec invokes ActiveStream::decodeData, which cascades to FilterManager::decodeData. FilterManager::decodeData fails to check the saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy(). This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.


Summary: Envoy global rate limit may crash when the response phase limit is enabled and the response phase request is failed directly

Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, At the rate limit filter, if the response phase limit with apply_on_stream_done in the rate limit configuration is enabled and the response phase limit request fails directly, it may crash Envoy. When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request. But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When a second limit request is sent at response phase, and the second limit request fails directly, the previous request's inner state may be accessed and result in crash. This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.


Summary: Improper Input Validation in etcd

In etcd before versions 3.3.23 and 3.4.10, a large slice causes panic in decodeRecord method. The size of a record is stored in the length field of a WAL file and no additional validation is done on this data. Therefore, it is possible to forge an extremely large frame size that can unintentionally panic at the expense of any RAFT participant trying to decode the WAL.


Summary: Improper Input Validation in etcd

In etcd before versions 3.3.23 and 3.4.10, it is possible to have an entry index greater then the number of entries in the ReadAll method in wal/wal.go. This could cause issues when WAL entries are being read during consensus as an arbitrary etcd consensus participant could go down from a runtime panic when reading the entry.


Summary: Improper Preservation of Permissions in etcd

In etcd before versions 3.3.23 and 3.4.10, certain directory paths are created (etcd data directory and the directory path when provided to automatically generate self-signed certificates for TLS connections with clients) with restricted access permissions (700) by using the os.MkdirAll. This function does not perform any permission checks when a given directory path exists already. A possible workaround is to ensure the directories have the desired permission (700).


Authentication vulnerability found in Etcd-io v.3.4.10 allows remote attackers to escalate privileges via the debug function.


Etcd v3.5.4 allows remote attackers to cause a denial of service via function PageWriter.write in pagewriter.go. NOTE: the vendor's position is that this is not a vulnerability.


Summary: etcd key name can be accessed via LeaseTimeToLive API

etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.26 and 3.5.9, the LeaseTimeToLive API allows access to key names (not value) associated to a lease when `Keys` parameter is true, even a user doesn't have read permission to the keys. The impact is limited to a cluster which enables auth (RBAC). Versions 3.4.26 and 3.5.9 fix this issue. There are no known workarounds.


Summary: etcd: Nested etcd transactions bypass RBAC authorization checks

etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, an authenticated user with RBAC restricted permissions on key ranges can use nested transactions to bypass all key-level authorization. This allows any authenticated user with direct access to etcd to effectively ignore all key range restrictions, accessing the entire etcd data store. Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected. Versions 3.4.42, 3.5.28, and 3.6.9 contain a patch. If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice. Restrict network access to etcd server ports so only trusted components can connect and require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution.


Summary: etcd: Authorization bypasses in multiple APIs

etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.42, 3.5.28, and 3.6.9, unauthorized users may bypass authentication or authorization checks and call certain etcd functions in clusters that expose the gRPC API to untrusted or partially trusted clients. In unpatched etcd clusters with etcd auth enabled, unauthorized users are able to call MemberList and learn cluster topology, including member IDs and advertised endpoints; call Alarm, which can be abused for operational disruption or denial of service; use Lease APIs, interfering with TTL-based keys and lease ownership; and/or trigger compaction, permanently removing historical revisions and disrupting watch, audit, and recovery workflows. Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected. Versions 3.4.42, 3.5.28, and 3.6.9 contain a patch. If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice. Restrict network access to etcd server ports so only trusted components can connect and/or require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution.


Summary: Apache Flink directory traversal attack: remote file writing through the REST API

Apache Flink 1.5.1 introduced a REST handler that allows you to write an uploaded file to an arbitrary location on the local file system, through a maliciously modified HTTP HEADER. The files can be written to any location accessible by Flink 1.5.1. All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed. The issue was fixed in commit a5264a6f41524afe8ceadf1d8ddc8c80f323ebc4 from apache/flink:master.


Summary: Apache Flink directory traversal attack: reading remote files through the REST API

A change introduced in Apache Flink 1.11.0 (and released in 1.11.1 and 1.11.2 as well) allows attackers to read any file on the local filesystem of the JobManager through the REST interface of the JobManager process. Access is restricted to files accessible by the JobManager process. All users should upgrade to Flink 1.11.3 or 1.12.0 if their Flink instance(s) are exposed. The issue was fixed in commit b561010b0ee741543c3953306037f00d7a9f0801 from apache/flink:master.


A vulnerability in Apache Flink (1.1.0 to 1.1.5, 1.2.0 to 1.2.1, 1.3.0 to 1.3.3, 1.4.0 to 1.4.2, 1.5.0 to 1.5.6, 1.6.0 to 1.6.4, 1.7.0 to 1.7.2, 1.8.0 to 1.8.3, 1.9.0 to 1.9.2, 1.10.0) where, when running a process with an enabled JMXReporter, with a port configured via metrics.reporter.reporter_name>.port, an attacker with local access to the machine and JMX port can execute a man-in-the-middle attack using a specially crafted request to rebind the JMXRMI registry to one under the attacker's control. This compromises any connection established to the process via JMX, allowing extraction of credentials and any other transferred data.


An issue was discovered in Fluent-ui v.1.2.2 allows attackers to gain escalated privileges and execute arbitrary code due to a default password.


Summary: ReDoS vulnerability in parser_apache2

Fluentd collects events from various data sources and writes them to files to help unify logging infrastructure. The parser_apache2 plugin in Fluentd v0.14.14 to v1.14.1 suffers from a regular expression denial of service (ReDoS) vulnerability. A broken apache log with a certain pattern of string can spend too much time in a regular expression, resulting in the potential for a DoS attack. This issue is patched in version 1.14.2 There are two workarounds available. Either don't use parser_apache2 for parsing logs (which cannot guarantee generated by Apache), or put patched version of parser_apache2.rb into /etc/fluent/plugin directory (or any other directories specified by the environment variable `FLUENT_PLUGIN` or `--plugin` option of fluentd).


Summary: Fluentd vulnerable to remote code execution due to insecure deserialization (in non-default configuration)

Fluentd collects events from various data sources and writes them to files, RDBMS, NoSQL, IaaS, SaaS, Hadoop and so on. A remote code execution (RCE) vulnerability in non-default configurations of Fluentd allows unauthenticated attackers to execute arbitrary code via specially crafted JSON payloads. Fluentd setups are only affected if the environment variable `FLUENT_OJ_OPTION_MODE` is explicitly set to `object`. Please note: The option FLUENT_OJ_OPTION_MODE was introduced in Fluentd version 1.13.2. Earlier versions of Fluentd are not affected by this vulnerability. This issue was patched in version 1.15.3. As a workaround do not use `FLUENT_OJ_OPTION_MODE=object`.


Summary: Improper kubeconfig validation allows arbitrary code execution

Flux2 is an open and extensible continuous delivery solution for Kubernetes. Flux2 versions between 0.1.0 and 0.29.0, helm-controller 0.1.0 to v0.19.0, and kustomize-controller 0.1.0 to v0.23.0 are vulnerable to Code Injection via malicious Kubeconfig. In multi-tenancy deployments this can also lead to privilege escalation if the controller's service account has elevated permissions. Workarounds include disabling functionality via Validating Admission webhooks by restricting users from setting the `spec.kubeConfig` field in Flux `Kustomization` and `HelmRelease` objects. Additional mitigations include applying restrictive AppArmor and SELinux profiles on the controller’s pod to limit what binaries can be executed. This vulnerability is fixed in kustomize-controller v0.23.0 and helm-controller v0.19.0, both included in flux2 v0.29.0


Summary: Improper path handling in kustomization files allows path traversal

Flux is an open and extensible continuous delivery solution for Kubernetes. Path Traversal in the kustomize-controller via a malicious `kustomization.yaml` allows an attacker to expose sensitive data from the controller’s pod filesystem and possibly privilege escalation in multi-tenancy deployments. Workarounds include automated tooling in the user's CI/CD pipeline to validate `kustomization.yaml` files conform with specific policies. This vulnerability is fixed in kustomize-controller v0.24.0 and included in flux2 v0.29.0.


Summary: Improper path handling in Kustomization files allows for denial of service

Flux is an open and extensible continuous delivery solution for Kubernetes. Path Traversal in the kustomize-controller via a malicious `kustomization.yaml` allows an attacker to cause a Denial of Service at the controller level. Workarounds include automated tooling in the user's CI/CD pipeline to validate `kustomization.yaml` files conform with specific policies. This vulnerability is fixed in kustomize-controller v0.24.0 and included in flux2 v0.29.0. Users are recommended to upgrade.


Summary: Flux CLI Workload Injection

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy. Flux CLI allows users to deploy Flux components into a Kubernetes cluster via command-line. The vulnerability allows other applications to replace the Flux deployment information with arbitrary content which is deployed into the target Kubernetes cluster instead. The vulnerability is due to the improper handling of user-supplied input, which results in a path traversal that can be controlled by the attacker. Users sharing the same shell between other applications and the Flux CLI commands could be affected by this vulnerability. In some scenarios no errors may be presented, which may cause end users not to realize that something is amiss. A safe workaround is to execute Flux CLI in ephemeral and isolated shell environments, which can ensure no persistent values exist from previous processes. However, upgrading to the latest version of the CLI is still the recommended mitigation strategy.


Summary: Flux2 Helm Controller denial of service

Flux2 is a tool for keeping Kubernetes clusters in sync with sources of configuration, and Flux's helm-controller is a Kubernetes operator that allows one to declaratively manage Helm chart releases. Helm controller is tightly integrated with the Helm SDK. A vulnerability found in the Helm SDK that affects flux2 v0.0.17 until v0.32.0 and helm-controller v0.0.4 until v0.23.0 allows for specific data inputs to cause high memory consumption. In some platforms, this could cause the controller to panic and stop processing reconciliations. In a shared cluster multi-tenancy environment, a tenant could create a HelmRelease that makes the controller panic, denying all other tenants from their Helm releases being reconciled. Patches are available in flux2 v0.32.0 and helm-controller v0.23.0.


Summary: Flux2 vulnerable to Denial of Service due to Improper use of metav1.Duration

Flux is an open and extensible continuous delivery solution for Kubernetes. Versions prior to 0.35.0 are subject to a Denial of Service. Users that have permissions to change Flux’s objects, either through a Flux source or directly within a cluster, can provide invalid data to fields `.spec.interval` or `.spec.timeout` (and structured variations of these fields), causing the entire object type to stop being processed. This issue is patched in version 0.35.0. As a workaround, Admission controllers can be employed to restrict the values that can be used for fields `.spec.interval` and `.spec.timeout`, however upgrading to the latest versions is still the recommended mitigation.


GDAL 3.3.0 through 3.4.0 has a heap-based buffer overflow in PCIDSK::CPCIDSKFile::ReadFromFile (called from PCIDSK::CPCIDSKSegment::ReadFromFile and PCIDSK::CPCIDSKBinarySegment::CPCIDSKBinarySegment).


Buffer Overflow vulnerability in gdal 3.10.2 allows a local attacker to cause a denial of service via the OGRSpatialReference::Release function. NOTE: the Supplier indicates that the report is invalid and could not be reproduced.


Server-side request forgery (SSRF) vulnerability in Ghost CMS < 3.10.0 allows an attacker to scan local or external network or otherwise interact with internal systems.


Summary: DOM XSS in Theme Preview

Ghost is a Node.js CMS. An unused endpoint added during the development of 4.0.0 has left sites vulnerable to untrusted users gaining access to Ghost Admin. Attackers can gain access by getting logged in users to click a link containing malicious code. Users do not need to enter credentials and may not know they've visited a malicious site. Ghost(Pro) has already been patched. We can find no evidence that the issue was exploited on Ghost(Pro) prior to the patch being added. Self-hosters are impacted if running Ghost a version between 4.0.0 and 4.3.2. Immediate action should be taken to secure your site. The issue has been fixed in 4.3.3, all 4.x sites should upgrade as soon as possible. As the endpoint is unused, the patch simply removes it. As a workaround blocking access to /ghost/preview can also mitigate the issue.


Summary: Privilege escalation: all users can access Admin-level API keys

Ghost is a Node.js content management system. An error in the implementation of the limits service between versions 4.0.0 and 4.9.4 allows all authenticated users (including contributors) to view admin-level API keys via the integrations API endpoint, leading to a privilege escalation vulnerability. This issue is patched in Ghost version 4.10.0. As a workaround, disable all non-Administrator accounts to prevent API access. It is highly recommended to regenerate all API keys after patching or applying the workaround.


An arbitrary file upload vulnerability in the file upload module of Ghost v4.39.0 allows attackers to execute arbitrary code via a crafted SVG file. NOTE: Vendor states that as outlined in Ghost's security documentation, upload of SVGs is only possible by trusted authenticated users. The uploading of SVG files to Ghost does not represent a remote code execution vulnerability. SVGs are not executable on the server, and may only execute javascript in a client's browser - this is expected and intentional functionality


An arbitrary file upload vulnerability in the file upload module of Ghost CMS v4.42.0 allows attackers to execute arbitrary code via a crafted file. NOTE: Vendor states as detailed in Ghost's security documentation, files can only be uploaded and published by trusted users, this is intentional


An authentication bypass vulnerability exists in the newsletter subscription functionality of Ghost Foundation Ghost 5.9.4. A specially-crafted HTTP request can lead to increased privileges. An attacker can send an HTTP request to trigger this vulnerability.


A user enumeration vulnerability exists in the login functionality of Ghost Foundation Ghost 5.9.4. A specially-crafted HTTP request can lead to a disclosure of sensitive information. An attacker can send a series of HTTP requests to trigger this vulnerability.


An insecure default vulnerability exists in the Post Creation functionality of Ghost Foundation Ghost 5.9.4. Default installations of Ghost allow non-administrator users to inject arbitrary Javascript in posts, which allow privilege escalation to administrator via XSS. To trigger this vulnerability, an attacker can send an HTTP request to inject Javascript in a post to trick an administrator into visiting the post.A stored XSS vulnerability exists in the `twitter` field for a user.


An insecure default vulnerability exists in the Post Creation functionality of Ghost Foundation Ghost 5.9.4. Default installations of Ghost allow non-administrator users to inject arbitrary Javascript in posts, which allow privilege escalation to administrator via XSS. To trigger this vulnerability, an attacker can send an HTTP request to inject Javascript in a post to trick an administrator into visiting the post.A stored XSS vulnerability exists in the `facebook` field for a user.


An insecure default vulnerability exists in the Post Creation functionality of Ghost Foundation Ghost 5.9.4. Default installations of Ghost allow non-administrator users to inject arbitrary Javascript in posts, which allow privilege escalation to administrator via XSS. To trigger this vulnerability, an attacker can send an HTTP request to inject Javascript in a post to trick an administrator into visiting the post.A stored XSS vulnerability exists in the `codeinjection_head` for a post.


An insecure default vulnerability exists in the Post Creation functionality of Ghost Foundation Ghost 5.9.4. Default installations of Ghost allow non-administrator users to inject arbitrary Javascript in posts, which allow privilege escalation to administrator via XSS. To trigger this vulnerability, an attacker can send an HTTP request to inject Javascript in a post to trick an administrator into visiting the post.A stored XSS vulnerability exists in the `codeinjection_foot` for a post.


Ghost 5.35.0 allows authorization bypass: contributors can view draft posts of other users, which is arguably inconsistent with a security policy in which a contributor's draft can only be read by editors until published by an editor. NOTE: the vendor's position is that this behavior has no security impact.


Summary: Ghost vulnerable to disclosure of private API fields

Ghost is an app for new-media creators with tools to build a website, publish content, send newsletters, and offer paid subscriptions to members. Prior to version 5.46.1, due to a lack of validation when filtering on the public API endpoints, it is possible to reveal private fields via a brute force attack.

Ghost(Pro) has already been patched. Maintainers can find no evidence that the issue was exploited on Ghost(Pro) prior to the patch being added. Self-hosters are impacted if running Ghost a version below v5.46.1. v5.46.1 contains a fix for this issue. As a workaround, add a block for requests to `/ghost/api/content/*` where the `filter` query parameter contains `password` or `email`.


Ghost before 5.42.1 allows remote attackers to read arbitrary files within the active theme's folder via /assets/built%2F..%2F..%2F/ directory traversal. This occurs in frontend/web/middleware/static-theme.js.


Summary: Arbitrary file read via symlinks in Ghost

Ghost is an open source content management system. Versions prior to 5.59.1 are subject to a vulnerability which allows authenticated users to upload files that are symlinks. This can be exploited to perform an arbitrary file read of any file on the host operating system. Site administrators can check for exploitation of this issue by looking for unknown symlinks within Ghost's `content/` folder. Version 5.59.1 contains a fix for this issue. All users are advised to upgrade. There are no known workarounds for this vulnerability.


Ghost through 5.76.0 allows stored XSS, and resultant privilege escalation in which a contributor can take over any account, via an SVG profile picture that contains JavaScript code to interact with the API on localhost TCP port 3001. NOTE: The discoverer reports that "The vendor does not view this as a valid vector."


Ghost before 5.76.0 allows XSS via a post excerpt in excerpt.js. An XSS payload can be rendered in post summaries.


Ghost before 5.82.0 allows CSV Injection during a member CSV export.


Ghost through 5.85.1 allows remote attackers to bypass an authentication rate-limit protection mechanism by using many X-Forwarded-For headers with different values. NOTE: the vendor's position is that Ghost should be installed with a reverse proxy that allows only trusted X-Forwarded-For headers.


Summary: Ghost's improper authentication allows access to member information and actions

Ghost is a Node.js content management system. Improper authentication on some endpoints used for member actions would allow an attacker to perform member-only actions, and read member information. This security vulnerability is present in Ghost 4.46.0 through 5.89.4. v5.89.5 contains a fix for this issue.


Summary: Ghost 6.0.6 - SSRF via oEmbed Bookmark

Server-Side Request Forgery (SSRF) vulnerability in Ghost allows an attacker to access internal resources.This issue affects Ghost: from 6.0.0 through 6.0.8, from 5.99.0 through 5.130.3.


Summary: Ghost has Staff 2FA bypass

Ghost is a Node.js content management system. In versions 5.105.0 through 5.130.5 and 6.0.0 through 6.10.3, a vulnerability in Ghost's 2FA mechanism allows staff users to skip email 2FA. This issue has been patched in versions 5.130.6 and 6.11.0.


Summary: Ghost has Staff Token permission bypass

Ghost is a Node.js content management system. In versions 5.121.0 through 5.130.5 and 6.0.0 through 6.10.3, a vulnerability in Ghost's handling of Staff Token authentication allowed certain endpoints to be accessed that were only intended to be accessible via Staff Session authentication. External systems that have been authenticated via Staff Tokens for Admin/Owner-role users would have had access to these endpoints. This issue has been patched in versions 5.130.6 and 6.11.0.


Summary: Ghost has SQL Injection in Members Activity Feed

Ghost is a Node.js content management system. In versions 5.90.0 through 5.130.5 and 6.0.0 through 6.10.3, a vulnerability in Ghost's /ghost/api/admin/members/events endpoint allows users with authentication credentials for the Admin API to execute arbitrary SQL. This issue has been patched in versions 5.130.6 and 6.11.0.


Summary: Ghost has SSRF via External Media Inliner

Ghost is a Node.js content management system. In versions 5.38.0 through 5.130.5 and 6.0.0 through 6.10.3, a vulnerability in Ghost’s media inliner mechanism allows staff users in possession of a valid authentication token for the Ghost Admin API to exfiltrate data from internal systems via SSRF. This issue has been patched in versions 5.130.6 and 6.11.0.


Summary: Ghost vulnerable to XSS via malicious Portal preview links

Ghost is an open source content management system. In Ghost versions 5.43.0 through 5.12.04 and 6.0.0 through 6.14.0, an attacker was able to craft a malicious link that, when accessed by an authenticated staff user or member, would execute JavaScript with the victim's permissions, potentially leading to account takeover. Ghost Portal versions 2.29.1 through 2.51.4 and 2.52.0 through 2.57.0 were vulnerable to this issue. Ghost automatically loads the latest patch of the members Portal component via CDN. For Ghost 5.x users, upgrading to v5.121.0 or later fixes the vulnerability. v5.121.0 loads Portal v2.51.5, which contains the patch. For Ghost 6.x users, upgrading to v6.15.0 or later fixes the vulnerability. v6.15.0 loads Portal v2.57.1, which contains the patch. For Ghost installations using a customized or self-hosted version of Portal, it will be necessary to manually rebuild from or update to the latest patch version.


Summary: Ghost has a SQL Injection in its Content API

Ghost is a Node.js content management system. Versions 3.24.0 through 6.19.0 allow unauthenticated attackers to perform arbitrary reads from the database. This issue has been fixed in version 6.19.1.


Summary: Ghost Vulnerable to Remote Code Execution via Malicious Themes

Ghost is a Node.js content management system. From version 0.7.2 to 6.19.0, specifically crafted malicious themes can execute arbitrary code on the server running Ghost. This issue has been patched in version 6.19.1.


Summary: Ghost: Incomplete CSRF protections around OTC use

Ghost is a Node.js content management system. From version 5.101.6 to 6.19.2, incomplete CSRF protections around /session/verify made it possible to use OTCs in login sessions different from the requesting session. In some scenarios this might have made it easier for phishers to take over a Ghost site. This issue has been patched in version 6.19.3.


Summary: malicious URLs may cause Git to present stored credentials to the wrong server

Affected versions of Git have a vulnerability whereby Git can be tricked into sending private credentials to a host controlled by an attacker. Git uses external "credential helper" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that contain an encoded newline can inject unintended values into the credential helper protocol stream, causing the credential helper to retrieve the password for one server (e.g., good.example.com) for an HTTP request being made to another server (e.g., evil.example.com), resulting in credentials for the former being sent to the latter. There are no restrictions on the relationship between the two, meaning that an attacker can craft a URL that will present stored credentials for any host to a host of their choosing. The vulnerability can be triggered by feeding a malicious URL to git clone. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git. The problem has been patched in the versions published on April 14th, 2020, going back to v2.17.x. Anyone wishing to backport the change further can do so by applying commit 9a6bbee (the full release includes extra checks for git fsck, but that commit is sufficient to protect clients against the vulnerability). The patched versions are: 2.17.4, 2.18.3, 2.19.4, 2.20.3, 2.21.2, 2.22.3, 2.23.2, 2.24.2, 2.25.3, 2.26.1.


Summary: Command Injection

The package git before 1.11.0 are vulnerable to Command Injection via git argument injection. When calling the fetch(remote = 'origin', opts = {}) function, the remote parameter is passed to the git fetch subcommand in a way that additional flags can be set. The additional flags can be used to perform a command injection.


Summary: Git's recursive clones on case-insensitive filesystems that support symlinks are susceptible to Remote Code Execution

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule's worktree but into a `.git/` directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is disabled in Git (e.g. via `git config --global core.symlinks false`), the described attack won't work. As always, it is best to avoid cloning repositories from untrusted sources.


Summary: Git vulnerable to Remote Code Execution while cloning special-crafted local repositories

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare a local repository in such a way that, when cloned, will execute arbitrary code during the operation. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid cloning repositories from untrusted sources.


Summary: Cloning local Git repository by untrusted user allows the untrusted user to modify objects in the cloned repository at will

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.


Summary: Local Git clone may hardlink arbitrary user-readable files into the new repository's "objects/" directory

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the `objects/` directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository's `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloning
will be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.


Summary: Git's protections for cloning untrusted repositories can be bypassed

Git is a revision control system. The Git project recommends to avoid working in untrusted repositories, and instead to clone it first with `git clone --no-local` to obtain a clean copy. Git has specific protections to make that a safe operation even with an untrusted source repository, but vulnerabilities allow those protections to be bypassed. In the context of cloning local repositories owned by other users, this vulnerability has been covered in CVE-2024-32004. But there are circumstances where the fixes for CVE-2024-32004 are not enough: For example, when obtaining a `.zip` file containing a full copy of a Git repository, it should not be trusted by default to be safe, as e.g. hooks could be configured to run within the context of that repository. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid using Git in repositories that have been obtained via archives from untrusted sources.


Summary: Git does not sanitize URLs when asking for credentials interactively

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When Git asks for credentials via a terminal prompt (i.e. without using any credential helper), it prints out the host name for which the user is expected to provide a username and/or a password. At this stage, any URL-encoded parts have been decoded already, and are printed verbatim. This allows attackers to craft URLs that contain ANSI escape sequences that the terminal interpret to confuse users e.g. into providing passwords for trusted Git hosting sites when in fact they are then sent to untrusted sites that are under the attacker's control. This issue has been patch via commits `7725b81` and `c903985` which are included in release versions v2.48.1, v2.47.2, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.


Summary: The sideband payload is passed unfiltered to the terminal in git

Git is a source code management tool. When cloning from a server (or fetching, or pushing), informational or error messages are transported from the remote Git process to the client via the so-called "sideband channel". These messages will be prefixed with "remote:" and printed directly to the standard error output. Typically, this standard error output is connected to a terminal that understands ANSI escape sequences, which Git did not protect against. Most modern terminals support control sequences that can be used by a malicious actor to hide and misrepresent information, or to mislead the user into executing untrusted scripts. As requested on the git-security mailing list, the patches are under discussion on the public mailing list. Users are advised to update as soon as possible. Users unable to upgrade should avoid recursive clones unless they are from trusted sources.


Summary: Newline confusion in credential helpers can lead to credential exfiltration in git

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. Git defines a line-based protocol that is used to exchange information between Git and Git credential helpers. Some ecosystems (most notably, .NET and node.js) interpret single Carriage Return characters as newlines, which renders the protections against CVE-2020-5260 incomplete for credential helpers that treat Carriage Returns in this way. This issue has been addressed in commit `b01b9b8` which is included in release versions v2.48.1, v2.47.2, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.


Summary: Git allows arbitrary code execution through broken config quoting

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When reading a config value, Git strips any trailing carriage return and line feed (CRLF). When writing a config entry, values with a trailing CR are not quoted, causing the CR to be lost when the config is later read. When initializing a submodule, if the submodule path contains a trailing CR, the altered path is read resulting in the submodule being checked out to an incorrect location. If a symlink exists that points the altered path to the submodule hooks directory, and the submodule contains an executable post-checkout hook, the script may be unintentionally executed after checkout. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.


Summary: Git alllows arbitrary file writes via bundle-uri parameter injection

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When cloning a repository Git knows to optionally fetch a bundle advertised by the remote server, which allows the server-side to offload parts of the clone to a CDN. The Git client does not perform sufficient validation of the advertised bundles, which allows the remote side to perform protocol injection. This protocol injection can cause the client to write the fetched bundle to a location controlled by the adversary. The fetched content is fully controlled by the server, which can in the worst case lead to arbitrary code execution. The use of bundle URIs is not enabled by default and can be controlled by the bundle.heuristic config option. Some cases of the vulnerability require that the adversary is in control of where a repository will be cloned to. This either requires social engineering or a recursive clone with submodules. These cases can thus be avoided by disabling recursive clones. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.


Summary: Git allows a buffer overflow in 'wincred' credential helper

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. The wincred credential helper uses a static buffer (target) as a unique key for storing and comparing against internal storage. This credential helper does not properly bounds check the available space remaining in the buffer before appending to it with wcsncat(), leading to potential buffer overflows. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.


An issue was discovered in Gitea through 1.11.5. An attacker can trigger a deadlock by initiating a transfer of a repository's ownership from one organization to another.


The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that the dangerousness of this feature should be documented immediately above the ENABLE_GIT_HOOKS line in the config file). NOTE: The vendor has indicated this is not a vulnerability and states "This is a functionality of the software that is limited to a very limited subset of accounts. If you give someone the privilege to execute arbitrary code on your server, they can execute arbitrary code on your server. We provide very clear warnings to users around this functionality and what it provides.


Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in modules/auth/repo_form.go.


Gitea 1.12.x and 1.13.x before 1.13.4 allows XSS via certain issue data in some situations.


The avatar middleware in Gitea before 1.13.6 allows Directory Traversal via a crafted URL.


Stack buffer overflow vulnerability in gitea 1.9.0 through 1.13.1 allows remote attackers to cause a denial of service (crash) via vectors related to a file path.


Server Side Request Forgery (SSRF) vulneraility exists in Gitea before 1.7.0 using the OpenID URL.


Cross Site Request Forgery (CSRF) vulnerability exists in Gitea before 1.5.2 via API routes.This can be dangerous especially with state altering POST requests.


Gitea before 1.11.2 is affected by Trusting HTTP Permission Methods on the Server Side when referencing the vulnerable admin or user API. which could let a remote malisious user execute arbitrary code.


Gitea before 1.4.3 is affected by URL Redirection to Untrusted Site ('Open Redirect') via internal URLs.


Cross Site Scripting (XSS) vulnerability exists in Gitea before 1.5.1 via the repository settings inside the external wiki/issue tracker URL field.


An issue exsits in Gitea through 1.15.7, which could let a malicious user gain privileges due to client side cookies not being deleted and the session remains valid on the server side for reuse.


An Authentication Bypass vulnerability exists in Gitea before 1.5.0, which could let a malicious user gain privileges. If captured, the TOTP code for the 2FA can be submitted correctly more than once.


Summary: Missing Authorization in go-gitea/gitea

Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4.


Summary: Open Redirect on login in go-gitea/gitea

Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5.


Summary: Cross-site Scripting (XSS) - Stored in go-gitea/gitea

Cross-site Scripting (XSS) - Stored in GitHub repository go-gitea/gitea prior to 1.16.9.


An arbitrary file deletion vulnerability in Gitea v1.16.3 allows attackers to cause a Denial of Service (DoS) via deleting the configuration file.


Gitea before 1.16.7 does not escape git fetch remote.


In Gitea before 1.16.9, it was possible for users to add existing issues to projects. Due to improper access controls, an attacker could assign any issue to any project in Gitea (there was no permission check for fetching the issue). As a result, the attacker would get access to private issue titles.


In Gitea through 1.17.1, repo cloning can occur in the migration function.


Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Arguments to git commands are mishandled.


In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log.


Summary: Open Redirect in go-gitea/gitea

Open Redirect in GitHub repository go-gitea/gitea prior to 1.19.4.


Gitea before 1.25.2 mishandles authorization for deletion of releases.


Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API.


In Gitea before 1.22.5, branch deletion permissions are not adequately enforced after merging a pull request.


Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources.


Gitea before 1.22.2 allows XSS because the search input box (for creating tags and branches) is v-html instead of v-text.


Gitea before 1.21.8 inadvertently discloses users' login times by allowing (for example) the lastlogintime explore/users sort order.


Gitea before 1.22.2 sometimes mishandles the propagation of token scope for access control within one of its own package registries.


In Gitea before 1.21.2, an anonymous user can visit a private user's project.


In Gitea before 1.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS.


In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists.


Summary: Gitea Release Email Notifications Leak Private Repository Release Details After Access Revocation

Gitea may send release notification emails for private repositories to users whose access has been revoked. When a repository is changed from public to private, users who previously watched the repository may continue to receive release notifications, potentially disclosing release titles, tags, and content.


Summary: Gitea Web Attachment Deletion: Cross-Repository Unauthorized Deletion via Missing Repo Ownership Check

Gitea does not properly verify repository context when deleting attachments. A user who previously uploaded an attachment to a repository may be able to delete it after losing access to that repository by making the request through a different repository they can access.


Summary: Gitea Organization Projects Cross-Organization Authorization Bypass via Project ID (IDOR)

Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization.


Summary: Notification API Leaks Private Repository Issue Titles After Collaborator Permission Revocation

Gitea's notification API does not re-validate repository access permissions when returning notification details. After a user's access to a private repository is revoked, they may still view issue and pull request titles through previously received notifications.


Summary: Gitea Stopwatch API Missing Authorization Check Leads to Post-Revocation Information Disclosure

Gitea's stopwatch API does not re-validate repository access permissions. After a user's access to a private repository is revoked, they may still view issue titles and repository names through previously started stopwatches.


Summary: Gitea Pull Requests Auto-Merge: Read-Only Users Can Cancel Scheduled Auto-Merge via Web Endpoint (Authorization Bypass)

Gitea does not properly verify authorization when canceling scheduled auto-merges via the web interface. A user with read access to pull requests may be able to cancel auto-merges scheduled by other users.


Summary: Gitea Git LFS Lock Deletion Broken Access Control (Cross-Repo IDOR)

Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.


Summary: Gitea: Broken access control in OpenID visibility toggle enables cross-user visibility changes

Gitea does not properly validate ownership when toggling OpenID URI visibility. An authenticated user may be able to change the visibility settings of other users' OpenID identities.


Summary: Gitea: Cross-Repository Authorization Bypass via Release Attachment Linking Leads to Private Attachment Disclosure

Gitea does not properly validate repository ownership when linking attachments to releases. An attachment uploaded to a private repository could potentially be linked to a release in a different public repository, making it accessible to unauthorized users.


GitLab EE 12.4.2 through 12.8.1 allows Denial of Service. It was internally discovered that a potential denial of service involving permissions checks could impact a project home page.


GitLab 10.1 through 12.8.1 has Incorrect Access Control. A scenario was discovered in which a GitLab account could be taken over through an expired link.


GitLab 12.5 through 12.8.1 allows HTML Injection. A particular error header was potentially susceptible to injection or potentially other vulnerabilities via unescaped input.


GitLab 12.1 through 12.8.1 allows XSS. A stored cross-site scripting vulnerability was discovered when displaying merge requests.


GitLab EE 3.0 through 12.8.1 allows SSRF. An internal investigation revealed that a particular deprecated service was creating a server side request forgery risk.


GitLab 12.1 through 12.8.1 allows XSS. The merge request submission form was determined to have a stored cross-site scripting vulnerability.


GitLab 7.10 through 12.8.1 has Incorrect Access Control. Under certain conditions where users should have been required to configure two-factor authentication, it was not being required.


GitLab 8.3 through 12.8.1 allows Information Disclosure. It was possible for certain non-members to access the Contribution Analytics page of a private group.


GitLab before 12.8.2 has Incorrect Access Control. It was internally discovered that the LFS import process could potentially be used to incorrectly access LFS objects not owned by the user.


GitLab 12.2 through 12.8.1 allows Denial of Service. A denial of service vulnerability impacting the designs for public issues was discovered.


GitLab 12.7 through 12.8.1 has Insecure Permissions. Under certain conditions involving groups, project authorization changes were not being applied.


GitLab EE 11.6 through 12.8.1 allows Information Disclosure. Sending a specially crafted request to the vulnerability_feedback endpoint could result in the exposure of a private project namespace


GitLab 12.3.5 through 12.8.1 allows Information Disclosure. A particular view was exposing merge private merge request titles.


GitLab 10.4 through 12.8.1 allows Directory Traversal. A particular endpoint was vulnerable to a directory traversal vulnerability, leading to arbitrary file read.


GitLab before 12.8.2 allows Information Disclosure. Badge images were not being proxied, causing mixed content warnings as well as leaking the IP address of the user.


GitLab 12.5 through 12.8.1 has Insecure Permissions. Depending on particular group settings, it was possible for invited groups to be given the incorrect permission level.


GitLab 8.11 through 12.8.1 allows a Denial of Service when using several features to recursively request eachother,


GitLab 11.7 through 12.8.1 allows Information Disclosure. Under certain group conditions, group epic information was unintentionally being disclosed.


GitLab 9.3 through 12.8.1 allows XSS. A cross-site scripting vulnerability was found when viewing particular file types.


GitLab 12.1 through 12.8.1 allows XSS. A cross-site scripting vulnerability was present in a particular view relating to the Grafana integration.


GitLab 12.8.x before 12.8.6, when sign-up is enabled, allows remote attackers to bypass email domain restrictions within the two-day grace period for an unconfirmed email address.


GitLab EE/CE 8.11 through 12.9.1 allows blocked users to pull/push docker images.


In GitLab EE 11.7 through 12.9, the NPM feature is vulnerable to a path traversal issue.


GitLab through 12.9 is affected by a potential DoS in repository archive download.


GitLab EE/CE 11.1 through 12.9 is vulnerable to parameter tampering on an upload feature that allows an unauthorized user to read content available under specific folders.


GitLab 8.10 and later through 12.9 is vulnerable to an SSRF in a project import note feature.


GitLab EE/CE 10.8 to 12.9 is leaking metadata and comments on vulnerabilities to unauthorized users on the vulnerability feedback page.


GitLab EE/CE 8.17 to 12.9 is vulnerable to information leakage when querying a merge request widget.


GitLab EE/CE 8.5 to 12.9 is vulnerable to a an path traversal when moving an issue between projects.


GitLab EE/CE 8.11 to 12.9 is leaking information on Issues opened in a public project and then moved to a private project through Web-UI and GraphQL API.


GitLab EE/CE 11.10 to 12.9 is leaking information on restricted CI pipelines metrics to unauthorized users.


GitLab EE/CE 8.0.rc1 to 12.9 is vulnerable to a blind SSRF in the FogBugz integration.


GitLab EE/CE 9.0 to 12.9 allows a maintainer to modify other maintainers' pipeline trigger descriptions within the same project.


An issue was discovered in GitLab Community Edition (CE) and Enterprise Edition (EE) before 12.7.9, 12.8.x before 12.8.9, and 12.9.x before 12.9.3. A Workhorse bypass could lead to NuGet package and file disclosure (Exposure of Sensitive Information) via request smuggling.


An issue was discovered in GitLab 10.7.0 and later through 12.9.2. A Workhorse bypass could lead to job artifact uploads and file disclosure (Exposure of Sensitive Information) via request smuggling.


An issue was discovered in GitLab CE and EE 8.15 through 12.9.2. Members of a group could still have access after the group is deleted.


GitLab 12.6 through 12.9 is vulnerable to a privilege escalation that allows an external user to create a personal snippet through the API.


GitLab 9.5.9 through 12.9 is vulnerable to stored XSS in an admin notification feature.


GitLab 10.8 through 12.9 has a vulnerability that allows someone to mirror a repository even if the feature is not activated.


GitLab EE 12.8 and later allows Exposure of Sensitive Information to an Unauthorized Actor via NuGet.


Amazon EKS credentials disclosure in GitLab CE/EE 12.6 and later through 13.0.1 allows other administrators to view Amazon EKS credentials via HTML source code


Client-Side code injection through Mermaid markup in GitLab CE/EE 12.9 and later through 13.0.1 allows a specially crafted Mermaid payload to PUT requests on behalf of other users via clicking on a link


An authorization issue relating to project maintainer impersonation was identified in GitLab EE 9.5 and later through 13.0.1 that could allow unauthorized users to impersonate as a maintainer to perform limited actions.


Kubernetes cluster token disclosure in GitLab CE/EE 10.3 and later through 13.0.1 allows other group maintainers to view Kubernetes cluster token


User email verification bypass in GitLab CE/EE 12.5 and later through 13.0.1 allows user to bypass email verification


Insecure authorization in Project Deploy Keys in GitLab CE/EE 12.8 and later through 13.0.1 allows users to update permissions of other users' deploy keys under certain conditions


A Stored Cross-Site Scripting vulnerability allowed the execution on Javascript payloads on the Metrics Dashboard in GitLab CE/EE 12.8 and later through 13.0.1


A specially crafted request could be used to confirm the existence of files hosted on object storage services, without disclosing their contents. This vulnerability affects GitLab CE/EE 12.10 and later through 13.0.1


A Reflected Cross-Site Scripting vulnerability allowed the execution of arbitrary Javascript code on the Static Site Editor in GitLab CE/EE 12.10 and later through 13.0.1


Missing permission check on fork relation creation in GitLab CE/EE 11.3 and later through 13.0.1 allows guest users to create a fork relation on restricted public projects via API


A Stored Cross-Site Scripting vulnerability allowed the execution of arbitrary Javascript code in the blobs API in all previous GitLab CE/EE versions through 13.0.1


OAuth flow missing verification checks CE/EE 12.3 and later through 13.0.1 allows unverified user to use OAuth authorization code flow


A Denial of Service vulnerability allowed exhausting the system resources in GitLab CE/EE 12.0 and later through 13.0.1


A security issue allowed achieving Denial of Service attacks through memory exhaustion by uploading malicious artifacts in all previous GitLab versions through 13.0.1


A user with an unverified email address could request an access to domain restricted groups in GitLab EE 12.2 and later through 13.0.1


User is allowed to set an email as a notification email even without verifying the new email in all previous GitLab CE/EE versions through 13.0.1


An authorization issue in the mirroring logic allowed read access to private repositories in GitLab CE/EE 10.6 and later through 13.0.5


For GitLab before 13.0.12, 13.1.6, 13.2.3 a memory exhaustion flaw exists due to excessive logging of an invite email error message.


For GitLab before 13.0.12, 13.1.6, 13.2.3 a denial of service exists in the project import feature


For GitLab before 13.0.12, 13.1.6, 13.2.3 after a group transfer occurs, members from a parent group keep their access level on the subgroup leading to improper access.


For GitLab before 13.0.12, 13.1.6, 13.2.3 a cross-site scripting vulnerability exists in the issues list via milestone title.


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. API Authorization Using Outdated CI Job Token


For GitLab before 13.0.12, 13.1.6, 13.2.3 a cross-site scripting (XSS) vulnerability exists in the issue reference number tooltip.


For GitLab before 13.0.12, 13.1.6, 13.2.3 user controlled git configuration settings can be modified to result in Server Side Request Forgery.


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. Project reporters and above could see confidential EPIC attached to confidential issues


In GitLab before 13.0.12, 13.1.6, and 13.2.3, a stored XSS vulnerability exists in the CI/CD Jobs page


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. In certain cases an invalid username could be accepted when 2FA is activated.


In GitLab before 13.0.12, 13.1.6, and 13.2.3, improper access control was used on the Applications page


In GitLab before 13.2.3, project sharing could temporarily allow too permissive access.


In GitLab before 13.0.12, 13.1.6 and 13.2.3, it is possible to bypass E-mail verification which is required for OAuth Flow.


In GitLab before 13.0.12, 13.1.6 and 13.2.3 using a branch with a hexadecimal name could override an existing hash.


In GitLab before 13.0.12, 13.1.6 and 13.2.3, access grants were not revoked when a user revoked access to an application.


An issue has been discovered in GitLab affecting versions >=10.7 <13.0.14, >=13.1.0 <13.1.8, >=13.2.0 <13.2.6. Improper Access Control for Deploy Tokens


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. When 2 factor authentication was enabled for groups, a malicious user could bypass that restriction by sending a specific query to the API endpoint.


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. Conan package upload functionality was not properly validating the supplied parameters, which resulted in the limited files disclosure.


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. The revocation feature was not revoking all session tokens and one could re-use it to obtain a valid session.


GitLab CE/EE version 13.3 prior to 13.3.4 was vulnerable to an OAuth authorization scope change without user consent in the middle of the authorization flow.


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. GitLab was vulnerable to a stored XSS on the standalone vulnerability page.


A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. Under certain conditions GitLab was not properly revoking user sessions and allowed a malicious user to access a user account with an old password.