Export limit exceeded: 378294 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (378294 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-18428 | 2 Aws, Github | 2 Opensearch, Opensearch | 2026-08-13 | 8.8 High |
| A SQL query validation bypass in the Flint extension query handler in the OpenSearch SQL plugin allows a remote authenticated actor with async query access to execute arbitrary code on Apache Spark workers by sending a crafted SQL query to the direct query endpoint. | ||||
| CVE-2026-73557 | 1 Vllm-project | 1 Vllm | 2026-08-13 | 5.3 Medium |
| vLLM is an inference and serving engine for large language models. From 0.20.2rc0 until 0.26.0, safe_load_prompt_embeds in vllm/renderers/embed_utils.py uses torch.sparse.check_sparse_tensor_invariants, whose process-global save, enable, and restore state can be raced by concurrent prompt_embeds parts submitted to POST /v1/chat/completions through AsyncMultiModalItemTracker.resolve_items, asyncio.gather, and the default executor, allowing an invalid sparse tensor to reach tensor.to_dense despite the CVE-2025-62164 guard when enable_prompt_embeds is enabled. This issue is fixed in version 0.26.0. | ||||
| CVE-2026-59133 | 1 Microsoft | 2 Windows App, Windows App Client For Windows Desktop | 2026-08-13 | 8.8 High |
| Execution with unnecessary privileges in Microsoft High Performance Computing (HPC) Pack allows an authorized attacker to elevate privileges over a network. | ||||
| CVE-2025-59322 | 1 Cpsd | 1 Cryptopro Securedisk For Bitlocker | 2026-08-13 | 7.5 High |
| CPSD CryptoPro Secure Disk for Bitlocker before v7.7.4 fails to properly handle decryption errors and allows encrypted volumes to be mounted as plaintext. | ||||
| CVE-2026-14857 | 2026-08-13 | 4.3 Medium | ||
| The WP Crowdfunding WordPress plugin before 2.2.1 does not verify ownership of a campaign before allowing its update history to be modified and a notification email sent to its backers, allowing any authenticated users such as Subscribers to alter other users' campaigns. | ||||
| CVE-2026-18750 | 1 Cert | 1 Vince | 2026-08-13 | 5.3 Medium |
| vinny/views.py: (ModifyEmailNotifications) IDOR: view fetches VinceCommEmail by raw pk from URL and toggles email_function/name without checking the record's contact belongs to the requesting group-admin. Lets a vendor admin flip notification routing (or read email/name) for another vendor's contact. | ||||
| CVE-2026-18749 | 1 Cert | 1 Vince | 2026-08-13 | 9.8 Critical |
| The type=track branch authorises on _is_my_case(t_attach.case) only and never checks VinceTrackAttachment.shared. A coordinator-uploaded case artefact that has NOT been marked shared is still retrievable by any case member who has (or is sent) its uuid — leaks not-yet-released coordinator material to vendors on the case. | ||||
| CVE-2026-67986 | 2026-08-13 | 8.4 High | ||
| amazing-print/amazing_print at commit dc890dfafdf07088ea901df53c19c2710e5c5234 contains a Ruby code injection condition in AwesomeMethodArray#grep. A specially named method containing Ruby interpolation syntax can be interpolated into a dynamically constructed eval string when grep is called with a block, resulting in Ruby code execution in the host process. Exploitation requires an application path that allows an attacker to influence dynamic method names. | ||||
| CVE-2026-67990 | 2026-08-13 | 5.4 Medium | ||
| basecamp/upright at commit efe4f2e5254ac6e57e45d2261804cca74dbbca3f disables Rails CSRF protection for its Alertmanager and Prometheus proxy controllers. An unauthenticated attacker can induce a logged-in user's browser to submit requests that are forwarded to enabled upstream write or management endpoints, such as creating an Alertmanager silence or requesting a Prometheus reload. The final impact depends on the APIs enabled by the upstream services. | ||||
| CVE-2026-66698 | 2 Brainstorm Force, Wordpress | 2 Suredash, Wordpress | 2026-08-13 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in SureDash <= 1.10.1 versions. | ||||
| CVE-2026-73564 | 1 Fatedier | 1 Frp | 2026-08-13 | N/A |
| frp is a fast reverse proxy. From 0.53.0 until 0.70.1, frp's optional SSH Tunnel Gateway in pkg/ssh/server.go parses an SSH exec channel request by adding 4 to an attacker-controlled four-byte big-endian length. A length of 0xFFFFFFFF makes the uint32 addition wrap to 3, defeats the payload bounds check, and causes payload[4:3] to panic in TunnelServer.handleNewChannel. When no authorized-keys file is configured, sshConfig.NoClientAuth permits an unauthenticated peer to reach this channel phase before the frp token is checked, so a single five-byte request terminates the frps process and drops every active tunnel. This issue is fixed in version 0.70.1. | ||||
| CVE-2026-64246 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use. | ||||
| CVE-2026-64248 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: MIPS: smp: report dying CPU to RCU in stop_this_cpu() smp_send_stop() parks all secondary CPUs in stop_this_cpu(). The function marks the CPU offline for the scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled. As long as nothing waits for an RCU grace period after smp_send_stop() this is harmless, which is why it went unnoticed. Since commit 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT") however, irq_work_sync() calls synchronize_rcu() on architectures without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns false. That is the asm-generic default used by MIPS. Any irq_work_sync() issued in the reboot/shutdown path after smp_send_stop() then blocks on a grace period that can never complete, hanging the reboot: WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on ... rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP. This issue was noticed on several Realtek MIPS switch SoCs (MIPS interAptiv) and came up during kernel bump downstream in OpenWrt from 6.18.33 to 6.18.34, after the backport of the patch to the 6.18 stable branch. The patch also has been backported all the way back to 6.1. Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. MIPS shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued. Reporting a dying CPU to RCU outside the regular hotplug offline path is not unprecedented: arm64 does the same in cpu_die_early(). There it is an exception for a CPU that was coming online and is aborting bringup, rather than the default shutdown action as on MIPS. | ||||
| CVE-2026-64249 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ] | ||||
| CVE-2026-64269 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE). | ||||
| CVE-2026-64270 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: mms114 - reject an oversized device packet size mms114_interrupt() reads a packet of touch data from the device into a fixed-size on-stack buffer struct mms114_touch touch[MMS114_MAX_TOUCH]; which holds MMS114_MAX_TOUCH (10) events of MMS114_EVENT_SIZE (8) bytes, i.e. 80 bytes. The length of the I2C read into it is taken verbatim from the device: packet_size = mms114_read_reg(data, MMS114_PACKET_SIZE); if (packet_size <= 0) goto out; ... error = __mms114_read_reg(data, MMS114_INFORMATION, packet_size, (u8 *)touch); packet_size is a single device register byte (0x0F) and the only check is the lower bound packet_size <= 0; it is never bounded against the size of touch[]. A malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can report a packet_size of up to 255, so __mms114_read_reg() writes up to 175 bytes past the end of touch[] on the IRQ-thread stack: a stack out-of-bounds write that can overwrite the stack canary, saved registers and the return address. A well-formed device never reports more than the buffer holds, so reject an oversized packet and drop the report, consistent with the handler's other error paths, rather than reading past the buffer. | ||||
| CVE-2026-64271 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: tw->data[tw->idx++] = data; if (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { ... tw->idx = 0; } The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do. | ||||
| CVE-2026-64272 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: mms114 - fix touch indexing for MMS134S and MMS136 The MMS134S and MMS136 touch controllers have an event size of 6 bytes rather than 8 bytes. When __mms114_read_reg() reads the touch data packet from the device into the touch buffer, the events are packed tightly at 6-byte intervals. However, the driver iterates through the events using standard C array indexing (touch[index]), where each element is sizeof(struct mms114_touch) (8 bytes) apart. As a result, any touch events beyond the first one are read from incorrect offsets and parsed improperly. Fix this by explicitly calculating the byte offset for each touch event based on the device's specific event size. | ||||
| CVE-2026-64273 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: i = data[1] & 0x7f; if (data[1] & 0x80) { if (!test_and_set_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) ... } else if (test_and_clear_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) { ... } The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate "effect started/stopped" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched. | ||||
| CVE-2026-64274 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration. | ||||