Export limit exceeded: 20909 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (402914 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-103627 | 1 Google | 1 Chrome | 2026-10-07 | 6.5 Medium |
| Information leak in SVG in Google Chrome prior to 154.0.8037.97 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-98290 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts. | ||||
| CVE-2026-98330 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: get the wiphy out of a dying network namespace When a network namespace is destroyed, cfg80211_pernet_exit() moves any wiphy back to the initial namespace, and just warns if that fails. But moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a garbage netns pointer: Kernel mode fault at addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] Note that commit debac3a20dec ("net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().") fixed another path that could reach it without allocation failures. Remove interfaces that cannot be moved instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the netdev core will unregister the interfaces anyway. | ||||
| CVE-2026-73570 | 2 Synacor, Zimbra | 2 Zimbra Collaboration Suite, Collaboration | 2026-10-07 | 8.9 High |
| A remote code execution vulnerability exists in Zimbra Collaboration (ZCS) before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Due to improper sanitization of untrusted input during SNMP notification processing, an unauthenticated attacker can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user. | ||||
| CVE-2026-98171 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: - Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. - Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. - Reject next_cmd values smaller than MID_HEADER_SIZE(server). - Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header. | ||||
| CVE-2025-32151 | 2 Themekraft, Wordpress | 2 Buddyforms, Wordpress | 2026-10-07 | 7.5 High |
| Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in Themekraft BuddyForms buddyforms allows PHP Local File Inclusion.This issue affects BuddyForms: from n/a through 2.10.2. | ||||
| CVE-2026-88416 | 1 Mcms | 1 Mcms | 2026-10-07 | 9.8 Critical |
| MCMS 6.1.1 through 6.2.1 has a SQL injection vulnerability in the custom model/form import feature. | ||||
| CVE-2026-88385 | 1 Michaelrsweet | 1 Mxml | 2026-10-07 | 6.5 Medium |
| Mini-XML 4.0.5 contains a memory leak vulnerability in mxml_load_data() during malformed XML parsing. Specially crafted XML input can cause text nodes allocated by mxmlNewText() to become unlinked before a parse error transfers control to the cleanup path. These orphaned nodes are not released, resulting in a persistent memory leak on each parsing attempt. Repeated attacker-controlled requests can cause cumulative memory exhaustion and denial of service. | ||||
| CVE-2026-98087 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU. The other 37 ms went to the stopper thread. The scheduler kept trying to push taskA, the pinned head of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran. Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock, then checks again with "task != pick_next_pushable_task(rq)". The task being pushed is taskB, but the pick returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the running task from that list, so taskB can never be the head. The check expects a candidate taken from the pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every time. .--> push-IPI arrives | | | v | pushable head = taskA -> pinned, cannot be pushed | | | v | so push taskB instead -> wake migration/N, a stop-class | | thread, so it preempts taskB | v | re-check compares taskB against the pushable head, | which is still taskA -> give up | | | v | nothing moved, taskA still queued, rq still overloaded | | '----------' repeats every ~17 us, 5204 times, for 89 ms The loop cannot stop itself. Every round leaves the runqueue exactly as it was, so the next push-IPI does the same thing. In the capture it ended only when taskB went to sleep on its own. taskA was then picked locally and left the pushable list. CPU time per task in the window, from sched_switch: taskB 51.95 ms real work migration/N 37.18 ms nothing moved taskA 0.00 ms queued the whole time, never picked idle 0.01 ms Counts over the same window: 7667 push-IPIs handled on this CPU 17481 pick_next_pushable_task() returned taskA, still pinned 5204 find_lock_lowest_rq() gave up on the re-check 1 push that actually completed 0 migrations of taskA The CPU times and the window length come from the standard sched_switch tracepoint. The counts needed tracepoints added inside the RT balancer for this investigation. The self-IPI path is closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded, because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinn ---truncated--- | ||||
| CVE-2026-51873 | 1 Stitionai | 1 Devika | 2026-10-07 | 8.8 High |
| Devika v1.0 is vulnerable to Directory Traversal in the Coder.save_code_to_project function, which allows attackers to write files outside the intended project workspace. | ||||
| CVE-2026-95165 | 2026-10-07 | 6.1 Medium | ||
| Bacularis 5.4.0 - 6.5.1 is vulnerable to Cross Site Scripting (XSS) in the Organization name field. | ||||
| CVE-2026-95166 | 2026-10-07 | 5.4 Medium | ||
| In Bacularis v1.0.0 - 6.5.1 when adding a new pool, the LabelFormat field allows for a Cross Site Scripting (XSS) payload. | ||||
| CVE-2026-95263 | 2026-10-07 | 7.2 High | ||
| Feehi CMS 2.1.1 is vulnerable to Incorrect Access Control. A low-privilege backend administrator with administrator-update permission can change the password of the built-in super administrator account. The server does not enforce protection for this account, and the update scenario does not require the old password. | ||||
| CVE-2026-95265 | 1 Liufee | 1 Feehicms | 2026-10-07 | 7.5 High |
| Feehi CMS 2.1.1 contains a Server-Side Request Forgery (SSRF) vulnerability in the UEditor catchimage endpoint. The private-IP validation does not block loopback or link-local addresses, allowing an attacker to make the server probe internal HTTP services through response differences. | ||||
| CVE-2026-106016 | 1 Mozilla | 1 Firefox | 2026-10-07 | N/A |
| Mitigation bypass in the File Handling component. This vulnerability was fixed in Firefox 157.0.1. | ||||
| CVE-2026-87890 | 1 Djangoproject | 1 Django | 2026-10-07 | 5.3 Medium |
| An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18. An incomplete fix for CVE-2026-15307 in Django spatial lookups allows an attacker who can supply `bytes` values to cause the Django process to make network requests via a crafted VRT document referencing an external raster source. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank sicksec for reporting this issue. | ||||
| CVE-2026-100817 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-10-07 | 5.4 Medium |
| Other issue in the JavaScript: WebAssembly component. This vulnerability was fixed in Thunderbird 157 and Firefox 157. | ||||
| CVE-2026-51888 | 1 Langflow | 1 Langflow | 2026-10-07 | 7.5 High |
| langflow-ai langflow v1.8.4 is affected by: Directory Traversal. The impact is: Arbitrary file write outside the intended workspace or storage boundary.. The component is: src/backend/base/langflow/api/v1/knowledge_bases.py:knowledge_bases-create_knowledge_base-a-live-http-post-to-create-knowledge-base. The attack vector is: Attack surface: HTTP or browser-backed service path. A public-facing upload or HTTP route handler forwards an attacker-controlled path or filename into host file creation without any visible boundary enforcement. ¶¶ A weakness has been identified in langflow-ai langflow up to 1.8.4. langflow contains an absolute path traversal vulnerability in knowledge_bases-create_knowledge_base-a-live-http-post-to-create-knowledge-base (src/backend/base/langflow/api/v1/knowledge_bases.py:51). An attacker can write or overwrite files outside the intended working directory by providing absolute paths in the knowledge base creation endpoint. | ||||
| CVE-2026-103630 | 1 Google | 1 Chrome | 2026-10-07 | 9.6 Critical |
| Use after free in FedCM in Google Chrome prior to 154.0.8037.97 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-103631 | 1 Google | 1 Chrome | 2026-10-07 | 8.8 High |
| Buffer overflow in WebRTC in Google Chrome prior to 154.0.8037.97 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||