Export limit exceeded: 47051 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (47051 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2006-3384 | 1 Vincent Leclercq | 1 News | 2026-04-16 | N/A |
| SQL injection vulnerability in divers.php in Vincent Leclercq News 5.2 allows remote attackers to execute arbitrary SQL commands via the (1) id and (2) texte parameters. | ||||
| CVE-2006-3364 | 1 F-art Agency | 1 Blog Cms | 2026-04-16 | N/A |
| SQL injection vulnerability in index.php in the NP_SEO plugin in BLOG:CMS before 4.1.0 allows remote attackers to execute arbitrary SQL commands via the id parameter. | ||||
| CVE-2006-4714 | 1 Spoonlabs | 1 Vivvo Article Management Cms | 2026-04-16 | N/A |
| PHP remote file inclusion vulnerability in index.php in SpoonLabs Vivvo Article Management CMS (aka phpWordPress) 3.2 and earlier, when register_globals is enabled, allows remote attackers to execute arbitrary PHP code via a URL in the classified_path parameter. | ||||
| CVE-2006-3368 | 1 Efone | 1 Efone | 2026-04-16 | N/A |
| Efone 20000723 stores config.inc under the web document root with insufficient access control, which allows remote attackers to obtain sensitive information. | ||||
| CVE-2006-4665 | 1 Mkportal | 1 Mkportal | 2026-04-16 | N/A |
| Cross-site scripting (XSS) vulnerability in index.php in MKPortal M1.1 Rc1 allows remote attackers to inject arbitrary web script or HTML via the ind parameter, possibly related to the PHP_SELF variable. NOTE: Some details are obtained from third party information. | ||||
| CVE-2006-4588 | 1 Vtiger | 1 Vtiger Crm | 2026-04-16 | N/A |
| vtiger CRM 4.2.4, and possibly earlier, allows remote attackers to bypass authentication and access administrative modules via a direct request to index.php with a modified module parameter, as demonstrated using the Settings module. | ||||
| CVE-2006-4589 | 1 Dyncms | 1 Dyncms | 2026-04-16 | N/A |
| PHP remote file inclusion vulnerability in 0_admin/modules/Wochenkarte/frontend/index.php in DynCMS 6 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the x_admindir parameter. | ||||
| CVE-2026-29111 | 2 Systemd, Systemd Project | 2 Systemd, Systemd | 2026-04-15 | 5.5 Medium |
| systemd, a system and service manager, (as PID 1) hits an assert and freezes execution when an unprivileged IPC API call is made with spurious data. On version v249 and older the effect is not an assert, but stack overwriting, with the attacker controlled content. From version v250 and newer this is not possible as the safety check causes an assert instead. This IPC call was added in v239, so versions older than that are not affected. Versions 260-rc1, 259.2, 258.5, and 257.11 contain patches. No known workarounds are available. | ||||
| CVE-2026-23013 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback octep_vf_request_irqs() requests MSI-X queue IRQs with dev_id set to ioq_vector. If request_irq() fails part-way, the rollback loop calls free_irq() with dev_id set to 'oct', which does not match the original dev_id and may leave the irqaction registered. This can keep IRQ handlers alive while ioq_vector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires. Fix the error path to free IRQs with the same ioq_vector dev_id used during request_irq(). | ||||
| CVE-2026-1615 | 1 Dchester | 1 Jsonpath | 2026-04-15 | 9.8 Critical |
| Versions of the package jsonpath before 1.3.0 are vulnerable to Arbitrary Code Injection via unsafe evaluation of user-supplied JSON Path expressions. The library relies on the static-eval module to process JSON Path input, which is not designed to handle untrusted data safely. An attacker can exploit this vulnerability by supplying a malicious JSON Path expression that, when evaluated, executes arbitrary JavaScript code, leading to Remote Code Execution in Node.js environments or Cross-site Scripting (XSS) in browser contexts. This affects all methods that evaluate JSON Paths against objects, including .query, .nodes, .paths, .value, .parent, and .apply. | ||||
| CVE-2022-39177 | 3 Bluez, Canonical, Debian | 3 Bluez, Ubuntu Linux, Debian Linux | 2026-04-15 | 8.8 High |
| BlueZ before 5.59 allows physically proximate attackers to cause a denial of service because malformed and invalid capabilities can be processed in profiles/audio/avdtp.c. | ||||
| CVE-2022-39176 | 3 Bluez, Canonical, Debian | 3 Bluez, Ubuntu Linux, Debian Linux | 2026-04-15 | 8.8 High |
| BlueZ before 5.59 allows physically proximate attackers to obtain sensitive information because profiles/audio/avrcp.c does not validate params_len. | ||||
| CVE-2016-8620 | 2 Haxx, Redhat | 2 Curl, Rhel Software Collections | 2026-04-15 | N/A |
| The 'globbing' feature in curl before version 7.51.0 has a flaw that leads to integer overflow and out-of-bounds read via user controlled input. | ||||
| CVE-2016-9594 | 1 Haxx | 1 Curl | 2026-04-15 | N/A |
| curl before version 7.52.1 is vulnerable to an uninitialized random in libcurl's internal function that returns a good 32bit random value. Having a weak or virtually non-existent random value makes the operations that use it vulnerable. | ||||
| CVE-2026-23136 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state. | ||||
| CVE-2026-23139 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: update last_gc only when GC has been performed Currently last_gc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely. Update the last_gc value only when a GC has been actually performed. | ||||
| CVE-2026-23172 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: fix potential skb->frags overflow in RX path When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior. This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet"). The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects. Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS. The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown. | ||||
| CVE-2026-23175 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: net: cpsw: Execute ndo_set_rx_mode callback in a work queue Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/481 RTNL: assertion failed at net/8021q/vlan_core.c (236) Modules linked in: CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x28/0x2c show_stack from dump_stack_lvl+0x30/0x38 dump_stack_lvl from __warn+0xb8/0x11c __warn from warn_slowpath_fmt+0x130/0x194 warn_slowpath_fmt from vlan_for_each+0x120/0x124 vlan_for_each from cpsw_add_mc_addr+0x54/0x98 cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88 __dev_mc_add from igmp6_group_added+0x84/0xec igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0 __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4 __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168 do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8 ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c do_sock_setsockopt from __sys_setsockopt+0x84/0xac __sys_setsockopt from ret_fast_syscall+0x0/0x54 This trace occurs because vlan_for_each() is called within cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held. Since modifying vlan_for_each() to operate without the RTNL lock is not straightforward, and because ndo_set_rx_mode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution. To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver. Please note: To reproduce this issue, I manually reverted the changes to am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone: switch to new cpsw switch drv") in order to revert to the legacy cpsw driver. | ||||
| CVE-2026-23180 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: add bounds check for if_id in IRQ handler The IRQ handler extracts if_id from the upper 16 bits of the hardware status register and uses it to index into ethsw->ports[] without validation. Since if_id can be any 16-bit value (0-65535) but the ports array is only allocated with sw_attr.num_ifs elements, this can lead to an out-of-bounds read potentially. Add a bounds check before accessing the array, consistent with the existing validation in dpaa2_switch_rx(). | ||||
| CVE-2026-25747 | 1 Apache | 1 Camel | 2026-04-15 | 8.8 High |
| Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component. The Camel-LevelDB DefaultLevelDBSerializer class deserializes data read from the LevelDB aggregation repository using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. An attacker who can write to the LevelDB database files used by a Camel application can inject a crafted serialized Java object that, when deserialized during normal aggregation repository operations, results in arbitrary code execution in the context of the application. This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.5, from 4.15.0 before 4.18.0. Users are recommended to upgrade to version 4.18.0, which fixes the issue. For the 4.10.x LTS releases, users are recommended to upgrade to 4.10.9, while for 4.14.x LTS releases, users are recommended to upgrade to 4.14.5 | ||||