Export limit exceeded: 408833 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (408833 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-55414 | 2026-10-15 | 5.3 Medium | ||
| NL Portal Backend Libraries provide backend components for Dutch government portals that interact with residents, customers, suppliers, and partner organizations. From 1.1.0 until 3.0.4, and in 3.1.0, the public getFormDefinitionByObjectenApiUrl and deprecated getFormDefinitionById GraphQL resolvers are reachable without CommonGroundAuthentication and forward a caller-influenced URL through ObjectenApiService.getObjectByUrl to ObjectsApiClient.getObjectByUrl, which attaches the privileged Objecten-API token. The host-equality check restricts requests to the configured Objecten-API host but does not constrain the scheme, port, or path, allowing an unauthenticated caller to induce a token-bearing request to a chosen endpoint on that host. Standard deployments are not exposed to cross-host SSRF, token capture requires attacker-controlled routing on the configured host, and typed deserialization limits returned data to objects shaped like form definitions. The 3.0 release line is fixed in version 3.0.4. The advisory does not identify a fixed 3.1 release. | ||||
| CVE-2026-55246 | 2026-10-15 | 7.8 High | ||
| bincookie is a header-only binarycookies parser. Prior to 0.1.9, bincookie_init_file() in bincookie.h allocates a buffer using the actual .binarycookies file length but trusts the file-controlled num_pages field as the loop bound for byte-swapping page_sizes entries. A crafted file can make the loop read and write beyond the heap allocation, and related unvalidated page sizes and cookie_offsets can drive additional out-of-bounds accesses in page and cookie iteration. Applications that parse an attacker-supplied binarycookies file may crash or suffer heap corruption that can potentially enable code execution. This issue is fixed in version 0.1.9. | ||||
| CVE-2026-48212 | 1 Otrs | 1 Otrs | 2026-10-15 | 4.8 Medium |
| An OTRS administrator can enter arbitrary JavaScript into the content of an OTRS Custom Page, which is stored by the application and subsequently executed in the browser of users accessing that page. This issue affects OTRS: * 7.0.X * 8.0.X * 2023.X * 2024.X * 2025.X * 2026.X before 2026.7.X | ||||
| CVE-2026-48211 | 1 Otrs | 2 Otrs, Otrs Community Edition | 2026-10-15 | 5.4 Medium |
| An authenticated administrator can be induced to delete administrative Import/Export templates through a Cross-Site Request Forgery (CSRF) attack. The OTRS AdminImportExport::TemplateDelete action does not validate the request's ChallengeToken, allowing an unauthenticated remote attacker to craft a malicious request that is executed with the privileges of an active administrator session. This issue affects OTRS: * 7.0.X * 8.0.X * 2023.X * 2024.X * 2025.X * 2026.X before 2026.7.X Please note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected | ||||
| CVE-2026-45449 | 2026-10-15 | 8.3 High | ||
| : Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Unitronics Unitronics UniStream Pro/UniLogic. This issue affects Unitronics UniStream Pro/UniLogic: Unitronics UniStream Pro versions only (B10 / C10) – UniLogic versions prior to 1.41.329. | ||||
| CVE-2026-24715 | 2026-10-15 | N/A | ||
| An observable timing discrepancy vulnerability has been reported to affect QuRouter. If exploited, the vulnerability could allow remote attackers to obtain sensitive data. We have already fixed the vulnerability in the following version: QuRouter 2.7.2.113 and later | ||||
| CVE-2026-22896 | 2026-10-15 | N/A | ||
| A cross-site scripting (XSS) vulnerability has been reported to affect Network & Virtual Switch. If a remote attacker gains an administrator account, they can then exploit the vulnerability to inject malicious code. We have already fixed the vulnerability in the following version: Network & Virtual Switch in QTS 5.1.8.2823 build 20240712 and later Network & Virtual Switch in QTS 5.2.1.2930 build 20241025 and later Network & Virtual Switch in QuTS cloud c5.2.4.3041 build 20250211 and later Network & Virtual Switch in QuTS hero h5.1.8.2823 build 20240712 and later Network & Virtual Switch in QuTS hero h5.2.1.2929 build 20241025 and later | ||||
| CVE-2026-21139 | 1 Samsung Mobile | 1 Samsung Continuity Service For Windows | 2026-10-15 | N/A |
| Improper access control in Samsung Continuity Service for windows prior to version 4.6.1217.0 allows adjacent attackers to manipulate the connected mobile device. | ||||
| CVE-2026-21138 | 1 Samsung | 1 Smart Switch | 2026-10-15 | N/A |
| Insufficient verification of data authenticity in Smart Switch prior to version 3.7.73 allows physical attackers to install arbitrary applications. | ||||
| CVE-2026-21136 | 1 Samsung | 1 Smart Switch | 2026-10-15 | N/A |
| Improper authorization in Smart Switch prior to version 3.7.73 allows physical attackers to invoke application restore process. | ||||
| CVE-2026-21132 | 1 Samsung Mobile | 1 Samsung Internet | 2026-10-15 | N/A |
| Improper input validation in Samsung Internet prior to version 30.0.5.24 allows remote attackers to inject arbitrary script. User interaction is required for triggering this vulnerability. | ||||
| CVE-2026-1907 | 2 Kong, Konghq | 2 Kong Enterprise Gateway, Kong Gateway | 2026-10-15 | N/A |
| A SQL Injection (SQLi) affects the Kong Gateway (Enterprise and Open Source) clustering communication logic when operating in Hybrid Mode. The issue can be triggered by sending specially crafted RPC requests to the Control Plane (CP), leading to potential unauthorized database access. Leveraging the issue requires network access to the Control Plane’s clustering port and a valid client certificate and key. | ||||
| CVE-2026-19736 | 1 Zephyrproject | 1 Zephyr | 2026-10-15 | 7.8 High |
| The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes. entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the overflow can land in adjacent kernel state. The same defect is reached from kernel mode by any caller requesting a non-word-multiple length, including getentropy() and, in builds where sys_csrand_get()/sys_rand_get() resolve to the hardware generator, sys_rand8_get() and sys_rand16_get(). Impact is memory corruption of up to 127 bytes immediately following the supplied buffer — typically the caller's stack in kernel-mode use, or memory outside the caller's partition when driven through the syscall. The overflow offset is fully determined by the requested length and is therefore deterministic, while the written content is uncontrolled TRNG output; the practical consequences range from crashes and unpredictable state corruption to opportunistic escalation when kernel bookkeeping such as object permission bitmaps is overwritten. The affected devices are those where the MCUX SDK enables TRNG_SW_HEALTH_TESTS (MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, MIMXRT633S), on which the TRNG is the zephyr,entropy chosen node; other SoCs using this driver take the SDK path that clamps the copy size and are unaffected. The fix routes any unaligned prefix and any sub-word tail through a local bounce word and hands the SDK only word-multiple sizes, so the SDK's word-granular writes can no longer pass the end of the caller's buffer. | ||||
| CVE-2026-19669 | 1 Zephyrproject | 1 Zephyr | 2026-10-15 | 7.8 High |
| The user-mode syscall verifiers z_vrfy_fuel_gauge_get_props() and z_vrfy_fuel_gauge_set_props() in drivers/fuel_gauge/fuel_gauge_syscall_handlers.c declared two variable-length arrays, union fuel_gauge_prop_val k_vals[len] and fuel_gauge_prop_t k_props[len], sized directly by the caller-supplied len argument. len is an unvalidated size_t taken straight from the syscall ABI, and the VLAs were allocated before any check at all — including before the K_SYSCALL_DRIVER_FUEL_GAUGE() object-permission check. The subsequent k_usermode_from_copy() calls validated only that the user source buffer was readable; the kernel destination was never bounds-checked, since it was sized by the same attacker-chosen len. Any thread running in user mode with CONFIG_USERSPACE enabled can invoke fuel_gauge_get_props() or fuel_gauge_set_props() with a large len. This first displaces the supervisor stack pointer by an arbitrary attacker-chosen amount — Zephyr does not build with stack-clash probing, so the displacement itself does not fault, and the nested calls made by the verifier then write frames below the privileged stack. If the caller has been granted access to a fuel-gauge device object, the memcpy inside k_usermode_from_copy() additionally writes len * sizeof(union fuel_gauge_prop_val) bytes of fully attacker-controlled data starting well below the stack base. CONFIG_PRIVILEGED_STACK_SIZE defaults to 1024 bytes, so a len of roughly 170 already exhausts it. The result is an out-of-bounds write in supervisor mode with attacker-controlled length and, on the permitted path, attacker-controlled content — a break out of the user-mode sandbox into kernel memory, leading to kernel code execution or a system crash. A stack guard region does not contain it, because the copy begins below the guard and walks upward, corrupting unprotected memory before the guard is reached. The fix removes the kernel-side copies entirely and validates the caller's arrays in place with K_SYSCALL_MEMORY_ARRAY_READ() / K_SYSCALL_MEMORY_ARRAY_WRITE(), which also handle the len * size multiplication overflow; this is safe because neither fuel_gauge_prop_t nor union fuel_gauge_prop_val contains embedded pointers. | ||||
| CVE-2026-19577 | 1 Zephyrproject | 1 Zephyr | 2026-10-15 | 7.1 High |
| net_route_ipv6_packet() in subsys/net/ip/route_ipv6.c resolved the nexthop's link-layer address with net_nbr_get_lladdr(nbr->idx) without first checking whether the neighbor cache entry actually had a linked link-layer address. An unresolved neighbor carries idx == NET_NBR_LLADDR_UNKNOWN (0xff), and net_nbr_get_lladdr() in subsys/net/ip/nbr.c performs no runtime bounds check beyond a NET_ASSERT, returning &net_neighbor_lladdr[255] — roughly 2.5 KB past the end of an array whose default size is CONFIG_NET_IPV6_MAX_NEIGHBORS (8). Because the returned pointer is never NULL, the following lladdr == NULL guard does not catch it. The function is reached from ipv6_route_packet() in subsys/net/ip/ipv6.c for every received unicast IPv6 packet whose destination is not a local address on the receiving interface; CONFIG_NET_IPV6_ROUTE is enabled by default whenever the IPv6 neighbor cache is, so no router or forwarding configuration is needed. net_route_ipv6_get_info() returns the packet's destination itself as the nexthop when a neighbor cache entry for it exists, and the cache lookup does not skip INCOMPLETE entries. An unauthenticated attacker on the same link can therefore force the unresolved state — for example by eliciting traffic to a spoofed, non-existent neighbor address so that net_ipv6_send_ns() creates an INCOMPLETE entry, or by sending a Router Advertisement with no source link-layer address option, which creates a persistently unresolved router neighbor — and then send a packet addressed to that neighbor. The result is an out-of-bounds read at a fixed index past the neighbor link-layer address array. On builds with CONFIG_ASSERT enabled the assertion fires and the device panics, giving a repeatable remote denial of service. With assertions disabled, the stale out-of-bounds struct net_linkaddr drives a memcmp() over an attacker-uninfluenced length and, when its len byte passes the NET_LINK_ADDR_MAX_LENGTH check, up to 8 bytes of unrelated static RAM are copied into the outgoing frame's destination link-layer address and transmitted on the link, disclosing them to any listener. There is no out-of-bounds write and the offset is not attacker-controlled, which bounds the impact. | ||||
| CVE-2026-19576 | 1 Zephyrproject | 1 Zephyr | 2026-10-15 | 6.8 Medium |
| The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POINTS_MSK (0x0F), yielding a value of 0..15. In gt911_process() that value is used directly as the loop bound for filling point_reg[], a stack array sized to CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, whose Kconfig range is 1..5 with a default of 1. No other check constrains the count; the driver relied only on a comment asserting that the controller had been programmed at init to report no more points than configured. Each loop iteration issues an I2C read of eight bytes straight into point_reg[i], so a controller that reports more points than the array holds causes up to 112 bytes of peer-supplied data to be written past the end of the array, over the stack frame of gt911_process() in the system workqueue thread. Two further loops then read out of bounds from the same array. Triggering it requires control of, or the ability to substitute, the I2C touch controller — plausible on the many supported boards where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; a spoofed device need only answer the init probes with a supported product ID and a checksum-valid config blob. The same overflow can also occur non-adversarially, with a GT9271-class panel that ignores the driver's touch-count programming and reports up to ten points, or with bus corruption of the single status byte. The impact is an out-of-bounds stack write with fully attacker-chosen content executing at kernel privilege, i.e. potential control-flow hijack on the host MCU, in addition to out-of-bounds reads and crashes. The attack vector is physical/local hardware access only; there is no network, USB, or syscall path to the defect. The fix clamps the reported count with min() against CONFIG_INPUT_GT911_MAX_TOUCH_POINTS before any array indexing. | ||||
| CVE-2026-18418 | 1 Zephyrproject | 1 Zephyr | 2026-10-15 | 3.4 Low |
| The zbus proxy agent IPC backend in subsys/zbus/proxy_agent/zbus_proxy_agent_ipc.c logged the channel name of a rejected inter-domain frame with a plain %s conversion. The frame type struct zbus_proxy_msg carries a fixed-size channel_name[] array as its last member, and nothing in the transport guarantees the array is NUL-terminated. The only code that verifies termination is zbus_proxy_agent_receive_cb() in subsys/zbus/proxy_agent/zbus_proxy_agent.c, which rejects the frame in precisely those cases — so the warning printed a non-terminated buffer exactly on the error paths where the name had been found invalid (or, for an invalid message_size, had not been inspected at all). Any peer domain able to place a frame of sizeof(struct zbus_proxy_msg) bytes on the bound ipc_service endpoint can trigger it, by sending a frame with an out-of-range message_size or with channel_name[] containing no NUL byte. Reaching the code requires CONFIG_ZBUS_PROXY_AGENT_IPC and logging built at warning level or above (the default), and requires control over the firmware of the peer domain — typically a second core on the same SoC. The resulting strlen() inside the log packager walks past the end of the frame object until it finds a zero byte. With the icmsg backend the frame lives in a stack buffer of the IPC work-queue thread, so bytes of that thread's stack are rendered into the log message; with the rpmsg backends the scan continues through the shared vring memory. Impact is bounded to disclosure of a small amount of adjacent memory into the receiving domain's log sink, plus a possible fatal fault if the scan leaves a mapped region; the log packager's own -ENOSPC bound prevents the overrun from becoming a write. The fix bounds the conversion with %.*s and MIN(msg->channel_name_len, sizeof(msg->channel_name)). | ||||
| CVE-2026-111157 | 2026-10-15 | 6.1 Medium | ||
| SoX through 14.4.2 contains a heap out-of-bounds write vulnerability in lsx_ms_adpcm_block_expand_i() in src/adpcm.c, triggered by an odd samplesPerBlock value in the WAV fmt chunk. Attackers can supply a crafted MS ADPCM WAV file to sox or any libsox consumer to write a partially controlled 16-bit sample past the heap buffer allocated by wav_ms_adpcm_fmt(). | ||||
| CVE-2026-111137 | 2026-10-15 | 6.1 Medium | ||
| libsmi through 0.5.0 contains an out-of-bounds write vulnerability in smiValueAsString() in lib/smi.c that allows attackers to overflow a fixed 1024-byte static buffer through hex rendering of OCTET STRING values. Attackers can supply a crafted MIB with an OCTET STRING DEFVAL of 512 or more octets and a leading 0x00 byte to corrupt adjacent library globals and crash smidump or other consumers. | ||||
| CVE-2026-111132 | 1 Gnome | 1 Libgxps | 2026-10-15 | 6.1 Medium |
| GNOME libgxps through 0.3.2 contains a heap out-of-bounds read in path_geometry_start_element() that allows attackers to read past allocations via crafted PolyBezierSegment or PolyQuadraticBezierSegment Points attributes. Attackers can supply a point count not divisible by three or two in a crafted XPS document to crash consumers like Evince and render adjacent heap memory into output. | ||||