Export limit exceeded: 405193 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 405193 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 405193 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (405193 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-17484 | 1 Ibm | 1 I | 2026-10-12 | 5.3 Medium |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a local attacker to cause a denial of service due to improper access control. | ||||
| CVE-2026-17487 | 1 Ibm | 1 I | 2026-10-12 | 5.3 Medium |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a remote attacker to enumerate user profiles due to the return of distinct error codes during the sign-on process. | ||||
| CVE-2026-18318 | 1 Ibm | 1 I | 2026-10-12 | 5.3 Medium |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a remote attacker to perform brute-force attacks to obtain credentials due to improper authentication. | ||||
| CVE-2026-18343 | 1 Ibm | 1 I | 2026-10-12 | 4.4 Medium |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a local attacker to modify the BOOTP table due to improper authorization. | ||||
| CVE-2026-81858 | 1 Ibm | 1 I | 2026-10-12 | 5.4 Medium |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a remote authenticated attacker to cause a denial of service and obtain information due to an out-of-bounds read in the File Server. | ||||
| CVE-2026-93886 | 1 Ibm | 1 I | 2026-10-12 | 8.3 High |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a remote authenticated attacker to execute arbitrary script code due to improper validation of user-supplied input. | ||||
| CVE-2026-96119 | 1 Ibm | 1 I | 2026-10-12 | 9.9 Critical |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a remote authenticated attacker to obtain sensitive information or execute arbitrary code on the system due to improper data sanitization by the HTTP Server Administration web application. | ||||
| CVE-2026-19938 | 2026-10-12 | 5.9 Medium | ||
| The Bluetooth host's ATT transmit path releases a buffer it does not own when signing fails. chan_send() in subsys/bluetooth/host/att.c documents (and every other error exit implements) the contract that on failure the caller retains ownership of the net_buf; the BT_ATT_OP_SIGNED_WRITE_CMD branch instead called net_buf_unref(buf) when bt_smp_sign() returned an error and then returned that error to the caller. The callers act on the contract: process_queue() re-queues the buffer with k_queue_prepend(), bt_att_chan_send_rsp() puts it back on chan->tx_queue, bt_att_chan_req_send() restores it into the request, and att_req_retry() unreferences it — so the already-freed buffer was re-queued, later dereferenced, and eventually freed again. An ATT Signed Write Command is produced when an application calls bt_gatt_write_without_response_cb() with sign set on an unencrypted connection. bt_smp_sign() fails whenever no local CSRK exists for the peer (-ENOENT), and whether one exists is negotiated with the peer: smp_distribute_keys() stores a local CSRK only when the peer's pairing key-distribution field requests the signing key and bonding was agreed. A peer can therefore pair without accepting the CSRK, pair with No Bonding, remain unpaired, or keep the link unencrypted, and the victim's next signed write takes the failing path. Because struct net_buf's node field is simultaneously the linkage word for the ATT TX FIFO, for the deferred-destroy list used by the att_pool destroy callback att_tx_destroy(), and for the pool free list, the mishandled buffer corrupts these lists and can be re-issued by bt_att_create_pdu() to a new PDU while the ATT TX path still holds it. The same branch also saved the net_buf_simple_state only after signing, so a buffer restored after a bt_l2cap_send_pdu() failure kept its 12-octet signature; a subsequent retry re-signed it and appended a second signature with net_buf_add(buf, 12) to a buffer that bt_att_create_pdu() sized for exactly one, writing past the end of the pooled buffer in builds where the net_buf tailroom assertion is compiled out. Impact is host-side memory corruption in the Bluetooth stack: list corruption, a pooled ATT buffer with two owners (wrong PDU contents transmitted, or a double free when the queues are drained at disconnect), and a bounded out-of-bounds write on the retry path — typically observed as a crash or assertion failure. Exposure requires the deprecated CONFIG_BT_SIGNING to be enabled and an application that actually issues signed writes; in that configuration the triggering condition is under the remote peer's control. | ||||
| CVE-2026-19937 | 2026-10-12 | 5.7 Medium | ||
| The Bluetooth Mesh Access layer delayable-message machinery in subsys/bluetooth/mesh/delayable_msg.c manages a static pool of CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT message contexts (default 4) threaded onto a free_ctx or busy_ctx list. release_delayable_msg_ctx() returned a context to free_ctx only when sys_slist_find_and_remove() found it on busy_ctx. The chunk-exhaustion error path in bt_mesh_delayable_msg_manage() releases a context that was already popped off free_ctx but not yet inserted on busy_ctx, so the context was appended to neither list and was permanently lost from the pool. Because bt_mesh_delayable_msg_init() runs only once from bt_mesh_init(), and node reset/suspend only drain busy_ctx, the loss survives unprovision, re-provision and suspend/resume — it is cleared only by a reboot. The error path is reached when the chunk pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40 chunks) is short of the chunks a new delayed message needs and the oldest pending message cannot be flushed because bt_mesh_access_send() returns -EBUSY or -ENOBUFS (all segmented-TX contexts busy, or advertising/segment buffers exhausted). A peer that is provisioned into the mesh network — holding a valid NetKey plus an AppKey or DevKey bound to a server model — can drive both conditions by flooding the victim with requests that elicit segmented responses while withholding the Segment Acknowledgment, which keeps the transmit contexts occupied while queued responses hold the chunk pool. Each further request that arrives in that window leaks one context. Once the pool is drained, bt_mesh_delayable_msg_manage() returns -ENOMEM for every subsequent send and bt_mesh_model_send() propagates that error with no fallback to an immediate transmit. Since CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED are both enabled by default, ctx->rnd_delay is set for every received access message, so all replies from Configuration Server, Health Server and application server models are silently dropped. The node keeps receiving and processing traffic but never answers, a persistent denial of service until the device is restarted. There is no memory corruption, information disclosure or integrity impact; releases before the fix compute the chunk count from the transmit buffer capacity rather than its payload length, making chunk-pool starvation — and therefore the leak — considerably easier to provoke. | ||||
| CVE-2026-19936 | 2026-10-12 | 4.8 Medium | ||
| The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) and one k_work_delayable between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() runs on the Bluetooth host RX thread, while delayable_msg_handler() runs on the system workqueue. Both block while the lists are in an intermediate state — the enqueuer in bt_rand(), both in bt_mesh_access_send() — which lets the other context observe torn state. delayable_msg_handler() used the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() and then assumed a separate sys_slist_get() would succeed. Because CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED default to y, every model response to a received mesh message is parked on this queue, so the enqueuer runs as a direct consequence of inbound traffic. A peer that can get access-layer messages accepted by a model (it must hold the NetKey and a bound AppKey, so a legitimate or compromised network member) controls the arrival rate, the size of the elicited responses and the destination address, and thereby controls occupancy of the 4-entry context pool and the 40-entry chunk pool. Exhausting the chunk pool forces bt_mesh_delayable_msg_manage() down the purge path, which sends and releases the only queued message and leaves busy_ctx empty while the delayable work item is still armed; if the enqueuer then yields, the handler runs against the empty list. The result is a read-modify-write through a NULL-based pointer (pending_msg->fired_time += 10) at a fixed low address on the system workqueue thread. On typical targets that faults, aborting the system workqueue thread — which stops all workqueue-driven functionality, including the mesh timing machinery — or resetting the node, so the impact is loss of availability of the affected node. The write value and address are fixed and no attacker-controlled length or index is involved, so this is not exploitable for memory corruption or code execution. The same unsynchronized window also allowed one message context to be selected and released by two contexts at once, producing duplicated transmissions, duplicated send-completion callbacks and crossed chunk ownership. The fix serializes every list mutation with a k_spinlock that is never held across a blocking call, makes push_msg_from_delayable_msgs() detach the queue head atomically so a message being sent is on no list, removes the unchecked sys_slist_get() from delayable_msg_handler(), and drops any message that reaches the front of the queue while the stack is suspended or reset. | ||||
| CVE-2026-96261 | 1 Ibm | 1 Powervm Hypervisor | 2026-10-12 | 7.3 High |
| IBM Power Systems Firmware FW1060.00 through FW1060.81 is affected by a vulnerability in host firmware configuration parsing. An attacker with authenticated service-level access to the service processor can write specially crafted configuration data, causing the host firmware boot stack to crash with possible memory corruption during system initialisation, resulting in an integrity and availability impact to the managed system. | ||||
| CVE-2026-86405 | 1 Sipay Electronic Money And Payment Services | 1 Prestashop Virtual Pos Module | 2026-10-12 | 9.8 Critical |
| Improper verification of cryptographic signature vulnerability in Sipay Electronic Money and Payment Services Inc. PrestaShop Virtual POS Module allows Signature Spoofing by Improper Validation. This issue affects PrestaShop Virtual POS Module: from 26.8.1 before 26.9.1. | ||||
| CVE-2026-85531 | 1 Sipay Electronic Money And Payment Services | 1 Opencart Virtual Pos Module | 2026-10-12 | 9.8 Critical |
| Improper verification of cryptographic signature vulnerability in Sipay Electronic Money and Payment Services Inc. OpenCart Virtual POS Module allows Signature Spoofing by Improper Validation. This issue affects OpenCart Virtual POS Module: from 26.8.2 before 26.9.1. | ||||
| CVE-2026-84418 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-12 | 7.4 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 can allow a man-in-the-middle attacker to present a forged TLS certificate, intercept the connection, and capture the IAM bearer Authorization header automatically attached by the session adapter. The captured token grants full platform-scope tenant API access, enabling the attacker to read and manipulate the victim's DataStage projects, flows, assets, and pipeline definitions. This is client-side SDK code running on the user's own machine, so exploitation requires an external network interceptor rather than a co-tenant in the shared cluster. | ||||
| CVE-2026-84290 | 1 Ibm | 1 Guardium Data Protection | 2026-10-12 | 5.1 Medium |
| IBM Guardium Data Protection 12.0, 12.1, 12.2 is affected by an improper validation of user-supplied pointers in the WfpMonitor kernel driver. Certain METHOD_NEITHER IOCTL handlers dereference user-controlled pointers without adequate probing and exception handling, potentially allowing a privileged local attacker to cause a system crash or perform limited kernel-memory reads. | ||||
| CVE-2026-84276 | 1 Ibm | 1 Guardium Data Protection | 2026-10-12 | 7.5 High |
| IBM Guardium Data Protection 12.2.2 is affected by a denial-of-service vulnerability in the edge-controller. An unauthenticated remote attacker with network access to the edge-controller gRPC service can provide malformed task data that triggers an unchecked type assertion, causing the edge-controller process to terminate unexpectedly. | ||||
| CVE-2026-84275 | 1 Ibm | 1 Guardium Data Protection | 2026-10-12 | 7.5 High |
| IBM Guardium Data Protection 12.2 is vulnerable to path traversal in the GIM file-upload functionality. An unauthenticated attacker could exploit this vulnerability to write arbitrary files to the Collector. | ||||
| CVE-2026-82110 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-12 | 9.6 Critical |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of pathname during a path traversal. | ||||
| CVE-2026-82108 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-12 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-82101 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-10-12 | 9.6 Critical |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to cause a denial of service due to a path traversal vulnerability. | ||||