| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Vaadin Charts renders charts with the Highcharts library and pins an exact version of it, 9.2.2 in Vaadin 22 to 24 and 12.2.0 in Vaadin 25, so an application cannot remove these vulnerabilities by upgrading Highcharts on its own. Highsoft disclosed several vulnerabilities in that library that are reachable through the chart configuration: writes to Object.prototype through dotted series.keys paths, and cross-site scripting through credits.href, through breadcrumbs.style, through HTML text parsing while printing, and through xlink:href attributes in exported charts. An application is affected where data an attacker controls reaches the chart configuration, for example through additionalOptions, through updateConfiguration(), or through text options that accept markup. The fixed Vaadin versions apply Highsoft's recommended workarounds to the bundled Highcharts when it loads, and keep the same Highcharts version.
Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:
Product version
Vaadin 22.0.0 - 23.6.15
Vaadin 24.0.0 - 24.4.23
Vaadin 24.5.0 - 24.7.15
Vaadin 24.8.0 - 24.9.22
Vaadin 24.10.0 - 24.10.10
Vaadin 25.0.0 - 25.2.9
Vaadin 25.3.0
Mitigation
Upgrade to 23.6.16
Upgrade to 24.4.24
Upgrade to 24.7.16
Upgrade to 24.9.23
Upgrade to 24.10.11
Upgrade to 25.2.10
Upgrade to 25.3.1 or newer
Please note that Vaadin versions 10-13 and 15-22 are no longer supported and you should update either to the latest 23, 24, 25 version.
Artifacts
Maven coordinates / Vulnerable versions / Fixed version
com.vaadin:vaadin / 22.0.0 - 23.6.15 / >=23.6.16
com.vaadin:vaadin / 24.0.0 - 24.4.23 / >=24.4.24
com.vaadin:vaadin / 24.5.0 - 24.7.15 / >=24.7.16
com.vaadin:vaadin / 24.8.0 - 24.9.22 / >=24.9.23
com.vaadin:vaadin / 24.10.0 - 24.10.10 / >=24.10.11
com.vaadin:vaadin / 25.0.0 - 25.0.13 / >=25.2.10
com.vaadin:vaadin / 25.1.0 - 25.1.13 / >=25.2.10
com.vaadin:vaadin / 25.2.0 - 25.2.9 / >=25.2.10
com.vaadin:vaadin / 25.3.0 / >=25.3.1
com.vaadin:vaadin-charts-flow / 22.0.0 - 23.6.15 / >=23.6.16
com.vaadin:vaadin-charts-flow / 24.0.0 - 24.4.22 / >=24.4.24
com.vaadin:vaadin-charts-flow / 24.5.0 - 24.7.14 / >=24.7.15
com.vaadin:vaadin-charts-flow / 24.8.0 - 24.9.22 / >=24.9.23
com.vaadin:vaadin-charts-flow / 24.10.0 - 24.10.10 / >=24.10.11
com.vaadin:vaadin-charts-flow / 25.0.0 - 25.0.13 / >=25.2.10
com.vaadin:vaadin-charts-flow / 25.1.0 - 25.1.13 / >=25.2.10
com.vaadin:vaadin-charts-flow / 25.2.0 - 25.2.9 / >=25.2.10
com.vaadin:vaadin-charts-flow / 25.3.0 / >=25.3.1
com.vaadin:vaadin-charts-flow-svg-generator / 21.0.0 - 23.6.15 / >=23.6.16
com.vaadin:vaadin-charts-flow-svg-generator / 24.0.0 - 24.4.22 / >=24.4.24
com.vaadin:vaadin-charts-flow-svg-generator / 24.5.0 - 24.7.14 / >=24.7.15
com.vaadin:vaadin-charts-flow-svg-generator / 24.8.0 - 24.9.22 / >=24.9.23
com.vaadin:vaadin-charts-flow-svg-generator / 24.10.0 - 24.10.10 / >=24.10.11
com.vaadin:vaadin-charts-flow-svg-generator / 25.0.0 - 25.0.13 / >=25.2.10
com.vaadin:vaadin-charts-flow-svg-generator / 25.1.0 - 25.1.13 / >=25.2.10
com.vaadin:vaadin-charts-flow-svg-generator / 25.2.0 - 25.2.9 / >=25.2.10
com.vaadin:vaadin-charts-flow-svg-generator / 25.3.0 / >=25.3.1
npm packages
npm package / Vulnerable versions / Fixed version
@vaadin/charts / 22.0.0 - 23.6.6 / >=23.6.7
@vaadin/charts / 24.0.0 - 24.4.18 / >=24.4.19
@vaadin/charts / 24.5.0 - 24.7.12 / >=24.7.13
@vaadin/charts / 24.8.0 - 24.9.18 / >=24.9.19
@vaadin/charts / 24.10.0 - 24.10.6 / >=24.10.7
@vaadin/charts / 25.0.0 - 25.0.13 / >=25.2.14
@vaadin/charts / 25.1.0 - 25.1.14 / >=25.2.14
@vaadin/charts / 25.2.0 - 25.2.13 / >=25.2.14
@vaadin/charts / 25.3.0 / >=25.3.1 |
| OpenJPEG 2.4.0 through 2.5.4, and git master through commit 8314119b, contains an out-of-bounds read and write in opj_dwt_encode_and_deinterleave_v() in src/lib/openjp2/dwt.c. This allows an attacker to cause a denial of service. |
| PEAK-System PCAN contains a vulnerable operation involving a variable-length receive-record copy. The driver uses a requested or queued record count without sufficiently capping the copy to the actual caller-supplied output length. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, pattern_to_regex maps % -> .*? and _ -> ., then compiles ^...$ with only [unicode]; re:run is called with only [{capture, none}] - no explicit match_limit. A pattern like %_%_..._%X becomes ^.*?..*?.....*?.X$ with overlapping lazy quantifiers. The whole-expression cap is ?MAX_EXPRESSION_LENGTH=4096 chars / ?MAX_TOKENS=200; a LIKE string literal is one token, so ~2000 %_ pairs fit. SQL filters are accepted unconditionally at rabbit_amqp_session.erl:3264 (no feature flag). Evaluated per-message at rabbit_stream_queue.erl:1439. OTP's default 10M match_limit caps each match at ~100-200 ms (not seconds), and the re NIF yields to the scheduler. An authenticated AMQP 1.0 consumer with read+write on a stream queue can cause ~100-200 ms of CPU per delivered message via a crafted LIKE filter, multiplied across thousands of messages and parallel sessions - a substantial backtracking-driven CPU amplification. Preconditions include AMQP 1.0 with stream queues in use Attacker can attach a receiver with a filter (read permission) and publish messages with long property values (write permission). This issue is fixed in versions 4.2.7 and 4.3.1. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The stream open handler calls only check_vhost_access; it omits the node/vhost/user connection-limit checks that rabbit_reader performs for AMQP. A developer %% FIXME comment at the cited line explicitly acknowledges the gap. No compensating enforcement exists in connection tracking or elsewhere in rabbitmq_stream. An authenticated tenant can fully bypass operator-configured per-user and per-vhost connection caps by connecting via port 5552 instead of 5672. Preconditions include rabbitmq_stream plugin enabled Authenticated stream-protocol credentials Operator relies on per-user/per-vhost connection limits for tenant isolation. This issue is fixed in versions 4.2.7 and 4.3.1. |
| A flaw was found in the libstdc++ component of GCC. An attacker who can provide an excessively large element count to a boolean vector (std::vector<bool>) constructor can trigger an integer wrap during internal memory calculations. This issue leaves the container in an inconsistent state, leading to out-of-bounds memory access and resulting in an application crash or a Denial of Service (DoS) during subsequent operations. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: esp: restore combined single-frag length gate
The ESP out-of-place fast path appends the trailer in esp_output_head()
before esp_output_tail() allocates the destination page frag. The
head-side gate currently checks skb->data_len and tailen separately, but
the tail code allocates a single destination frag from the combined
post-trailer skb->data_len.
Reject the page-frag fast path when the combined aligned length exceeds a
page. Otherwise skb_page_frag_refill() may fall back to a single page while
the destination sg still spans the combined skb->data_len.
Restore this combined-length page gate for both IPv4 and IPv6. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: hci: fix out-of-bounds read in HCP header parsing
Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read
packet->header from skb->data at function entry without first checking
that the buffer holds at least one byte. A malicious NFC peer can send
a 0-byte HCP frame that passes through the SHDLC layer and reaches
these functions, causing an out-of-bounds heap read of packet->header.
The same 0-byte frame, if queued as a non-final fragment, also causes
the reassembly loop to underflow msg_len to UINT_MAX, triggering
skb_over_panic() when the reassembled skb is written.
Fix this by adding a pskb_may_pull() check at the entry of each
function before packet->header is first accessed. The existing
pskb_may_pull() checks before the reassembled hcp_skb is cast to
struct hcp_packet remain in place to guard the 2-byte HCP message
header. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers
Properly validate the count passed from a device when calling
svdm_consume_identity() or svdm_consume_identity_sop_prime() as the
device-controlled value could index off of the static arrays, which
could leak data. |
| Missing queue-set type validation in the queue-set selection system call in FreeRTOS-Kernel before V11.3.3 on MPU-enabled ports with queue sets enabled allows a local unprivileged task to write actor-controlled data beyond a pointer-sized object on the privileged kernel stack, affecting privileged memory across the MPU isolation boundary.
To remediate this issue, users should upgrade to FreeRTOS-Kernel V11.3.3, rebuild, and reflash affected firmware. Builds that do not enable queue sets are not affected. |
| Memory corruption in Autofill in Google Chrome prior to 156.0.8078.79 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Wekan is open source kanban built with Meteor. Prior to 11.11, the user-search publication in server/publications/users.js and the searchUsers method in server/models/users.js pass authenticated user-controlled searchTerm and query values to new RegExp() without escaping regular-expression metacharacters. MongoDB-backed deployments evaluate the resulting patterns with PCRE2, allowing a logged-in user to submit catastrophic-backtracking expressions that consume database CPU and degrade or deny service to other users; searchUsers additionally requires board membership or site-admin status. The FerretDB v1 / RE2 unaffected configuration is not practically affected by catastrophic backtracking. This issue is fixed in version 11.11. |
| A flaw was found in rsyslog. An unauthenticated remote attacker can trigger a heap buffer overflow in the RainerScript `replace()` function by sending specially crafted syslog messages. This vulnerability arises from an incorrect buffer size calculation during string replacement, causing memory corruption. Successful exploitation can lead to a denial of service (DoS) for the affected system. |
| A unauthenticated remote peer may lead rsyslogd to crash due to a flaw in the optional imptcp module. A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected. |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.10, the ReadableByteBuf.readLength() and ReadableByteBuf.readIntLengthEncodedNotNull() methods narrowed the protocol's unsigned 8-byte length-encoded integer to a Java int without checking that the value fit a non-negative integer. Values above Integer.MAX_VALUE could wrap to a negative or unrelated length that downstream allocation and read paths used. A malicious or compromised server, or a machine-in-the-middle attacker, could trigger NegativeArraySizeException, out-of-bounds failures, or oversized allocation behavior in client connection handling. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.10. |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, decoders for OK packet session-state blocks, column definition packets, text row data, or binary row data used server-declared lengths without confirming that the requested bytes remained in the receive buffer. The decoders could position reads, create sub-buffers, or decode strings beyond the packet boundary. A malicious or compromised server, or a machine-in-the-middle attacker, could trigger unchecked ArrayIndexOutOfBoundsException or IllegalArgumentException failures inside JDBC calls and terminate connection handling. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11. |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, when CLIENT_SESSION_TRACK was negotiated, the OkPacket.parse() and OkPacket.parseWithInfo() paths allocated byte arrays using server-declared lengths for the OK packet info field and session-state variable names and values before confirming that the bytes remained in the packet. A malicious or compromised server, or a machine-in-the-middle attacker, could send a small OK packet declaring a much larger length and repeatedly force attacker-controlled heap allocations before the subsequent copy failed. This could create garbage-collection pressure or an OutOfMemoryError in the client application. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11. |
| MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the MariaDbPoolConnection.recover() and MariaDbPoolPinnedConnection.recover() implementations trusted the gtrid_length and bqual_length columns returned by XA RECOVER. The methods allocated and split Xid byte arrays without validating the lengths against Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE, or the actual data payload. A malicious or compromised server, or a machine-in-the-middle attacker, could cause large allocations, NegativeArraySizeException, or ArrayIndexOutOfBoundsException during XA recovery. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11. |
| An out-of-bounds read vulnerability exists in the streaming RPC client of Apache bRPC (versions 1.11.0 through 1.17.0) on all platforms. A client that creates multiple streams in a single RPC expects the server response to carry exactly one extra_stream_id for every additional stream. The response handling path indexed the returned identifiers using the locally created stream count without first validating the size of the returned list, so a malicious or compromised server (or an on-path attacker) can trigger an out-of-bounds read in the client by returning a malformed StreamSettings response with fewer extra_stream_ids than expected. This may crash the client process (denial of service) or leak unintended memory contents into subsequent stream handling; surplus identifiers have no valid client-stream mapping and are processed inconsistently.
Root Cause:
Since bRPC 1.11.0, a client can create multiple streams in one RPC via batch StreamCreate. The expected behavior is that the server response must return exactly (N-1) extra_stream_ids, where N is the number of locally created streams. In Controller::HandleStreamConnection, the response path reads extra_stream_ids[i-1] for each additional local stream without first comparing the returned list size with (N-1). If the server returns fewer identifiers, the read runs past the end of the returned list (out-of-bounds read); if it returns more, the surplus identifiers have no corresponding client-side stream.
Affected Scenarios:
A bRPC client using multi-stream RPC (creating more than one stream in a single RPC) that connects to an untrusted, malicious, or compromised server or to a server reached through an untrusted network path. The server sends a malformed StreamSettings response to trigger the issue.
How to Fix:
(Choose one of the following options)
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3485
Note:
The fix makes the client reject responses whose extra_stream_ids count does not exactly match the number of additional client streams. Such mismatched responses now fail the RPC with ERESPONSE and go through the existing stream cleanup path, instead of being partially processed. |
| Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the forge.http client stored cookie names and paths from Set-Cookie response headers in ordinary JavaScript objects. A malicious server could use the cookie name __proto__ so that the attacker-controlled cookie path was written as a property on Object.prototype, or use inherited names such as constructor to modify Object. An empty cookie value could use the removal path to delete an inherited Object.prototype property. Applications using forge.http directly or through forge.xhr are affected; applications that do not use forge.http are unaffected. This issue is fixed in version 1.4.1. |
