Export limit exceeded: 10048 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10048 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-13983 | 2 Apple, Google | 3 Ios, Iphone Os, Chrome | 2025-11-17 | 6.3 Medium |
| Inappropriate implementation in Lens in Google Chrome on iOS prior to 136.0.7103.59 allowed a remote attacker to perform UI spoofing via a crafted QR code. (Chromium security severity: Low) | ||||
| CVE-2025-8855 | 1 Optimus Software | 1 Brokerage Automation | 2025-11-15 | 8.1 High |
| Authorization Bypass Through User-Controlled Key, Weak Password Recovery Mechanism for Forgotten Password, Authentication Bypass by Assumed-Immutable Data vulnerability in Optimus Software Brokerage Automation allows Exploiting Trust in Client, Authentication Bypass, Manipulate Registry Information.This issue affects Brokerage Automation: before 1.1.71. | ||||
| CVE-2022-49943 | 1 Linux | 1 Linux Kernel | 2025-11-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix obscure lockdep violation for udc_mutex A recent commit expanding the scope of the udc_lock mutex in the gadget core managed to cause an obscure and slightly bizarre lockdep violation. In abbreviated form: ====================================================== WARNING: possible circular locking dependency detected 5.19.0-rc7+ #12510 Not tainted ------------------------------------------------------ udevadm/312 is trying to acquire lock: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0 but task is already holding lock: ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (regulator_list_mutex){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidently this was caused by the scope of udc_mutex being too large. The mutex is only meant to protect udc->driver along with a few other things. As far as I can tell, there's no reason for the mutex to be held while the gadget core calls a gadget driver's ->bind or ->unbind routine, or while a UDC is being started or stopped. (This accounts for link #1 in the chain above, where the mutex is held while the dwc2_hsotg_udc is started as part of driver probing.) Gadget drivers' ->disconnect callbacks are problematic. Even though usb_gadget_disconnect() will now acquire the udc_mutex, there's a window in usb_gadget_bind_driver() between the times when the mutex is released and the ->bind callback is invoked. If a disconnect occurred during that window, we could call the driver's ->disconnect routine before its ->bind routine. To prevent this from happening, it will be necessary to prevent a UDC from connecting while it has no gadget driver. This should be done already but it doesn't seem to be; currently usb_gadget_connect() has no check for this. Such a check will have to be added later. Some degree of mutual exclusion is required in soft_connect_store(), which can dereference udc->driver at arbitrary times since it is a sysfs callback. The solution here is to acquire the gadget's device lock rather than the udc_mutex. Since the driver core guarantees that the device lock is always held during driver binding and unbinding, this will make the accesses in soft_connect_store() mutually exclusive with any changes to udc->driver. Lastly, it turns out there is one place which should hold the udc_mutex but currently does not: The function_show() routine needs protection while it dereferences udc->driver. The missing lock and unlock calls are added. | ||||
| CVE-2025-64484 | 1 Oauth2 Proxy Project | 1 Oauth2 Proxy | 2025-11-14 | 8.5 High |
| OAuth2-Proxy is an open-source tool that can act as either a standalone reverse proxy or a middleware component integrated into existing reverse proxy or load balancer setups. In versions prior to 7.13.0, all deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications). Authenticated users can inject underscore variants of X-Forwarded-* headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised. The problem has been patched with v7.13.0. By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away. For those who have a rational that requires keeping a similar looking header and not stripping it, the maintainers introduced a new configuration field for Headers managed through the AlphaConfig called `InsecureSkipHeaderNormalization`. As a workaround, ensure filtering and processing logic in upstream services don't treat underscores and hyphens in Headers the same way. | ||||
| CVE-2025-10161 | 1 Turkguven | 1 Perfektive | 2025-11-14 | 7.3 High |
| Improper Restriction of Excessive Authentication Attempts, Client-Side Enforcement of Server-Side Security, Reliance on Untrusted Inputs in a Security Decision vulnerability in Turkguven Software Technologies Inc. Perfektive allows Brute Force, Authentication Bypass, Functionality Bypass.This issue affects Perfektive: before Version: 12574 Build: 2701. | ||||
| CVE-2025-31357 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attacker can obtain a user's plant list by knowing the username. | ||||
| CVE-2025-31933 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attacker can check the existence of usernames in the system by querying an API. | ||||
| CVE-2025-31941 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attacker can obtain a list of smart devices by knowing a valid username. | ||||
| CVE-2025-31949 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An authenticated attacker can obtain any plant name by knowing the plant ID. | ||||
| CVE-2025-24315 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| Unauthenticated attackers can add devices of other users to their scenes (or arbitrary scenes of other arbitrary users). | ||||
| CVE-2025-24850 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An attacker can export other users' plant information. | ||||
| CVE-2025-25276 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attacker can hijack other users' devices and potentially control them. | ||||
| CVE-2025-26857 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| Unauthenticated attackers can rename arbitrary devices of arbitrary users (i.e., EV chargers). | ||||
| CVE-2022-49986 | 1 Linux | 1 Linux Kernel | 2025-11-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- | ||||
| CVE-2025-27561 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| Unauthenticated attackers can rename "rooms" of arbitrary users. | ||||
| CVE-2025-27565 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attacker can delete any user's "rooms" by knowing the user's and room IDs. | ||||
| CVE-2025-27575 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attacker can obtain EV charger version and firmware upgrading history by knowing the charger ID. | ||||
| CVE-2025-27719 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| Unauthenticated attackers can query an API endpoint and get device details. | ||||
| CVE-2025-27927 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| An unauthenticated attackers can obtain a list of smart devices by knowing a valid username through an unprotected API. | ||||
| CVE-2025-27929 | 1 Growatt | 1 Cloud Portal | 2025-11-14 | 5.3 Medium |
| Unauthenticated attackers can retrieve full list of users associated with arbitrary accounts. | ||||