| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Apache Traffic Server can resume a TLS session across SNI virtual hosts without re-verifying a client certificate required by the resumed host's verify_client STRICT policy.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Apache Traffic Server's default outbound session-sharing policy can reuse a pooled TLS session authenticated with one client certificate for a transaction configured to present a different one.
This issue affects Apache Traffic Server: from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Apache Traffic Server's experimental magick plugin lets an unauthenticated client control ImageMagick convert arguments in its default (unsigned) configuration.
This issue affects Apache Traffic Server: from 8.0.1 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Apache Traffic Server's origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy's own credentials.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Apache Traffic Server's experimental tsmemcache plugin allows unauthenticated network read, write, and deletion of the shared proxy cache.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Apache Traffic Server can return an origin connection to the shared pool while the origin is still waiting on a request body the client declared but never fully sent, including when the client used Expect: 100-continue. The origin then reads a later request on that connection as leftover body data, which lets an attacker smuggle requests past ATS access controls, disrupt other users' requests, or poison the cache.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), Missing Authentication for Critical Function vulnerability in Apache Kylin. Impact most to the kylin services that are directly exposed to public network, which is not common. In-house kylin deployments are mostly not impacted.
This issue affects Apache Kylin: from 5 through 5.0.4. Certain backend cache API misses required authentication and can cause execution of injected SQL.
Users are recommended to upgrade to version 5.0.5, which fixes the issue. |
| Uncontrolled recursion in the AMF parser in Apache bRPC < 1.18.0 allows a remote RTMP peer to crash a bRPC process by sending deeply nested AMF objects or arrays. The parser recursively processed nested AMF containers without enforcing a depth limit, which could exhaust the native stack.
Affected Scenarios:
Applications using bRPC RTMP support and parsing AMF data from an untrusted RTMP peer. This includes RTMP servers parsing client command messages, RTMP clients parsing server responses or status messages, and either side parsing inbound AMF script data such as metadata or cue points. Direct callers of ReadAMFObject or ReadAMFArray on untrusted input are also affected.
How to Fix:
1. Upgrade Apache bRPC to 1.18.0.
2. Apply the patch from PR https://github.com/apache/brpc/pull/3344 .
Note:
The fix introduces a configurable AMF nesting depth limit with default value 128. AMF objects or arrays deeper than amf_max_depth are rejected after applying the fix. |
| UNSUPPORTED WHEN ASSIGNED Improper restriction of XML external entity references in Apache Abdera allows an attacker to access sensitive data or make server-side requests when an application parses attacker-controlled XML with Abdera.
This issue affects Apache Abdera: all versions.
Apache Abdera is retired and no longer supported, so we do not plan to release a version that fixes this issue. Users are recommended to migrate to a maintained alternative. Applications that cannot migrate should ensure that untrusted XML cannot reach the affected Abdera parser or JDBC adapter parsing paths. Actively maintained downstream products may still be impacted if they include an affected Abdera artifact.
NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| Uncontrolled Resource Consumption vulnerability in Apache IoTDB JDBC driver.
This issue affects Apache IoTDB JDBC driver: from 1.3.3 before 2.0.11.
Users are recommended to upgrade to version 2.0.11, which fixes the issue. |
| Improper authentication in Apache bRPC through 1.17.0 allows a remote unauthenticated attacker to bypass authentication for protected non-builtin HTTP endpoints by first sending a builtin HTTP request on the same HTTP/1.1 keep-alive connection.
When ServerOptions.auth is enabled and builtin HTTP services are exposed on the public listener, a builtin request received as the first message on a socket may cause the connection to be treated as authenticated for later requests on that socket. Users are recommended to upgrade to version 1.18.0, which fixes this issue, or apply this PR separately: https://github.com/apache/brpc/pull/3308 |
| Uncontrolled recursion in the HTTP/2 HPACK decoder in Apache bRPC before 1.18.0 allows remote attackers to cause denial of service by sending a crafted HTTP/2 header block containing many consecutive Dynamic Table Size Update entries. Each update was decoded by recursively invoking the HPACK decoder, which could exhaust the thread stack before a header field or end of input was reached.
Root Cause:
The bRPC HPACK decoder recursively decoded the next entry after processing a Dynamic Table Size Update. The decoder did not bound the recursion depth, so a long sequence of update entries could consume excessive stack space.
Affected Scenarios:
Use bRPC with the built-in HTTP/2 implementation to accept HTTP/2 traffic from an untrusted network.
How to Fix:
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3343
Note:
The fix changes HPACK Dynamic Table Size Update decoding to use iterative parsing instead of recursive parsing. |
| Uncontrolled recursion in the Redis reply parser in Apache bRPC < 1.18.0 allows a remote Redis server peer to crash a bRPC Redis client process by returning a deeply nested RESP array reply. The parser recursed once for each nested array level without enforcing a depth limit. The fix adds a configurable Redis reply depth limit with default value 128 and rejects replies exceeding that limit.
Affected Scenarios:
Applications using bRPC as a Redis client with ChannelOptions.protocol="redis" and receiving replies from an untrusted or faulty Redis server peer.
How to Fix:
1. Upgrade Apache bRPC to 1.18.0.
2. Apply the patch from PR https://github.com/apache/brpc/pull/3344 .
Note:
After applying the fix, Redis replies with array nesting deeper than redis_max_reply_depth are rejected. |
| Integer underflow and out-of-bounds read in the HTTP/2 server DATA frame parser in Apache bRPC allows an unauthenticated remote attacker to cause denial of service by sending a malformed DATA frame with the PADDED flag set and a zero-length payload.
Root Cause:
The HTTP/2 DATA frame handler computed the fragment size from the attacker-controlled payload length and, when the PADDED flag was present, decremented the fragment size before ensuring that the frame contained the mandatory pad length byte. A zero-length padded DATA frame could therefore underflow the unsigned fragment size and read the pad length byte past the end of the frame buffer.
Affected Scenarios:
Apache bRPC servers that accept HTTP/2 traffic are affected when a remote client can send crafted HTTP/2 frames to the server. HTTP/2 may be reached through cleartext h2c detection on an HTTP port or through TLS ALPN negotiation.
How to Fix:
(Choose one of the following options)
1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3325
Note:
The fix validates that a padded DATA frame has enough payload bytes for the pad length field before decrementing the fragment size or reading the pad length byte. Malformed zero-length padded DATA frames are rejected with HTTP/2 FRAME_SIZE_ERROR. |
| The RTMP AMF parser in Apache bRPC accepts AMF string lengths and array counts directly from untrusted input. A remote unauthenticated attacker who can reach a bRPC server with RTMP enabled can send a small AMF payload with an excessive declared long string length or array count, causing excessive memory allocation or resource consumption before the parser rejects the incomplete payload.
Root Cause:
The AMF long string parser resized the destination string to the declared 32-bit length before validating that the stream contained that many bytes. ECMA array and strict array parsers also accepted 32-bit element counts without a configurable upper bound.
Affected Scenarios:
Deployments that enable the bRPC RTMP server component and accept RTMP traffic from untrusted clients. Direct uses of the AMF parser on untrusted data are also affected.
How to Fix:
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3353
Note:
The fix introduces configurable AMF parsing limits. The default maximum string size is 64 MiB and the default maximum array element count is 1,048,576. Payloads above these limits are rejected. The limits can be adjusted with amf_max_string_size and amf_max_array_size. |
| The Redis server command parser in Apache bRPC accepts an empty RESP array as a command header. A remote unauthenticated attacker who can reach a bRPC server with Redis service enabled can send an empty array header followed by a bulk string, causing an out-of-bounds write in the parser and crashing the process.
Root Cause:
RedisCommandParser::ConsumeImpl rejected negative RESP array counts but accepted zero. It resized the command argument vector to zero elements and continued parsing. When a following bulk string was parsed, the only index guard was a CHECK. In configurations where fatal logs do not abort immediately, execution could continue and write to _args[0] even though the vector was empty.
Affected Scenarios:
Deployments that enable ServerOptions.redis_service and accept Redis protocol traffic from untrusted clients. The issue is reached during parsing before command handling or authentication.
How to Fix:
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3354
Note:
The fix rejects empty RESP arrays as invalid Redis commands and replaces the internal index CHECK with an explicit parse error so malformed command streams cannot fall through to an indexed vector write. |
| The Redis protocol implementation in Apache bRPC allowed inline command parsing to allocate and copy the full connection buffer before a complete CRLF-terminated command was available. A remote attacker with access to a Redis-protocol bRPC service could send long inline inputs without a terminating CRLF to increase memory usage and CPU copy overhead, potentially causing denial of service.
Root Cause:
The Redis inline command parser allocated memory based on the current input buffer size and copied the entire buffer before determining the current inline command boundary. The existing redis_max_allocation_size limit was applied to RESP bulk strings and arrays, but not effectively to the inline command path before allocation.
Affected Scenarios:
Use Apache bRPC server with Redis protocol enabled and reachable by untrusted clients.
How to Fix:
1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue.
2. Apply the patch from PR https://github.com/apache/brpc/pull/3363 .
Note:
The fix applies redis_max_allocation_size to Redis inline command lines and scans for CRLF before allocating parser arena memory. Inline command lines exceeding this limit are rejected. |
| Apache bRPC versions before 1.18.0 do not consistently enforce the configured max_body_size limit in non-progressive HTTP/1 and HTTP/2 parsing and in memcache and couchbase response parsing.
A remote unauthenticated peer can cause an affected process to buffer message data beyond the configured limit, which may lead to memory exhaustion and denial of service.
Users should upgrade to 1.18.0 or apply the patch from PR https://github.com/apache/brpc/pull/3382 . The fix rejects oversized buffered HTTP bodies, returns HTTP 413 for HTTP/1 requests, resets oversized HTTP/2 streams, and rejects oversized memcache and couchbase responses from their declared lengths. Progressive HTTP reading remains supported because it uses bounded buffering. |
| Out-of-bounds reads in URL parsing and case-insensitive header lookup in Apache bRPC before version 1.18.0 on platforms where plain char is unsigned, such as ARM64, allow remote attackers to cause a process crash and denial of service by sending crafted input containing bytes with the high bit set.
Root Cause:
Two 256-entry lookup tables are accessed through pointers biased by 128 so that valid indices are in the range -128 to 127. Input bytes are promoted from plain char to int without first normalizing them to the signed-char range. On affected platforms, bytes in the range 0x80 to 0xFF therefore become indices 128 to 255 and read up to 127 bytes beyond the end of the underlying tables.
Affected Scenarios:
A remotely accessible bRPC HTTP server on an affected platform can reach the vulnerable URL lookup through an unauthenticated request URI containing a high-bit byte. The case-insensitive lookup is also reachable when untrusted header names are processed through APIs such as the HTTP/2 HPACK path. HTTP/1 header names containing high-bit bytes are rejected by the HTTP/1 parser before reaching the vulnerable lookup. Builds where plain char is signed, which commonly include x86_64 builds, are not affected by this issue.
How to Fix:
Choose one of the following options:
1. Upgrade Apache bRPC to version 1.18.0 or later.
2. Apply the patch from https://github.com/apache/brpc/pull/3376 .
The fix normalizes lookup-table indices to the signed-char range before accessing the biased tables. |
