Export limit exceeded: 421019 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (421019 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-47104 | 1 Libusb | 1 Libusb | 2026-05-28 | 4 Medium |
| libusb before version 1.0.30 contains a one-byte out-of-bounds read vulnerability in parse_iad_array() in descriptor.c that allows attackers to trigger a denial of service by supplying a malformed USB descriptor whose bLength equals size minus one, causing the bounds check to use the original buffer size instead of the remaining size. Attackers in virtualized environments with USB passthrough can supply crafted descriptors through libusb_get_active_interface_association_descriptors or libusb_get_interface_association_descriptors to read one byte past the end of the malloc allocation, resulting in a denial of service. | ||||
| CVE-2026-9712 | 1 Pretix | 1 Pretix | 2026-05-28 | N/A |
| When creating an export through the pretix API, API clients are returned an UUID value for their export job (a long, random string like 35742818-c375-4d15-839f-d49aecce94d6). Using this UUID, the API client can then request the actual file for download. The same kind of UUID is used in other places in pretix when temporary files are generated for internal use or download. One remaining API endpoint, however, wrongfully did not verify if the UUID used for download actually belongs to a file that is supposed to be downloadable and belongs to the correct user. In reality, this is hard to exploit because an attacker would need to have access to a valid UUID for the file they desire which is unlikely to happen without a separate security problem giving them access to logs etc. | ||||
| CVE-2026-38930 | 1 Openrapid | 1 Rapidcms | 2026-05-28 | 6.5 Medium |
| OpenRapid RapidCMS v1.3.1 was discovered to contain an authentication bypass in the /template/default/menu.php component. This vulnerability is exploited via injecting a crafted SQL payload into the name cookie parameter. | ||||
| CVE-2026-44475 | 1 Ellanetworks | 1 Core | 2026-05-28 | 6.1 Medium |
| Ella Core is a 5G core designed for private networks. Prior to 1.10.0, Ella Core does not verify the UE Security Capabilities received in NGAP PathSwitchRequest messages against its locally stored values. A malicious gNB can overwrite Ella Core's stored UE security capabilities for any UE with arbitrary values by sending a single crafted PathSwitchRequest. This vulnerability is fixed in 1.10.0. | ||||
| CVE-2026-9531 | 1 Totolink | 1 Ca750-poe | 2026-05-28 | 6.3 Medium |
| A weakness has been identified in Totolink CA750-PoE 6.2c.510. Impacted is the function setUpgradeUboot of the file /cgi-bin/cstecgi.cgi of the component Setting Handler. This manipulation of the argument FileName causes os command injection. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. | ||||
| CVE-2026-45924 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: <TASK> dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 </TASK> Found by Linux Verification Center (linuxtesting.org). | ||||
| CVE-2026-45926 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rust: pwm: Fix potential memory leak on init error When initializing a PWM chip using pwmchip_alloc(), the allocated device owns an initial reference that must be released on all error paths. If __pinned_init() were to fail, the allocated pwm_chip would currently leak because the error path returns without calling pwmchip_put(). | ||||
| CVE-2026-45937 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: crypto: inside-secure/eip93 - fix kernel panic in driver detach During driver detach, the same hash algorithm is unregistered multiple times due to a wrong iterator. | ||||
| CVE-2026-45938 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_lbc: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. | ||||
| CVE-2026-45939 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpib: Fix memory leak in ni_usb_init() In ni_usb_init(), if ni_usb_setup_init() fails, the function returns -EFAULT without freeing the allocated writes buffer, leading to a memory leak. Additionally, ni_usb_setup_init() returns 0 on failure, which causes ni_usb_init() to return -EFAULT, an inappropriate error code for this situation. Fix the leak by freeing writes in the error path. Modify ni_usb_setup_init() to return -EINVAL on failure and propagate this error code in ni_usb_init(). | ||||
| CVE-2024-49924 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-05-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime. | ||||
| CVE-2026-45718 | 1 Budibase | 1 Budibase | 2026-05-28 | 5.4 Medium |
| Budibase is an open-source low-code platform. Prior to 3.38.1, the row action trigger endpoint (POST /api/tables/:sourceId/actions/:actionId/trigger) fails to validate that the user-supplied rowId is within the scope of the view's row filters. A user with access to a filtered view can trigger row actions on any row in the underlying table, including rows explicitly excluded by the view's security filters. This vulnerability is fixed in 3.38.1. | ||||
| CVE-2026-46427 | 1 Budibase | 1 Budibase | 2026-05-28 | 7.7 High |
| Budibase is an open-source low-code platform. Prior to 3.38.3, removeSecrets at packages/server/src/sdk/workspace/datasources/datasources.ts masks only datasource config fields whose schema type is DatasourceFieldType.PASSWORD. The Snowflake integration types its privateKey field as SENSITIVE_LONGFORM, which the filter skips. GET /api/datasources/:datasourceId lives on authorizedRoutes guarded by PermissionType.TABLE + PermissionLevel.READ. An authenticated BASIC user with any app role and call the endpoint and receive the full Snowflake PEM in plaintext. This vulnerability is fixed in 3.38.3. | ||||
| CVE-2026-4392 | 1 Teamspeak 3 Server | 1 Teamspeak 3 Server | 2026-05-28 | 5.3 Medium |
| A vulnerability was detected in TeamSpeak 3 Server up to 3.13.7. This issue affects some unknown processing of the component clientek Handshake Handler. Performing a manipulation of the argument proof results in reachable assertion. Remote exploitation of the attack is possible. Upgrading to version 3.13.8 is capable of addressing this issue. Upgrading the affected component is recommended. | ||||
| CVE-2026-48149 | 1 Budibase | 1 Budibase | 2026-05-28 | 8.1 High |
| Budibase is an open-source low-code platform. Prior to 3.39.0, the Budibase Text component renders markdown by assigning marked.parse(markdown) straight to innerHTML with no sanitizer (packages/bbui/src/Markdown/MarkdownViewer.svelte:22). Any column a builder binds to a Text component in Markdown mode is a stored-XSS sink writable by every BASIC app user with WRITE on the underlying table. This vulnerability is fixed in 3.39.0. | ||||
| CVE-2026-45903 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memory access flags in helper prototypes After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier started relying on the access type flags in helper function prototypes to perform memory access optimizations. Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the corresponding MEM_RDONLY or MEM_WRITE flags. This omission causes the verifier to incorrectly assume that the buffer contents are unchanged across the helper call. Consequently, the verifier may optimize away subsequent reads based on this wrong assumption, leading to correctness issues. For bpf_get_stack_proto_raw_tp, the original MEM_RDONLY was incorrect since the helper writes to the buffer. Change it to ARG_PTR_TO_UNINIT_MEM which correctly indicates write access to potentially uninitialized memory. Similar issues were recently addressed for specific helpers in commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer") and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args"). Fix these prototypes by adding the correct memory access flags. | ||||
| CVE-2026-45906 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: power: supply: pf1550: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle. | ||||
| CVE-2026-45907 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix deadlocks between devlink and netdev instance locks In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering. The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock. But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary. | ||||
| CVE-2026-45914 | 1 Linux | 1 Linux Kernel | 2026-05-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Revert "hwmon: (ibmpex) fix use-after-free in high/low store" This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix. | ||||
| CVE-2026-9542 | 1 Codeastro | 1 Leave Management System | 2026-05-28 | 6.3 Medium |
| A weakness has been identified in CodeAstro Leave Management System 1.0. The affected element is an unknown function of the file /admin/add_staff.php. Executing a manipulation of the argument email_id can lead to sql injection. The attack can be launched remotely. The exploit has been made available to the public and could be used for attacks. | ||||