Search

Search Results (329509 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-24532 2026-01-23 N/A
Missing Authorization vulnerability in SiteLock SiteLock Security sitelock allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects SiteLock Security: from n/a through <= 5.0.2.
CVE-2026-24531 2026-01-23 N/A
Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in Select-Themes Prowess prowess allows PHP Local File Inclusion.This issue affects Prowess: from n/a through <= 2.3.
CVE-2026-24530 2026-01-23 N/A
Missing Authorization vulnerability in sheepfish WebP Conversion webp-conversion allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WebP Conversion: from n/a through <= 2.1.
CVE-2026-24529 2026-01-23 N/A
Missing Authorization vulnerability in Alejandro Quick Restaurant Reservations quick-restaurant-reservations allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Quick Restaurant Reservations: from n/a through <= 1.6.7.
CVE-2026-24528 2026-01-23 N/A
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in pixelgrade Nova Blocks nova-blocks allows DOM-Based XSS.This issue affects Nova Blocks: from n/a through <= 2.1.9.
CVE-2026-24526 2026-01-23 N/A
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Steve Truman Email Inquiry &amp; Cart Options for WooCommerce woocommerce-email-inquiry-cart-options allows DOM-Based XSS.This issue affects Email Inquiry &amp; Cart Options for WooCommerce: from n/a through <= 3.4.3.
CVE-2026-24525 2026-01-23 N/A
Missing Authorization vulnerability in CloudPanel CLP Varnish Cache clp-varnish-cache allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CLP Varnish Cache: from n/a through <= 1.0.2.
CVE-2026-24524 2026-01-23 N/A
Missing Authorization vulnerability in Essekia Tablesome tablesome allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Tablesome: from n/a through <= 1.1.35.2.
CVE-2026-24523 2026-01-23 N/A
Exposure of Sensitive System Information to an Unauthorized Control Sphere vulnerability in Marcus (aka @msykes) WP FullCalendar wp-fullcalendar allows Retrieve Embedded Sensitive Data.This issue affects WP FullCalendar: from n/a through <= 1.6.
CVE-2026-24522 2026-01-23 N/A
Missing Authorization vulnerability in MyThemeShop WP Subscribe wp-subscribe allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Subscribe: from n/a through <= 1.2.16.
CVE-2026-24521 2026-01-23 N/A
Cross-Site Request Forgery (CSRF) vulnerability in Timur Kamaev Kama Thumbnail kama-thumbnail allows Cross Site Request Forgery.This issue affects Kama Thumbnail: from n/a through <= 3.5.1.
CVE-2026-21883 2026-01-23 5.4 Medium
Bokeh is an interactive visualization library written in Python. In versions 3.8.1 and below, if a server is configured with an allowlist (e.g., dashboard.corp), an attacker can register a domain like dashboard.corp.attacker.com (or use a subdomain if applicable) and lure a victim to visit it. The malicious site can then initiate a WebSocket connection to the vulnerable Bokeh server. Since the Origin header (e.g., http://dashboard.corp.attacker.com/) matches the allowlist according to the flawed logic, the connection is accepted. Once connected, the attacker can interact with the Bokeh server on behalf of the victim, potentially accessing sensitive data, or modifying visualizations. This issue is fixed in version 3.8.2.
CVE-2026-20613 1 Apple 2 Container, Containerization 2026-01-23 7.8 High
The ArchiveReader.extractContents() function used by cctl image load and container image load performs no pathname validation before extracting an archive member. This means that a carelessly or maliciously constructed archive can extract a file into any user-writable location on the system using relative pathnames. This issue is addressed in container 0.8.0 and containerization 0.21.0.
CVE-2025-71157 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: always drop device refcount in ib_del_sub_device_and_put() Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add support to add/delete a sub IB device through netlink") grabs a reference using ib_device_get_by_index() before calling ib_del_sub_device_and_put(), we need to drop that reference before returning -EOPNOTSUPP error.
CVE-2025-71156 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: gve: defer interrupt enabling until NAPI registration Currently, interrupts are automatically enabled immediately upon request. This allows interrupt to fire before the associated NAPI context is fully initialized and cause failures like below: [ 0.946369] Call Trace: [ 0.946369] <IRQ> [ 0.946369] __napi_poll+0x2a/0x1e0 [ 0.946369] net_rx_action+0x2f9/0x3f0 [ 0.946369] handle_softirqs+0xd6/0x2c0 [ 0.946369] ? handle_edge_irq+0xc1/0x1b0 [ 0.946369] __irq_exit_rcu+0xc3/0xe0 [ 0.946369] common_interrupt+0x81/0xa0 [ 0.946369] </IRQ> [ 0.946369] <TASK> [ 0.946369] asm_common_interrupt+0x22/0x40 [ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10 Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto enablement and explicitly enable the interrupt in NAPI initialization path (and disable it during NAPI teardown). This ensures that interrupt lifecycle is strictly coupled with readiness of NAPI context.
CVE-2025-71155 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.
CVE-2025-71154 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: fix memory leak on usb_submit_urb() failure In async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak. The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked. Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.
CVE-2025-71153 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix memory leak in get_file_all_info() In get_file_all_info(), if vfs_getattr() fails, the function returns immediately without freeing the allocated filename, leading to a memory leak. Fix this by freeing the filename before returning in this error case.
CVE-2025-71152 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---
CVE-2025-71151 1 Linux 1 Linux Kernel 2026-01-23 N/A
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory and information leak in smb3_reconfigure() In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak. Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.