Total
27847 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-34602 | 1 Samsung | 1 Android | 2024-07-11 | N/A | 5.5 MEDIUM |
| Use of implicit intent for sensitive communication in Samsung Messages prior to SMR Jul-2024 Release 1 allows local attackers to get sensitive information. User interaction is required for triggering this vulnerability. | |||||
| CVE-2024-38071 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2024-07-11 | N/A | 7.5 HIGH |
| Windows Remote Desktop Licensing Service Denial of Service Vulnerability | |||||
| CVE-2024-37999 | 1 Siemens | 1 Medicalis Workflow Orchestrator | 2024-07-11 | N/A | 7.8 HIGH |
| A vulnerability has been identified in Medicalis Workflow Orchestrator (All versions). The affected application executes as a trusted account with high privileges and network access. This could allow an authenticated local attacker to escalate privileges. | |||||
| CVE-2024-0985 | 1 Postgresql | 1 Postgresql | 2024-07-10 | N/A | 8.0 HIGH |
| Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. Versions before PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 are affected. | |||||
| CVE-2024-38080 | 1 Microsoft | 5 Windows 11 21h2, Windows 11 22h2, Windows 11 23h2 and 2 more | 2024-07-10 | N/A | 7.8 HIGH |
| Windows Hyper-V Elevation of Privilege Vulnerability | |||||
| CVE-2024-40614 | 1 Egroupware | 1 Egroupware | 2024-07-10 | N/A | 9.8 CRITICAL |
| EGroupware before 23.1.20240624 mishandles an ORDER BY clause. This leads to json.php?menuaction=EGroupware\Api\Etemplate\Widget\Nextmatch::ajax_get_rows sort.id SQL injection by authenticated users for Address Book or InfoLog sorting. | |||||
| CVE-2023-21266 | 1 Google | 1 Android | 2024-07-09 | N/A | 7.8 HIGH |
| In multiple functions of ActivityManagerService.java, there is a possible way to escape Google Play protection due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | |||||
| CVE-2021-42287 | 1 Microsoft | 5 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 2 more | 2024-07-09 | 6.5 MEDIUM | 7.5 HIGH |
| Active Directory Domain Services Elevation of Privilege Vulnerability | |||||
| CVE-2021-34484 | 1 Microsoft | 16 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 13 more | 2024-07-09 | 4.6 MEDIUM | 7.8 HIGH |
| Windows User Profile Service Elevation of Privilege Vulnerability | |||||
| CVE-2016-0151 | 1 Microsoft | 5 Windows 10 1507, Windows 10 1511, Windows 8.1 and 2 more | 2024-07-09 | 7.2 HIGH | 7.8 HIGH |
| The Client-Server Run-time Subsystem (CSRSS) in Microsoft Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 mismanages process tokens, which allows local users to gain privileges via a crafted application, aka "Windows CSRSS Security Feature Bypass Vulnerability." | |||||
| CVE-2017-0213 | 1 Microsoft | 10 Windows 10 1507, Windows 10 1511, Windows 10 1607 and 7 more | 2024-07-09 | 1.9 LOW | 7.3 HIGH |
| Windows COM Aggregate Marshaler in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an elevation privilege vulnerability when an attacker runs a specially crafted application, aka "Windows COM Elevation of Privilege Vulnerability". This CVE ID is unique from CVE-2017-0214. | |||||
| CVE-2011-2005 | 1 Microsoft | 2 Windows Server 2003, Windows Xp | 2024-07-09 | 7.2 HIGH | 7.8 HIGH |
| afd.sys in the Ancillary Function Driver in Microsoft Windows XP SP2 and SP3 and Server 2003 SP2 does not properly validate user-mode input passed to kernel mode, which allows local users to gain privileges via a crafted application, aka "Ancillary Function Driver Elevation of Privilege Vulnerability." | |||||
| CVE-2016-0040 | 1 Microsoft | 3 Windows 7, Windows Server 2008, Windows Vista | 2024-07-09 | 7.2 HIGH | 7.8 HIGH |
| The kernel in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, and Windows 7 SP1 allows local users to gain privileges via a crafted application, aka "Windows Elevation of Privilege Vulnerability." | |||||
| CVE-2024-36041 | 1 Kde | 1 Plasma-workspace | 2024-07-09 | N/A | 7.8 HIGH |
| KSmserver in KDE Plasma Workspace (aka plasma-workspace) before 5.27.11.1 and 6.x before 6.0.5.1 allows connections via ICE based purely on the host, i.e., all local connections are accepted. This allows another user on the same machine to gain access to the session manager, e.g., use the session-restore feature to execute arbitrary code as the victim (on the next boot) via earlier use of the /tmp directory. | |||||
| CVE-2023-38546 | 1 Haxx | 1 Libcurl | 2024-07-09 | N/A | 3.7 LOW |
| This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met. libcurl performs transfers. In its API, an application creates "easy handles" that are the individual handles for single transfers. libcurl provides a function call that duplicates en easy handle called [curl_easy_duphandle](https://curl.se/libcurl/c/curl_easy_duphandle.html). If a transfer has cookies enabled when the handle is duplicated, the cookie-enable state is also cloned - but without cloning the actual cookies. If the source handle did not read any cookies from a specific file on disk, the cloned version of the handle would instead store the file name as `none` (using the four ASCII letters, no quotes). Subsequent use of the cloned handle that does not explicitly set a source to load cookies from would then inadvertently load cookies from a file named `none` - if such a file exists and is readable in the current directory of the program using libcurl. And if using the correct file format of course. | |||||
| CVE-2022-47554 | 1 Ormazabal | 4 Ekorccp, Ekorccp Firmware, Ekorrci and 1 more | 2024-07-09 | N/A | 7.5 HIGH |
| Exposure of sensitive information in ekorCCP and ekorRCI, potentially allowing a remote attacker to obtain critical information from various .xml files, including .xml files containing credentials, without being authenticated within the web server. | |||||
| CVE-2017-12741 | 1 Siemens | 76 Dk Standard Ethernet Controller, Dk Standard Ethernet Controller Firmware, Ek-ertec 200p and 73 more | 2024-07-09 | 7.8 HIGH | 7.5 HIGH |
| Specially crafted packets sent to port 161/udp could cause a denial of service condition. The affected devices must be restarted manually. | |||||
| CVE-2024-39479 | 1 Linux | 1 Linux Kernel | 2024-07-08 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) | |||||
| CVE-2024-39481 | 1 Linux | 1 Linux Kernel | 2024-07-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: mc: Fix graph walk in media_pipeline_start The graph walk tries to follow all links, even if they are not between pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link. Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK links. | |||||
| CVE-2024-39483 | 1 Linux | 1 Linux Kernel | 2024-07-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support. | |||||