| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated Broken Access Control in Deposits and Partial Payments for WooCommerce <= 3.1.0 versions. |
| Issue summary: Receiving a DTLS record for a future epoch while a handshake
is in progress causes OpenSSL to buffer far more memory than the record
itself requires.
Impact summary: A peer can use a small amount of network traffic to make an
OpenSSL DTLS endpoint retain a disproportionately large amount of memory,
which may lead to a Denial of Service.
CWE: CWE-405: Asymmetric Resource Consumption (Amplification)
Description: While a DTLS handshake is in progress, a peer may legitimately
have already moved on to the next epoch (for example, having sent its
ChangeCipherSpec and Finished messages) before the local endpoint has
processed the same transition, typically because of reordering on the
underlying UDP transport. OpenSSL buffers such early records so that they
can be processed once the local endpoint catches up.
Buffering a record currently retains the entire read buffer it arrived in,
which is sized to hold the largest possible DTLS record (around 16
kilobytes), rather than just the bytes that make up the record itself. Up
to 100 such records may be buffered per connection. As a result, a peer
that sends a stream of small forged records claiming to belong to the next
epoch can cause an OpenSSL DTLS endpoint to retain around 1.7 megabytes of
memory, despite sending only a small fraction of that amount of data over
the network.
An attacker therefore gains a memory amplification factor of around 1200,
and can multiply the effect across as many associations as it is able to
open, making this a remote memory exhaustion Denial of Service risk for
DTLS servers. Since the memory retained per connection remains bounded,
and any limit an application already places on the number of concurrent
associations also bounds the total exposure, this issue has been assessed
as Low severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary.
OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to this
issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.2.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.4.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.8.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.7.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.22.
Premium support customers only:
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zi
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zr
This issue was reported on 18 May 2026 by Amazon Web Services.
The fix has been developed by Matt Caswell.
-- cut (non-publishing metadata for internal use) --
Reported by: Amazon Web Services
Fixed by: Matt Caswell |
| Issue summary: In a server or client configuration with RFC7250 Raw Public Keys (RPKs)
enabled, and only the private key (with no associated certificate) configured locally,
a NULL pointer dereference may occur when the remote peer solicits raw public keys and
also sends the typically omitted "signature_algorithms_cert" TLS extension.
Impact summary: The impact is limited to a possible Denial of Service as a result of
an application abort, no data disclosure or remote command execution are possible.
CWE: CWE-476: NULL Pointer Dereference
Description: While a passing comment in sample code in the documentation suggests
that key-only RPK configurations are supported, the best-practice RPK configuration
is to always configure a corresponding certificate (possibly self-signed or
signed by any convenient CA).
When the private key is configured along with a matching certificate, the
"signature_algorithms_cert" extension is handled reliably even without the
fix, and peer clients or servers that don't support raw public keys may be
able to complete a TLS connection by pinning or verifying the corresponding
certificate or its public key.
Deployments that prefer to configure just a private key with no certificate
need to upgrade to an updated release as noted below.
FIPS impact: no
No FIPS modules are affected by this issue, as the SSL protocol implementation
is outside the OpenSSL FIPS module boundary. |
| The Kirki – Freeform Page Builder, Website Builder & Customizer plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘comment’ parameter in all versions up to, and including, 6.2.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| In createSessionInternal of PackageInstallerService.java, there is a possible way to permanently DoS the device due to a logic error in the code. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In setClipboardAccessNotificationsEnabledForUser of ClipboardService.java, there is a possible mult-iuser isolation due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In writeToParcel of BleRssiRangingCapabilities.java, there is a possible way to obtain the Bluetooth MAC address due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In onCreate of ContactsPickerActivity.kt, there is a possible misleading UI due to a tapjacking/overlay attack. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In initForUserNoTracing of VoiceInteractionManagerService.java, there is a possible persistent denial of service due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of XmpDataParser.java, there is a possible improper data sanitization due to a logic error in the code. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of rw_t3t.cc, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In updateInternal of MediaProvider.java, there is a possible expose contents of files due to a race condition. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In screenArgsForPermissionCheckIfAny of multiple locations there is a possible risk of unauthorized access due to a confused deputy. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In openFile of AppFuseBridge.java, there is a possible information disclosure due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible improper data sanitization due to a logic error in the code. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix still_degraded being inverted in raid10_sync_request()
Commit fe6a19d40ceb ("md/md-bitmap: merge md_bitmap_start_sync() into
bitmap_operations") converted still_degraded from int to bool, but
inverted the assignment in the loop that checks whether the array will
still be degraded after the current device is recovered:
"still_degraded = 1" became "still_degraded = false".
As a result, recovering a device while another mirror is still missing
calls md_bitmap_start_sync() with degraded == false, which clears bitmap
bits that the still-missing device needs. When that device is re-added,
its bitmap-based recovery finds the bits already cleared and skips every
region written while the array was degraded, so it is marked In_sync
while holding stale data: silent corruption.
Reproducer (raid10 near=2, 4 disks, internal bitmap):
- fail and remove one disk of each mirror pair
- write to the degraded array
- re-add both disks and let recovery finish
- "check" reports mismatch_cnt=262272 after 256 MiB of degraded
writes and file contents differ; the second disk's "recovery"
completes in milliseconds because everything is skipped
The same conversion in raid1 got it right (still_degraded = true).
Restore the correct value. |
| In the Linux kernel, the following vulnerability has been resolved:
mpls: reload header after pskb_may_pull()
mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop
when an MPLS route has multiple nexthops. While walking the MPLS label
stack, the hash routine caches hdr for the current label. After finding
the bottom-of-stack label, it calls pskb_may_pull() before reading the
inner IP header.
If an skb is constructed with the inner IP header in nonlinear data and
insufficient tailroom in the linear head, pskb_may_pull() calls
pskb_expand_head() to replace the skb head and free the old one. This
leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr
again when it performs a second pull for the larger header.
The issue was found through static analysis. A reproducer sending a legal
Geneve packet through a bareudp/MPLS multipath setup triggered the same
KASAN report in 2 of 2 unpatched runs:
BUG: KASAN: slab-use-after-free in mpls_select_multipath
Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23
Call Trace:
mpls_select_multipath
mpls_forward
__netif_receive_skb_list_core
netif_receive_skb_list_internal
napi_complete_done
gro_cell_poll
__napi_poll
net_rx_action
Freed by task 23:
kfree
pskb_expand_head
__pskb_pull_tail
mpls_select_multipath
Reload hdr from the current skb head after each successful pull before
deriving the inner IPv4 or IPv6 header pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Check svc pool percpu counter allocation
__svc_create() initializes three per-pool percpu_counter stats and
ignores every return value. On SMP, percpu_counter_init() fails when
__alloc_percpu_gfp() cannot satisfy the allocation, leaving the failed
counter with fbc->counters == NULL and its embedded raw_spinlock_t,
list_head, and count never initialized. __svc_create() returns the
half-constructed svc_serv to nfsd, lockd, or the NFS callback service
anyway.
Once that service is live, the hot-path increments in
svc_xprt_enqueue(), svc_handle_xprt(), and
svc_pool_wake_idle_thread() reach a counter whose backing pointer is
NULL. The pointer is a per-cpu offset, so the access does not fault:
it resolves to offset zero of the current CPU's per-cpu area and
silently corrupts whatever variable lives there. A
/proc/fs/nfsd/pool_stats read walks the same NULL per-cpu storage and
returns garbage, and on CONFIG_DEBUG_SPINLOCK or lockdep it splats on
the never-initialized lock.
Creating the broken service requires a percpu allocation failure during
RPC server startup, so it is reachable only by a local administrator
under memory pressure or fault injection; a remote peer cannot induce
the bad state on its own.
Check each percpu_counter_init() return value in __svc_create() and
fail when an allocation fails, unwinding the counters already set up
in the current pool and in every pool initialized before it. A
discrete percpu_counter_destroy() per counter at teardown frees each
per-cpu allocation exactly once. |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: close backchannel before destroying callback service
A backchannel receive can complete a request while the NFS callback
service is being torn down. xprt_complete_bc_request() removes the
request from bc_pa_list, drops bc_alloc_count, marks the request in use,
and then asks xprt_enqueue_bc_request() to hand it to the callback
service.
If teardown has already cleared xprt->bc_serv, xprt_enqueue_bc_request()
currently returns without enqueueing or freeing the committed request.
The xprt_get() taken on entry is leaked as well. If the producer wins
the race before bc_serv is cleared, it can also enqueue onto sv_cb_list
after nfs_callback_down() has stopped the callback threads, leaving the
request linked to a svc_serv that is about to be freed.
Close the producer side before callback threads are stopped. Add
xprt_svc_shutdown_bc() to clear xprt->bc_serv under bc_pa_lock, and call
it on callback shutdown and callback-start failure before stopping the
service threads. Requests that lose the NULL transition in
xprt_enqueue_bc_request() are released through the normal backchannel
free path after balancing bc_slot_count. Finally, drain any remaining
sv_cb_list requests after the callback threads have stopped and before
svc_destroy() frees the service. |
| In the Linux kernel, the following vulnerability has been resolved:
sunrpc: defer rq_argp and rq_resp free until after RCU grace period
svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously
via kfree(), but defers the rqstp struct free via kfree_rcu(). After
svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is
a window where RCU readers that started before list_del_rcu() can still
traverse the thread list and find the rqstp. These readers (e.g.
nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has
already been freed — a use-after-free.
Fix this by moving the kfree of rq_argp and rq_resp into an explicit
call_rcu() callback alongside the struct free. Resources not accessed
by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain
synchronously freed. |
