| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| GStreamer rtpqdm2depay Out-Of-Bounds Write Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.
The specific flaw exists within the processing of X-QDM RTP payload elements. When parsing the packetid element, the process does not properly validate user-supplied data, which can result in a write past the end of an allocated array. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28850. |
| GStreamer H.266 Codec Parser Integer Underflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.
The specific flaw exists within the parsing of picture partitions. The issue results from the lack of proper validation of user-supplied data, which can result in an integer underflow before writing to memory. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-28910. |
| cpp-httplib is a C++11 single-file header-only cross platform HTTP/HTTPS library. Prior to 0.37.2, when a cpp-httplib client is configured with a proxy and set_follow_location(true), any HTTPS redirect it follows will have TLS certificate and hostname verification silently disabled on the new connection. The client will accept any certificate presented by the redirect target — expired, self-signed, or forged — without raising an error or notifying the application. A network attacker in a position to return a redirect response can fully intercept the follow-up HTTPS connection, including any credentials or session tokens in flight. This vulnerability is fixed in 0.37.2. |
| AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. In 1.11.1 and earlier, a SQL injection vulnerability in the built-in SQL Agent plugin allows any user who can invoke the agent to execute arbitrary SQL commands on connected databases. The getTableSchemaSql() method in all three database connectors (MySQL, PostgreSQL, MSSQL) constructs SQL queries using direct string concatenation of the table_name parameter without sanitization or parameterization. |
| PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, The crsf_rc parser accepts an oversized variable-length known packet and copies it into a fixed 64-byte global buffer without a bounds check. In deployments where crsf_rc is enabled on a CRSF serial port, an adjacent/raw-serial attacker can trigger memory corruption and crash PX4. This vulnerability is fixed in 1.17.0-rc2. |
| PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, the Zenoh uORB subscriber allocates a stack VLA directly from the incoming payload length without bounds. A remote Zenoh publisher can send an oversized fragmented message to force an unbounded stack allocation and copy, causing a stack overflow and crash of the Zenoh bridge task. This vulnerability is fixed in 1.17.0-rc2. |
| Runtipi is a personal homeserver orchestrator. Prior to 4.8.1, The Runtipi /api/auth/verify-totp endpoint does not enforce any rate limiting, attempt counting, or account lockout mechanism. An attacker who has obtained a user's valid credentials (via phishing, credential stuffing, or data breach) can brute-force the 6-digit TOTP code to completely bypass two-factor authentication. The TOTP verification session persists for 24 hours (default cache TTL), providing an excessive window during which the full 1,000,000-code keyspace (000000–999999) can be exhausted. At practical request rates (~500 req/s), the attack completes in approximately 33 minutes in the worst case. This vulnerability is fixed in 4.8.1. |
| This issue affects Apache Spark: before 3.5.7 and 4.0.1. Users are recommended to upgrade to version 3.5.7 or 4.0.1 and above, which fixes the issue.
Summary
Apache Spark 3.5.4 and earlier versions contain a code execution vulnerability in the Spark History Web UI due to overly permissive Jackson deserialization of event log data. This allows an attacker with access to the Spark event logs directory to inject malicious JSON payloads that trigger deserialization of arbitrary classes, enabling command execution on the host running the Spark History Server.
Details
The vulnerability arises because the Spark History Server uses Jackson polymorphic deserialization with @JsonTypeInfo.Id.CLASS on SparkListenerEvent objects, allowing an attacker to specify arbitrary class names in the event JSON. This behavior permits instantiating unintended classes, such as org.apache.hive.jdbc.HiveConnection, which can perform network calls or other malicious actions during deserialization.
The attacker can exploit this by injecting crafted JSON content into the Spark event log files, which the History Server then deserializes on startup or when loading event logs. For example, the attacker can force the History Server to open a JDBC connection to a remote attacker-controlled server, demonstrating remote command injection capability.
Proof of Concept:
1. Run Spark with event logging enabled, writing to a writable directory (spark-logs).
2. Inject the following JSON at the beginning of an event log file:
{
"Event": "org.apache.hive.jdbc.HiveConnection",
"uri": "jdbc:hive2://<IP>:<PORT>/",
"info": {
"hive.metastore.uris": "thrift://<IP>:<PORT>"
}
}
3. Start the Spark History Server with logs pointing to the modified directory.
4. The Spark History Server initiates a JDBC connection to the attacker’s server, confirming the injection.
Impact
An attacker with write access to Spark event logs can execute arbitrary code on the server running the History Server, potentially compromising the entire system. |
| The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a "decompression bomb") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive.
The vulnerability exists in the PerMessageDeflate.decompress() method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold. |
| Authentication bypass by capture-replay vulnerability in ABB AWIN GW100 rev.2, ABB AWIN GW120.This issue affects AWIN GW100 rev.2: 2.0-0, 2.0-1; AWIN GW120: 1.2-0, 1.2-1. |
| Missing authentication for critical function vulnerability in ABB AWIN GW100 rev.2, ABB AWIN GW120.This issue affects AWIN GW100 rev.2: 2.0-0, 2.0-1; AWIN GW120: 1.2-0, 1.2-1. |
| Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the 'DEFAULT' keyword.
Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client's initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
were treated as a single sufficiently secure 'tuple', with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.
As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
configuration results in only 'classical' groups (such as 'X25519' being the
only ones in the client's initial keyshare prediction).
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
list of groups, and treated all the supported groups as sufficiently secure.
If any of the keyshares predicted by the client were supported by the server
the most preferred among these was selected, even if other groups supported by
the client, but not included in the list of predicted keyshares would have been
more preferred, if included.
The new syntax partitions the groups into distinct 'tuples' of roughly
equivalent security. Within each tuple the most preferred group included among
the client's predicted keyshares is chosen, but if the client supports a group
from a more preferred tuple, but did not predict any corresponding keyshares,
the server will ask the client to retry the ClientHello (by issuing a Hello
Retry Request or HRR) with the most preferred mutually supported group.
The above works as expected when the server's configuration uses the built-in
default group list, or explicitly defines its own list by directly defining the
various desired groups and group 'tuples'.
No OpenSSL FIPS modules are affected by this issue, the code in question lies
outside the FIPS boundary.
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue. |
| There is a memory corruption vulnerability due to an out-of-bounds write when loading a corrupted DSB file in Digilent DASYLab. This vulnerability may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted .DSB file. This vulnerability affects all versions of Digilent DASYLab. |
| There is a memory corruption vulnerability due to an out-of-bounds write when loading a corrupted file in Digilent DASYLab. This vulnerability may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted file. This vulnerability affects all versions of Digilent DASYLab. |
| There is a memory corruption vulnerability due to an out-of-bounds read when loading a corrupted file in Digilent DASYLab. This vulnerability may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted file. This vulnerability affects all versions of Digilent DASYLab. |
| There is a memory corruption vulnerability due to an out-of-bounds read when loading a corrupted file in Digilent DASYLab. This vulnerability may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted file. This vulnerability affects all versions of Digilent DASYLab. |
| ImpactA server can reply with a WebSocket frame using the 64-bit length form and an extremely large length. undici's ByteParser overflows internal math, ends up in an invalid state, and throws a fatal TypeError that terminates the process.
Patches
Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later. |
| ImpactThe undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the server_max_window_bits parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range server_max_window_bits value (outside zlib's valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination.
The vulnerability exists because:
* The isValidClientWindowBits() function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15
* The createInflateRaw() call is not wrapped in a try-catch block
* The resulting exception propagates up through the call stack and crashes the Node.js process |
| OneUptime is a solution for monitoring and managing online services. Prior to 10.0.23, the Markdown viewer component renders Mermaid diagrams with securityLevel: "loose" and injects the SVG output via innerHTML. This configuration explicitly allows interactive event bindings in Mermaid diagrams, enabling XSS through Mermaid's click directive which can execute arbitrary JavaScript. Any field that renders markdown (incident descriptions, status page announcements, monitor notes) is vulnerable. This vulnerability is fixed in 10.0.23. |
| Inappropriate implementation in V8 in Google Chrome prior to 146.0.7680.75 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) |
