| 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`. |
| 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. |
| 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 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) |
| simple-git, an interface for running git commands in any node.js application, enables applications to execute Git operations from JavaScript. Prior to 4.0.0, the default blockUnsafeOperationsPlugin compares parsed option names with literal dangerous option spellings while Git accepts unambiguous long-option abbreviations. Attacker-influenced push arguments such as abbreviated --receive-pack or --exec forms can therefore bypass detectVulnerableFlags, reach git push against a local or file remote or an attacker-influenced receive-pack target, and cause Git to invoke an attacker-selected command in consumers that expose those arguments. The clone-side abbreviation handling does not protect the push path. This issue is fixed in 4.0.0. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Mediawiki - Cargo extension allows Reflected XSS.
This issue affects Mediawiki - Cargo extension: through 3.9.4. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Mediawiki - Cargo extension allows Reflected XSS.
This issue affects Mediawiki - Cargo extension: through 3.9.4. |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in the Mediawiki - Cargo extension allows Stored XSS.
This issue affects Mediawiki - Cargo extension: through 3.9.4. |
| Incorrect authorization in HID 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) |
| Out of bounds write in GPU in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Renovate versions from 42.68.1 before 42.96.3 and from 43.0.0 before 43.4.4, including the renovate/renovate Docker images, and Mend Renovate CE/EE images (renovate-ce, renovate-ee-server, renovate-ee-worker) from 13.3.0 before 13.6.0, fail to restrict environment variables to an allowlist when spawning child processes. As a result, child processes (e.g. npm install, postUpgradeTasks, postUpdateOptions) gain full access to all environment variables of the Renovate process, allowing insider or outside attackers to exfiltrate secrets accessible to the Renovate deployment. |
| Renovate versions from 43.65.0 before 43.102.11 contain a remote code execution vulnerability in bazel-module and bazelisk managers when using lockFileMaintenance. Attackers can execute arbitrary code by providing malicious dependencies that are referenced in bazel mod deps calls, such as within ctx.execute statements. |
| Renovate versions 37.158.0 before 37.199.0 contain a command injection vulnerability in the helmv3 manager's registryAliases handling that allows attackers with commit access to execute arbitrary commands. Attackers can manipulate registryAliases keys with unquoted shell metacharacters to inject commands executed during helm repo add operations, gaining full access to Renovate's execution environment. |
| A vulnerability was determined in Freedesktop Poppler 26.06.0/26.07.0/26.08.0. This impacts the function FoFiTrueType::cvtSfnts of the file fofi/FoFiTrueType.cc. This manipulation causes integer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 245d3c6823377755f2c1d5fdddd010279c6ed94d. It is suggested to install a patch to address this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix use-after-free race in sample_restore_put()
Concurrent teardown of TC sample rules sharing the same restore
context may re-read restore->count after dropping restore_lock.
At that point another thread may already have completed cleanup and
freed the restore object.
Use the result of the refcount decrement while holding restore_lock to
determine whether cleanup is needed. |
