Export limit exceeded: 361997 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (361997 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-24721 | 1 Innovaphone | 1 Innovaphone Pbx | 2025-09-18 | 6.5 Medium |
| An issue was discovered on Innovaphone PBX before 14r1 devices. The password form, used to authenticate, allows a Brute Force Attack through which an attacker may be able to access the administration panel | ||||
| CVE-2024-25247 | 1 Niushop | 1 B2b2c Multi-business | 2025-09-18 | 9.8 Critical |
| SQL Injection vulnerability in /app/api/controller/Store.php in Niushop B2B2C V5 allows attackers to run arbitrary SQL commands via latitude and longitude parameters. | ||||
| CVE-2025-58352 | 1 Weblate | 1 Weblate | 2025-09-18 | 6.5 Medium |
| Weblate is a web based localization tool. Versions lower than 5.13.1 contain a vulnerability that causes long session expiry during the second factor verification. The long session expiry could be used to circumvent rate limiting of the second factor. This issue is fixed in version 5.13.1. | ||||
| CVE-2024-1899 | 1 Showdownjs | 1 Showdown | 2025-09-18 | 5.3 Medium |
| An issue in the anchors subparser of Showdownjs versions <= 2.1.0 could allow a remote attacker to cause denial of service conditions. | ||||
| CVE-2024-27456 | 1 Rylabs | 1 Rack Cors Middleware | 2025-09-18 | 9.1 Critical |
| rack-cors (aka Rack CORS Middleware) 2.0.1 has 0666 permissions for the .rb files. | ||||
| CVE-2024-27454 | 1 Ijl | 1 Orjson | 2025-09-18 | 7.5 High |
| orjson.loads in orjson before 3.9.15 does not limit recursion for deeply nested JSON documents. | ||||
| CVE-2024-27350 | 1 Amazon | 1 Fire Os | 2025-09-18 | 5.9 Medium |
| Amazon Fire OS 7 before 7.6.6.9 and 8 before 8.1.0.3 allows Fire TV applications to establish local ADB (Android Debug Bridge) connections. NOTE: some third parties dispute whether this has security relevance, because an ADB connection is only possible after the (non-default) ADB Debugging option is enabled, and after the initiator of that specific connection attempt has been approved via a full-screen prompt. | ||||
| CVE-2024-24386 | 1 Vitalpbx | 1 Vitalpbx | 2025-09-18 | 7.2 High |
| An issue in VitalPBX v.3.2.4-5 allows an attacker to execute arbitrary code via a crafted payload to the /var/lib/vitalpbx/scripts folder. | ||||
| CVE-2024-24256 | 1 Yonyou | 1 Yonyou | 2025-09-18 | 5.9 Medium |
| SQL Injection vulnerability in Yonyou space-time enterprise information integration platform v.9.0 and before allows an attacker to obtain sensitive information via the gwbhAIM parameter in the saveMove.jsp in the hr_position directory. | ||||
| CVE-2024-27080 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race when detecting delalloc ranges during fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below. The race happens like this: 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole; 2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit; 3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf; 4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over; 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range. This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this: generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated--- | ||||
| CVE-2025-10060 | 1 Mongodb | 1 Mongodb | 2025-09-18 | 6.5 Medium |
| MongoDB Server may allow upsert operations retried within a transaction to violate unique index constraints, potentially causing an invariant failure and server crash during commit. This issue may be triggered by improper WriteUnitOfWork state management. This issue affects MongoDB Server v6.0 versions prior to 6.0.25, MongoDB Server v7.0 versions prior to 7.0.22 and MongoDB Server v8.0 versions prior to 8.0.12 | ||||
| CVE-2024-27391 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: do not realloc workqueue everytime an interface is added Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue. | ||||
| CVE-2024-27036 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: cifs: Fix writeback data corruption cifs writeback doesn't correctly handle the case where cifs_extend_writeback() hits a point where it is considering an additional folio, but this would overrun the wsize - at which point it drops out of the xarray scanning loop and calls xas_pause(). The problem is that xas_pause() advances the loop counter - thereby skipping that page. What needs to happen is for xas_reset() to be called any time we decide we don't want to process the page we're looking at, but rather send the request we are building and start a new one. Fix this by copying and adapting the netfslib writepages code as a temporary measure, with cifs writeback intending to be offloaded to netfslib in the near future. This also fixes the issue with the use of filemap_get_folios_tag() causing retry of a bunch of pages which the extender already dealt with. This can be tested by creating, say, a 64K file somewhere not on cifs (otherwise copy-offload may get underfoot), mounting a cifs share with a wsize of 64000, copying the file to it and then comparing the original file and the copy: dd if=/dev/urandom of=/tmp/64K bs=64k count=1 mount //192.168.6.1/test /mnt -o user=...,pass=...,wsize=64000 cp /tmp/64K /mnt/64K cmp /tmp/64K /mnt/64K Without the fix, the cmp fails at position 64000 (or shortly thereafter). | ||||
| CVE-2021-47532 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm/devfreq: Fix OPP refcnt leak | ||||
| CVE-2025-58446 | 1 Mlc-ai | 1 Xgrammar | 2025-09-18 | 7.5 High |
| xgrammar is an open-source library for efficient, flexible, and portable structured generation. A grammar optimizer introduced in 0.1.23 processes large grammars (>100k characters) at very low rates, and can be used for DOS of model providers. This issue is fixed in version 0.1.24. | ||||
| CVE-2021-47533 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Clear the HVS FIFO commit pointer once done Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state. Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure. | ||||
| CVE-2021-47538 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer() Need to call rxrpc_put_local() for peer candidate before kfree() as it holds a ref to rxrpc_local. [DH: v2: Changed to abstract the peer freeing code out into a function] | ||||
| CVE-2021-47539 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxrpc_peer leak in rxrpc_look_up_bundle() Need to call rxrpc_put_peer() for bundle candidate before kfree() as it holds a ref to rxrpc_peer. [DH: v2: Changed to abstract out the bundle freeing code into a function] | ||||
| CVE-2025-10079 | 1 Phpgurukul | 1 Small Crm | 2025-09-18 | 7.3 High |
| A flaw has been found in PHPGurukul Small CRM 4.0. Affected by this vulnerability is an unknown functionality of the file /get-quote.php. Executing manipulation of the argument Contact can lead to sql injection. The attack can be executed remotely. The exploit has been published and may be used. | ||||
| CVE-2024-27063 | 1 Linux | 1 Linux Kernel | 2025-09-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: leds: trigger: netdev: Fix kernel panic on interface rename trig notify Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") in the various changes, reworked the way to set the LINKUP mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function. This changed the logic where, in the previous implementation the dev from the trigger event was used to check if the carrier was ok, but in the new implementation with the generic function, the dev in trigger_data is used instead. This is problematic and cause a possible kernel panic due to the fact that the dev in the trigger_data still reference the old one as the new one (passed from the trigger event) still has to be hold and saved in the trigger_data struct (done in the NETDEV_REGISTER case). On calling of get_device_state(), an invalid net_dev is used and this cause a kernel panic. To handle this correctly, move the call to get_device_state() after the new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER case) and correctly parse the new dev. | ||||