| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From 42.3.3 until 42.10.0, 43.5.0, and 44.0.0-beta.6, Electron's sandboxed preload code cache did not verify that a cached entry matched the preload it was served for. A compromised renderer could write attacker-controlled cache data and cause Electron to reuse it for a later load, executing the renderer's code in the more privileged preload context. The issue affects applications that load untrusted content. This issue is fixed in versions 42.10.0, 43.5.0, and 44.0.0-beta.6. |
| An unauthenticated client can drain the RTSP server's packet pool with a couple of dozen requests
that carry a Session header the parser cannot convert.
The Session branch returns the raw NetX error code instead of an RTSP status code:
```c
/* addons/rtsp/nx_rtsp_server.c:2754 */
status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id);
if (status)
{
return(status); /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */
}
```
Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch
eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The
raw code then reaches `_nx_rtsp_server_error_response_send` (nx_rtsp_server.c:1234), which does not
recognise it, takes a path that returns without releasing the response packet it already allocated,
and the block never goes back to the pool.
Six requests with an empty Session header against a 22 packet pool:
```
valid requests: after request 6: pool available = 21, AFTER = 22 / 22
malformed requests: after request 6: pool available = 16, AFTER = 17 / 22
```
One block per request, not returned when the client disconnects. Twenty six requests take the pool
to zero and the server starts failing allocations, after which it serves nobody. If the pool is
shared with the rest of the application, as it is in the shipped sample, the rest of the stack
stops with it.
Convert the `_nx_utility_string_to_uint` failure in the Session branch into
NX_RTSP_STATUS_CODE_BAD_REQUEST the way the CSeq branch does, and release the response packet on
every exit path of `_nx_rtsp_server_error_response_send`. |
| XML injection (aka blind XPath injection) vulnerability in The Wikimedia Foundation Mediawiki - EasyTimeline extension allows XML Injection.
This issue affects Mediawiki - EasyTimeline extension: before 1.46.1, 1.45.5, 1.43.10. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in The Wikimedia Foundation Mediawiki - Refreshed skin allows Stored XSS.
This issue affects Mediawiki - Refreshed skin: before 1.46.1, 1.45.5, 1.43.10. |
| Issue summary: SM2 signature generation uses non-constant-time arithmetic
on secret values, forming a timing side-channel.
Impact summary: An attacker able to measure SM2 signing times may learn
information about the per-signature secret nonce, which over many signatures
can, via a lattice / Hidden Number Problem attack, lead to recovery of the
private key.
CWE: CWE-208: Observable Timing Discrepancy
Description: SM2 signature generation computes the signature value using
variable-time BIGNUM operations on the secret nonce and the private key, so
the time taken to produce an SM2 signature depends on these secret values,
forming a timing side-channel.
Applications performing SM2 signature generation are affected on all
platforms.
FIPS Impact: no
SM2 is not a FIPS algorithm. |
| Issue summary: The DTLS retransmission logic does not correctly handle
a handshake message write that is suspended part-way through.
The retransmitted message can be read past the message buffer and
the retransmission overwrites the internal state the suspended write
needs to resume correctly.
Impact summary: The retransmitted message can disclose a heap memory
to the peer as plaintext handshake data or cause a crash and a Denial
of Service when the read reaches an unmapped memory region.
CWE: CWE-125: Out-of-bounds Read
Description: DTLS handshake messages can be written out in multiple
fragments, and a write can suspend mid-message (returning WANT_WRITE)
if the underlying transport temporarily cannot accept more data. While
such a write is suspended, the DTLS retransmission timer may
independently fire and ask the retransmission logic to resend an
earlier, already-acknowledged-as-sent message from its retransmit
queue.
The retransmission logic reused the same internal buffer and position
tracking as the message that was still being written, without
resetting the position back to the start of the message being
retransmitted. As a result the retransmission was read starting from
wherever the suspended write had left off, producing a mislabelled
message whose body was leftover bytes from the other, larger message
still in flight - content that was never meant to be sent at that
point, and which could run past the end of the allocated buffer.
Separately, even when the retransmission is positioned correctly,
allowing it to run to completion while another write is suspended
overwrites the same shared bookkeeping that the suspended write
depends on to resume. When the application later resumes the
suspended write (via a subsequent SSL_read(), SSL_write(),
SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a
state inconsistent with the message and aborts the process in
a debugging build.
The fix resets the retransmission's read position to the start of the
message before resending, and skips retransmission entirely whenever a
handshake write is still suspended, deferring to the next call that
resumes it instead.
FIPS impact: no
The affected code is outside the FIPS module boundary. |
| Improper validation of non-secure (NS) pointers in multiple TrustZone-M non-secure callable (NSC) entry functions allows an attacker executing in the non-secure world to supply pointers to secure memory. The secure firmware subsequently dereferences these attacker-controlled pointers without verifying that they reference non-secure memory, resulting in unintended disclosure of secure memory contents. This violates the isolation guarantees provided by Arm TrustZone-M and can be leveraged as a memory disclosure or corruption primitive that may enable recovery of sensitive cryptographic material. |
| Attacker model / Preconditions: a loaded `TXM_MODULE_USER_MODE | TXM_MODULE_MEMORY_PROTECTION` module issuing kernel dispatch calls, on a build with `TX_ENABLE_EVENT_TRACE`.
A user-mode, memory-protected module can register an arbitrary function pointer as the global trace-full callback. The kernel calls it directly — no validation, no trampoline — from privileged kernel code when the trace buffer wraps.
An invalid pointer faults the kernel (DoS). A pointer into the module's own code was observed running with kernel privilege (`CONTROL.nPRIV = 0`), confirmed at runtime with a register capture inside that code. |
| The TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than
four bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not
against the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. Two things follow from that one
missing check, both reachable before any authentication because TFTP has none.
The handler passes `nx_packet_length - 4` straight to FileX:
```c
/* addons/tftp/nxd_tftp_server.c:1863, 1889 */
status = nx_packet_copy(packet_ptr, &temp_ptr,
server_ptr -> nx_tftp_server_packet_pool_ptr, NX_WAIT_FOREVER);
...
fx_file_write(&(client_request_ptr -> nx_tftp_client_request_file),
packet_ptr -> nx_packet_prepend_ptr + 4,
packet_ptr -> nx_packet_length - 4);
```
`nx_packet_length` is the length of a chain, not of one contiguous buffer, so FileX copies past the
end of the first packet:
```
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1280 at 0x621000001108 thread T5
#0 __interceptor_memcpy
#1 _fx_utility_memory_copy filex/common/src/fx_utility_memory_copy.c:78
0x621000001108 is 0 bytes to the right of 4104-byte region
```
Those bytes are written into the file the attacker is uploading, and a TFTP read request hands them
back, so this is a memory disclosure with a convenient retrieval channel.
The same datagram also wedges the server. `nx_packet_copy` at :1863 needs
ceil(nx_packet_length / pool_payload) packets and asks for them with NX_WAIT_FOREVER, so when the
attacker sizes the datagram beyond what the pool holds, the server thread suspends and never
returns. A liveness probe after one such datagram times out with the pool at 0 of 12 packets and
the server thread suspended, and no later client is served.
Reject `nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX` in the DATA branch before either call,
and use a bounded wait rather than NX_WAIT_FOREVER for the copy. |
| hey,
`_nx_snmp_utility_object_id_get` in the NetX Duo SNMP addon does not validate the claimed OID data length against the actual buffer size when the OID uses BER multibyte length encoding, so a remote attacker can send a crafted SNMP packet with a multibyte OID length larger than the available buffer, causing the parser to read past the packet buffer boundary into adjacent heap memory. the OOB bytes are decoded as OID component values and written into the agents internal OID string buffer, corrupting agent state. on systems with memory protection the OOB read poses the risk of crashing the SNMP agent thread, causing denial of service. on bare metal embedded systems without memory protection the read silently succeeds and corrupts the agents internal state with heap data. |
| The cleanup of tempfile.TemporaryDirectory is vulnerable to a race condition. An attacker who can modify the tree during cleanup can replace a directory with a symbolic link, causing files outside of the temporary directory to be deleted or have their permissions and file flags reset, with the privileges of the process performing the cleanup. Note that platforms where shutil.rmtree.avoids_symlink_attacks is false, remain affected, and file flags may still be reset outside of the tree on all platforms. |
| Unbounded PPP IPCP Option Parsing Causes a Worker Stall and Out-of-bounds Read |
| FTP Passive Data Connection Not Bound to the Authenticated Control Peer |
| pageant provides a [PageantStream] type that implements [AsyncRead] and [AsyncWrite] traits and can be used to talk to a running Pageant instance. Prior to pageant 0.2.3, the Windows pageant crate's pageant/src/wmmessage.rs MemoryMap::read function trusts a peer-controlled u32 response length supplied through the 8192-byte Pageant shared-memory mapping reached by AgentClient::connect_pageant. A local process that impersonates the Pageant window can make query_pageant_direct allocate up to approximately 4 GiB and copy beyond the mapped view, reliably crashing a russh client and conditionally exposing adjacent committed memory. This issue is fixed in pageant 0.2.3. |
| Russh is a Rust SSH client and server library. Prior to 0.63.0, the hybrid ML-KEM 768 and X25519 implementation in russh/src/kex/hybrid_mlkem.rs accepts an all-zero 32-byte peer X25519 public key in both server_dh and compute_shared_secret, forcing the X25519 contribution to the combined shared secret to zero. A malicious SSH peer can therefore make the combined secret depend only on ML-KEM, defeating the hybrid exchange's intended fallback protection if ML-KEM is later weakened. This issue is fixed in version 0.63.0. |
| A vulnerability was detected in Ziroom ZHOME A0101 1.0.1.0. This affects the function set_syslog of the file /api/ZRnetwork/set_syslog. The manipulation of the argument conloglevel/log_size results in command injection. The attack may be performed from remote. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Issue summary: A malicious remote peer may flood the local QUIC
stack with NEW_CONNECTION_ID frames by avoiding a limit check on
how many connection IDs the remote QUIC stack can use.
Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame
for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID
frame is dispatched via the Control Frame Queue (CFQ). If the remote
peer also withholds ACKs, then it can force the local stack
to allocate ~400MB (depending on ACK delay).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism
by which a remote peer can notify the local QUIC stack to change the
destination connection ID (a.k.a. CID) the local stack uses to
identify the connection at the remote peer. Each CID is associated
with a sequence number. The sequence number is transmitted
in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID
which is being either associated with a connection or retired.
The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know
a new CID is being associated with an existing connection. The
NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the
retire-prior-to number. The retire-prior-to identifies existing
CIDs that are to be retired. The local QUIC stack must send a
RETIRE_CONNECTION_ID for every destination CID whose sequence number
is less than retire-prior-to. The CID becomes retired after the
local stack receives an ACK for its RETIRE_CONNECTION_ID frame.
Although the OpenSSL QUIC stack supports at most one destination CID
for every connection, it can be tricked into processing more than
one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC
stack currently retires the destination CID as soon as it receives
the NEW_CONNECTION_ID, while in fact the destination CID must
be retired after an ACK for the RETIRE_CONNECTION_ID frame is received.
Correcting the flawed logic also fixes the backlog growth.
[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
| Missing authorization in NFC in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) |
| Missing authorization in WebView in Google Chrome on on Android prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Missing authorization in WakeLock in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low) |
