Export limit exceeded: 420087 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (420087 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-12629 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 4.6 Medium |
| The ARM PL011 UART driver in drivers/serial/uart_pl011.c fails to acknowledge receive error interrupts. On the PL011, the framing, parity, break, and overrun error interrupts (PL011_IMSC_ERROR_MASK) are cleared only by writing the interrupt-clear register UARTICR; reading the data register clears the RX interrupt and the per-byte RSR status but not the error interrupt status in MIS. The interrupt service routine pl011_isr() acknowledged only the CTS modem-status interrupt and never wrote icr for the error bits, so an asserted error interrupt remains pending after the ISR returns. When an application enables error-interrupt reporting via the public uart_irq_err_enable() API, an attacker who controls the serial peer can deterministically assert these error bits by injecting line errors on the RX line — a baud/stop-bit mismatch or mid-character break (framing/break error), a flipped parity bit (parity error), or FIFO flooding (overrun error). Because the error interrupt is never cleared, the interrupt line stays asserted and the CPU re-enters pl011_isr() immediately and indefinitely, producing an interrupt-storm livelock from which the core makes no forward progress. The impact is an availability-only denial of service (permanent hang), reachable from an external or removable UART peer. Exploitation is gated by configuration: the error interrupt is off by default and no in-tree subsystem enables it, so only applications that explicitly call uart_irq_err_enable() on a PL011-based, interrupt-driven port are affected. The fix makes pl011_isr() acknowledge the pending error bits via uart->icr, breaking the loop, and additionally clears the latched RSR status in pl011_err_check(). | ||||
| CVE-2026-12522 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 8.8 High |
| The HL7800 cellular modem driver's +CGCONTRDP: response handler on_cmd_atcmdinfo_ipaddr() in drivers/modem/vendor_standalone/hl7800.c parses the PDP-context dynamic parameters (local address, subnet mask, gateway, and DNS servers) that the cellular network assigns to the device. The response is linearized into a 256-byte stack buffer, after which each address field length is computed from comma/. delimiter positions in the network-supplied data and used directly as the length argument to strncpy() into the fixed 64-byte stack buffer temp_addr_str (and the 16-byte iface_ctx.dns_v4_string). Because the field length is derived from attacker-controlled delimiter positions and was not bounded against the destination buffer, a single field can be far larger than 64 bytes. A malicious or impersonated cellular network (for example a rogue base station) can return a crafted +CGCONTRDP response with an overlong address field, causing strncpy() to write past temp_addr_str on the modem worker thread's stack, plus an out-of-bounds NUL write at temp_addr_str[addr_len]. No device-side privileges or user interaction are required: the device itself issues the AT+CGCONTRDP=1 query during normal network attach and parses whatever the network returns. The overflow corrupts adjacent stack memory in supervisor context, yielding at minimum a remotely triggerable crash and potentially control-flow hijacking on targets without stack protection. The fix bounds every field length against its destination buffer (temp_addr_str and dns_v4_string) before each copy, rejecting overlong fields. | ||||
| CVE-2026-121803 | 2026-11-04 | N/A | ||
| This CVE ID is a duplicate of CVE-2026-80335 (VULN-002 dl_download_midst) and has been rejected. | ||||
| CVE-2026-113085 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| Information leak in Media in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-113046 | 1 Google | 1 Chrome | 2026-11-04 | 8.8 High |
| UI misrepresentation in Passwords in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-101438 | 1 Oracle | 2 Siebel Crm, Siebel Crm Cloud Applications | 2026-11-04 | 8 High |
| Vulnerability in the Siebel CRM Cloud Applications product of Oracle Siebel CRM (component: Siebel Cloud Manager). Supported versions that are affected are 22.3-26.9. Difficult to exploit vulnerability allows unauthenticated attacker with access to the physical communication segment attached to the hardware where the Siebel CRM Cloud Applications executes to compromise Siebel CRM Cloud Applications. While the vulnerability is in Siebel CRM Cloud Applications, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Siebel CRM Cloud Applications accessible data as well as unauthorized access to critical data or complete access to all Siebel CRM Cloud Applications accessible data. CVSS 3.1 Base Score 8.0 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N). | ||||
| CVE-2026-101442 | 1 Oracle | 2 Siebel Crm, Siebel Crm Cloud Applications | 2026-11-04 | 3.1 Low |
| Vulnerability in the Siebel CRM Cloud Applications product of Oracle Siebel CRM (component: Siebel Cloud Manager). Supported versions that are affected are 22.3-26.9. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Siebel CRM Cloud Applications. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Siebel CRM Cloud Applications accessible data. CVSS 3.1 Base Score 3.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N). | ||||
| CVE-2026-112428 | 1 Apple | 1 Macos | 2026-11-04 | 5.5 Medium |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may bypass Gatekeeper checks. | ||||
| CVE-2026-112690 | 1 Apple | 5 Ios And Ipados, Ipados, Iphone Os and 2 more | 2026-11-04 | 9.8 Critical |
| This issue was addressed with improved input validation. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, visionOS 27.2. A remote attacker may be able to break out of the WebContent sandbox. | ||||
| CVE-2026-121415 | 2 Parse Community, Parseplatform | 2 Parse Server, Parse-server | 2026-11-04 | 3.7 Low |
| Parse Server before 8.6.111 and 9.0.0 before 9.10.6-alpha.3 on MongoDB skips field type validation for null-valued dot notation keys, allowing sub-documents to be written beneath Pointer, Number, String, Date, or Boolean fields. Any client with write access, including unauthenticated clients where public writes are permitted, can corrupt field values, make objects unreadable via internal date fields, or break atomic operations on number fields. | ||||
| CVE-2026-121438 | 2 Lepture, Mistune Project | 2 Mistune, Mistune | 2026-11-04 | 5.3 Medium |
| Mistune before 3.3.3 contains a denial of service vulnerability in InlineParser.parse_link that allows attackers to cause quadratic CPU growth by supplying balanced nested brackets. Attackers can submit crafted Markdown with thousands of nested bracket pairs not forming a valid link, triggering repeated _contains_nested_link scans that exhaust CPU in parsing applications. | ||||
| CVE-2026-119521 | 2 Cozmoslabs, Wordpress-extensions | 2 Paid Member Subscriptions, Paid Member Subscriptions | 2026-11-04 | 6.5 Medium |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Cozmoslabs Paid Member Subscriptions paid-member-subscriptions allows Stored XSS.This issue affects Paid Member Subscriptions: from n/a through 3.1.3. | ||||
| CVE-2026-79976 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 7.1 High |
| The MCTP-over-I2C+GPIO target binding in subsys/pmci/mctp/mctp_i2c_gpio_target.c emulates a small pseudo-register file, where the bus controller first writes a register number and then writes or reads payload bytes. The selected register (b->reg_addr) and the data-phase flag (b->rxtx) were never cleared when the controller issued an I2C STOP, so after a completed transfer the target still had a data register selected while the packet buffer that register refers to had already been consumed and set to NULL by mctp_i2c_gpio_target_stop(). A controller on the bus can re-enter the same branch of mctp_i2c_gpio_target_stop() with a NULL buffer using two ordinary transactions and no authentication: first a normal packet write to MCTP_I2C_GPIO_RX_MSG_ADDR followed by STOP (which delivers and frees b->rx_pkt), then a bare read transaction followed by STOP. The failing read_requested() call leaves the stale state untouched and the I2C driver still delivers the STOP callback, which then calls mctp_bus_rx() with a NULL packet. The symmetric case exists on the transmit side, where the stale MCTP_I2C_GPIO_TX_MSG_ADDR selection dereferences b->tx_pkt->end after b->tx_pkt has been cleared and additionally signals b->tx_complete a second time, causing the next outbound packet to be dropped. The dereference happens in the I2C target interrupt handler, so on any target that traps accesses to address 0 the result is a fatal exception and a device reset or halt — a denial of service inflicted by any device able to act as controller on the shared management bus (for example compromised firmware on a peer MCTP endpoint or on the BMC). On parts where address 0 is readable, the impact degrades to a malformed packet buffer being handed to the MCTP stack and lost transmit packets. No attacker-controlled value is written and no confidentiality or integrity boundary is crossed. The fix resets b->reg_addr to MCTP_I2C_GPIO_INVALID_ADDR and clears b->rxtx at every STOP, so a new register must be selected before any data phase can run again. Only builds that opt into the experimental CONFIG_MCTP subsystem with CONFIG_MCTP_I2C_GPIO_TARGET=y are affected. | ||||
| CVE-2026-77684 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 5.7 Medium |
| The Bluetooth Classic Hands-Free Profile HF role in subsys/bluetooth/host/classic/hfp_hf.c does not release the AT command buffers that are still queued on hf->tx_pending when the RFCOMM DLC goes down. hfp_hf_disconnected() only cancelled the work items and cleared hf->acl, and no other code path ever dequeues those buffers, so each one is permanently lost from the fixed hf_pool (CONFIG_BT_MAX_CONN + 1 buffers, i.e. two in the default configuration). The same function also left BT_HFP_HF_FLAG_CONNECTED set, and hfp_hf_create() wiped the object with memset() as soon as hf->acl was NULL, without checking whether hf->work, hf->slc_work or hf->deferred_work was still pending or running. The remote Audio Gateway peer controls the trigger end to end and needs no application involvement: an unsolicited +BCS: 1 response makes bcs_handle() call bt_hfp_hf_select_codec() and queue an AT+BCS buffer, which cannot be transmitted while BT_HFP_HF_FLAG_RX_ONGOING is set, and an immediately following RFCOMM DISC strands that buffer. Repeating the connect / +BCS / disconnect cycle a couple of times empties hf_pool for good. With the pool exhausted, HFP command sending fails permanently, and because hfp_hf_send_cmd() allocates with K_FOREVER (bt_rfcomm_create_pdu() → bt_conn_create_pdu()) from the Bluetooth RX context — where that timeout is not downgraded to K_NO_WAIT — one further +BCS from the peer parks the Bluetooth RX thread inside net_buf_alloc() with no possible waker, halting all HCI event processing until the device is rebooted. Separately, reusing the HF slot while a work handler was still queued or running allowed memset() to wipe live k_work items out from under the system workqueue, corrupting shared kernel workqueue state. Exploitation requires an established HFP session (for SSP devices L2CAP enforces authentication before the RFCOMM channel is reachable) and a build with CONFIG_BT_HFP_HF enabled. | ||||
| CVE-2026-101445 | 1 Oracle | 2 Siebel Crm, Siebel Crm Cloud Applications | 2026-11-04 | 3.6 Low |
| Vulnerability in the Siebel CRM Cloud Applications product of Oracle Siebel CRM (component: Siebel Cloud Manager). Supported versions that are affected are 22.3-26.9. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Siebel CRM Cloud Applications executes to compromise Siebel CRM Cloud Applications. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Siebel CRM Cloud Applications accessible data as well as unauthorized read access to a subset of Siebel CRM Cloud Applications accessible data. CVSS 3.1 Base Score 3.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N). | ||||
| CVE-2026-112459 | 1 Apple | 6 Ios And Ipados, Ipados, Iphone Os and 3 more | 2026-11-04 | 7.5 High |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, tvOS 27.2, watchOS 27.2. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2026-112550 | 1 Apple | 1 Macos | 2026-11-04 | 5.5 Medium |
| A type confusion issue was addressed with improved memory handling. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to cause a denial-of-service. | ||||
| CVE-2026-112557 | 1 Apple | 1 Macos | 2026-11-04 | 5.5 Medium |
| The issue was addressed with improved checks. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. A malicious application may be able to bypass Privacy preferences. | ||||
| CVE-2026-107040 | 2026-11-04 | 9.1 Critical | ||
| Insecure permissions in MBasov OMN-Go versionCode 26080824 allows unauthorized attackers to invoke an exported component, leading to arbitrary data access and control of data flow. | ||||
| CVE-2026-10686 | 1 Zephyrproject | 1 Zephyr | 2026-11-04 | 5.8 Medium |
| Zephyr's IPv6 forwarding path re-sent routed unicast packets without ever decrementing the IPv6 hop limit. Both routing branches of ipv6_route_packet() (subsys/net/ip) were affected: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). Each set the packet forwarding flag and called net_send_data() with the hop limit untouched and no expiry check. Per RFC 8200 the hop-limit decrement is the mechanism that bounds packet lifetime and terminates routing loops; without it, a device acting as an IPv6 router relays looping packets indefinitely. An on-path attacker who can induce or exploit a transient L3 loop turns it into a permanent forwarding storm, causing CPU/bandwidth resource exhaustion (availability DoS) on the forwarder and adjacent links; path-discovery and loop diagnostics that rely on hop-limit expiry are also defeated. Affected configurations. In every affected release the forwarding path is reached via CONFIG_NET_ROUTE (enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set), together with CONFIG_NET_ROUTING for cross-interface routing. Note that CONFIG_NET_IPV6_FORWARDING and CONFIG_NET_IPV4_FORWARDING — which appear in the fix and in this advisory's evidence notes — were introduced after v4.4.0, when the routing options were split and renamed; they do not exist in any affected release. When auditing a v4.4.1-or-earlier configuration, look for CONFIG_NET_ROUTE and CONFIG_NET_ROUTING. IPv4 is not affected in any release. The IPv4 forwarding path (net_route_ipv4_packet() in route_ipv4.c) was added after v4.4.0 and has never shipped in a release. Its TTL decrement and IPv4 header-checksum recomputation landed on main as part of the same fix, so the evidence notes below discuss it, but no released version is reachable by way of IPv4. Affected releases are v1.8.0 through v4.4.1: v1.8.0 introduced net_route_packet() and v2.2.0 added net_route_packet_if(), and neither decremented the hop limit. v4.3.1 carries the explicit-route fix but not the on-link one, so it is affected as well. Fixed on main by 7d8f1afa7345 (explicit-route path) and 589eadc74efa (on-link path). | ||||