| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The StreamsHub Console operator acts as a confused deputy: a Kubernetes tenant with permission to create a Console custom resource can set spec.kafkaClusters[].credentials.kafkaUser.namespace to any namespace. The operator, running with cluster-wide Secrets RBAC, reads the victim-namespace KafkaUser Secret (SASL credentials or TLS private keys) and writes the plaintext material into a Secret in the attacker's namespace. No same-namespace check or allowlist exists anywhere in the code path. |
| Summary
Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.
Root cause
*
HTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.
*
HTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.
*
The HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.
Impact
A remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:
*
Cache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host).
*
Host-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.
Deployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76
*
If you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'. |
| Summary
Before version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client's Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.
Impact
Specifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go's net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.
Note that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded , https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee
*
Do not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.
*
If you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: disable LZ4 rolling decompression for now
LZ4 rolling decompression [1] was introduced to reduce the memory
footprint of temporary pages:
For many cases, it is needed for users to read small data within
a compressed extent (pcluster), either due to random small read, or
since uptodate folios (typically order-0) cannot be reused for
decompression again since decompression algorithm refills
already-uptodate folios.
Rolling decompression works because LZ4 is LZ77-based and only refers
to the most recent 64 KiB of decompressed data, so in theory only a
bounded rolling window of temporary pages is needed when decompressing.
It can save a lot of temporary memory, e.g.
601,960-byte data can be compressed into a 256k LZ4 compressed extent,
which means it needs 146 extra pages per request in the worst case if
rolling decompression is disabled.
However, the upstream LZ4 implementation is not under EROFS' control:
For example, the literal copy memmove() may still **copy long literals
backward** on x86 based on the address comparison even when the source
and destination ranges do not overlap (IOWs, inline decompression
doesn't need to be considered here). That breaks the rolling assumption
and makes the optimization broken.
Disable it for now to make sure the data correctness first since EROFS
is used everywhere now: The rolling window approach can be revived once
we either ensure that the official LZ4 code always copies forward for
non-overlapping ranges or maintain our own LZ4 implementation in EROFS.
The main impact is a higher runtime memory footprint; However, recent
commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4
decompression") helps mitigate this when enabled but it's still not
perfect.
[1] https://www.usenix.org/conference/atc19/presentation/gao
ยง 3.3 Decompression |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: skip the VMID 0 flush for VRAM
Clear-on-release only runs on VRAM, which amdgpu_ttm_map_buffer() reaches
via its direct MC address without programming a GART window, yet the wipe
still forces a VMID 0 flush. On GFX11 (e.g. Navi33) that spurious SDMA
flush can wedge the engine; only flush when a GART window is actually used.
v2: Let amdgpu_ttm_map_buffer() return whether the VMID 0 flush is needed,
and drive the clear and copy paths from that. (Christian)
v3: Make the vm_needs_flush output parameter mandatory instead of
allowing NULL. (Christian)
(cherry picked from commit a306e406e570b74318ff7d80e5b07b540ca1d3a9) |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12
svm_copy_lbrs() always marks VMCB_LBR dirty in the destination VMCB.
However, nested_svm_vmexit() uses it to copy LBRs to vmcb12, and
clearing clean bits in vmcb12 is not architecturally defined.
Move vmcb_mark_dirty() to callers and drop it for vmcb12.
This also facilitates incoming refactoring that does not pass the entire
VMCB to svm_copy_lbrs(). |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix zero size inode with non-zero size after log replay
When logging that an inode exists, as part of logging a new name or
logging new dir entries for a directory, we always set the generation of
the logged inode item to 0. This is to signal during log replay (in
overwrite_item()), that we should not set the i_size since we only logged
that an inode exists, so the i_size of the inode in the subvolume tree
must be preserved (as when we log new names or that an inode exists, we
don't log extents).
This works fine except when we have already logged an inode in full mode
or it's the first time we are logging an inode created in a past
transaction, that inode has a new i_size of 0 and then we log a new name
for the inode (due to a new hardlink or a rename), in which case we log
an i_size of 0 for the inode and a generation of 0, which causes the log
replay code to not update the inode's i_size to 0 (in overwrite_item()).
An example scenario:
mkdir /mnt/dir
xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo
sync
xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo
ln /mnt/dir/foo /mnt/dir/bar
xfs_io -c "fsync" /mnt/dir
<power fail>
After log replay the file remains with a size of 64K. This is because when
we first log the inode, when we fsync file foo, we log its current i_size
of 0, and then when we create a hard link we log again the inode in exists
mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we
add to the log tree, so during log replay overwrite_item() sees that the
generation is 0 and i_size is 0 so we skip updating the inode's i_size
from 64K to 0.
Fix this by making sure at fill_inode_item() we always log the real
generation of the inode if it was logged in the current transaction with
the i_size we logged before. Also if an inode created in a previous
transaction is logged in exists mode only, make sure we log the i_size
stored in the inode item located from the commit root, so that if we log
multiple times that the inode exists we get the correct i_size.
A test case for fstests will follow soon. |
| In the Linux kernel, the following vulnerability has been resolved:
x86-64: rename misleadingly named '__copy_user_nocache()' function
This function was a masterclass in bad naming, for various historical
reasons.
It claimed to be a non-cached user copy. It is literally _neither_ of
those things. It's a specialty memory copy routine that uses
non-temporal stores for the destination (but not the source), and that
does exception handling for both source and destination accesses.
Also note that while it works for unaligned targets, any unaligned parts
(whether at beginning or end) will not use non-temporal stores, since
only words and quadwords can be non-temporal on x86.
The exception handling means that it _can_ be used for user space
accesses, but not on its own - it needs all the normal "start user space
access" logic around it.
But typically the user space access would be the source, not the
non-temporal destination. That was the original intention of this,
where the destination was some fragile persistent memory target that
needed non-temporal stores in order to catch machine check exceptions
synchronously and deal with them gracefully.
Thus that non-descriptive name: one use case was to copy from user space
into a non-cached kernel buffer. However, the existing users are a mix
of that intended use-case, and a couple of random drivers that just did
this as a performance tweak.
Some of those random drivers then actively misused the user copying
version (with STAC/CLAC and all) to do kernel copies without ever even
caring about the exception handling, _just_ for the non-temporal
destination.
Rename it as a first small step to actually make it halfway sane, and
change the prototype to be more normal: it doesn't take a user pointer
unless the caller has done the proper conversion, and the argument size
is the full size_t (it still won't actually copy more than 4GB in one
go, but there's also no reason to silently truncate the size argument in
the caller).
Finally, use this now sanely named function in the NTB code, which
mis-used a user copy version (with STAC/CLAC and all) of this interface
despite it not actually being a user copy at all. |
| The Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section. A header field name placed in the request body is therefore reported to the server as though it were a header, which lets a client control request framing decisions it should not be able to reach. |
| A flaw was found in Quarkus-HTTP, which incorrectly parses cookies with
certain value-delimiting characters in incoming requests. This issue could
allow an attacker to construct a cookie value to exfiltrate HttpOnly cookie
values or spoof arbitrary additional cookie values, leading to unauthorized
data access or modification. The main threat from this flaw impacts data
confidentiality and integrity. |
| Inconsistent interpretation of http requests ('http request/response smuggling') in ASP.NET Core allows an unauthorized attacker to perform tampering over a network. |
| Inconsistent interpretation of http requests ('http request/response smuggling') in ASP.NET Core allows an unauthorized attacker to bypass a security feature over a network. |
| A flaw was found in Netty. A remote unauthenticated attacker can exploit a vulnerability in Netty's HTTP/1 to HTTP/2 conversion process. When an HTTP/1 request includes both an absolute-form request-target and a conflicting Host header, Netty incorrectly prioritizes the Host header for the HTTP/2 :authority field, discarding the original request-target authority. This inconsistency can allow an attacker to bypass security controls in Netty-based proxies or gateways, potentially leading to unauthorized access, cache poisoning, or misrouting of requests. |
| A flaw was found in Netty's `netty-codec-http` component. A remote attacker could exploit this vulnerability by sending a specially crafted HTTP/1.1 chunk-size token that includes post-digit whitespace. This incorrect parsing of the chunk size can lead to HTTP request smuggling. This allows an attacker to bypass security controls or access unauthorized resources in proxy/backend deployments. |
| A flaw was found in Netty's HTTP/1.1 decoder. This vulnerability allows a remote attacker to bypass `Transfer-Encoding` header validation by splitting the `Transfer-Encoding` field across multiple headers, with the last field containing a non-final transfer coding like `gzip` or `deflate`. This bypass can lead to HTTP request smuggling, enabling attackers to bypass security controls, desynchronize request processing, or cause requests to be processed in an unintended context. |
| In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding. |
| Issue summary: The POLY1305 MAC (message authentication code) implementation
contains a bug that might corrupt the internal state of applications on the
Windows 64 platform when running on newer X86_64 processors supporting the
AVX512-IFMA instructions.
Impact summary: If in an application that uses the OpenSSL library an attacker
can influence whether the POLY1305 MAC algorithm is used, the application
state might be corrupted with various application dependent consequences.
The POLY1305 MAC (message authentication code) implementation in OpenSSL does
not save the contents of non-volatile XMM registers on Windows 64 platform
when calculating the MAC of data larger than 64 bytes. Before returning to
the caller all the XMM registers are set to zero rather than restoring their
previous content. The vulnerable code is used only on newer x86_64 processors
supporting the AVX512-IFMA instructions.
The consequences of this kind of internal application state corruption can
be various - from no consequences, if the calling application does not
depend on the contents of non-volatile XMM registers at all, to the worst
consequences, where the attacker could get complete control of the application
process. However given the contents of the registers are just zeroized so
the attacker cannot put arbitrary values inside, the most likely consequence,
if any, would be an incorrect result of some application dependent
calculations or a crash leading to a denial of service.
The POLY1305 MAC algorithm is most frequently used as part of the
CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)
algorithm. The most common usage of this AEAD cipher is with TLS protocol
versions 1.2 and 1.3 and a malicious client can influence whether this AEAD
cipher is used by the server. This implies that server applications using
OpenSSL can be potentially impacted. However we are currently not aware of
any concrete application that would be affected by this issue therefore we
consider this a Low severity security issue.
As a workaround the AVX512-IFMA instructions support can be disabled at
runtime by setting the environment variable OPENSSL_ia32cap:
OPENSSL_ia32cap=:~0x200000
The FIPS provider is not affected by this issue. |
| Radius is a cloud-native, portable application platform that makes app development easier for teams building cloud-native apps. Prior to 0.58.0, the Kubernetes controller deserializes the user-controlled radapp.io/status annotation on a Deployment and uses its container resource identifier for deletion without confirming ownership by that Deployment. An attacker with permission to modify Deployment annotations and knowledge of a target Radius resource ID can forge radapp.io/status and set radapp.io/enabled to false, causing reconciliation to enter the privileged deletion path for another tenant's Radius-managed container resource. In a multi-tenant installation this confused-deputy condition can delete another team's recoverable container resource and disrupt service; in a single-tenant installation the impact is limited to self denial of service. The multi-tenant Radius controller reads the annotations in pkg/controller/reconciler/annotations.go and reaches the privileged delete in pkg/controller/reconciler/deployment_reconciler.go. The issue does not disclose data, grant privileges, or provide persistence. This issue is fixed in version 0.58.0. |
| Confused deputy in DeviceBoundSessionCredentials in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent `POST` request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST. |
