Export limit exceeded: 35432 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (35432 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-24464 | 3 Fedoraproject, Microsoft, Redhat | 7 Fedora, .net, .net Core and 4 more | 2026-05-27 | 7.5 High |
| .NET and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2022-23267 | 3 Fedoraproject, Microsoft, Redhat | 9 Fedora, .net, .net Core and 6 more | 2026-05-27 | 7.5 High |
| .NET and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2022-39399 | 5 Azul, Fedoraproject, Netapp and 2 more | 19 Zulu, Fedora, 7-mode Transition Tool and 16 more | 2026-05-27 | 3.7 Low |
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 11.0.16.1, 17.0.4.1, 19; Oracle GraalVM Enterprise Edition: 20.3.7, 21.3.3 and 22.2.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N). | ||||
| CVE-2026-48898 | 1 Joomla | 2 Joomla!, Joomla\! | 2026-05-27 | 9.8 Critical |
| An improper access check allows privilege escalation through the com_users batch task. | ||||
| CVE-2026-48904 | 1 Joomla | 2 Joomla!, Joomla\! | 2026-05-27 | 9.8 Critical |
| An improper access check allows privelege escalation through the com_users group editing webservice endpoint. | ||||
| CVE-2026-48900 | 1 Joomla | 2 Joomla!, Joomla\! | 2026-05-27 | 4.3 Medium |
| An improper access check allowed low privileged users to edit the task types of existing scheduler tasks. | ||||
| CVE-2026-48899 | 1 Joomla | 2 Joomla!, Joomla\! | 2026-05-27 | 9.8 Critical |
| An improper access check allows privilege escalation through the com_users batch task. | ||||
| CVE-2025-43357 | 1 Apple | 4 Ios, Ipados, Iphone Os and 1 more | 2026-05-26 | 5.5 Medium |
| This issue was addressed with improved redaction of sensitive information. This issue is fixed in iOS 18.7 and iPadOS 18.7, iOS 26 and iPadOS 26, macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to fingerprint the user. | ||||
| CVE-2026-43387 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser"), we don't trust the data in the frame so we should check the length better before acting on it | ||||
| CVE-2026-8240 | 1 Concretecms | 1 Concrete Cms | 2026-05-26 | 5.3 Medium |
| Concrete CMS 9.5.0 and below is vulnerable to unauthenticated page metadata disclosure across every page with a configured summary template, revealing the existence of private, draft, and restricted pages while leaking title, path, description, and author information. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. | ||||
| CVE-2026-43381 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nouveau/dpcd: return EBUSY for aux xfer if the device is asleep If we have runtime suspended, and userspace wants to use /dev/drm_dp_* then just tell it the device is busy instead of crashing in the GSP code. WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024 RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them awake while fw updates are happening. | ||||
| CVE-2026-43383 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 9.4 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. | ||||
| CVE-2026-43384 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. | ||||
| CVE-2026-43385 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net: Fix rcu_tasks stall in threaded busypoll I was debugging a NIC driver when I noticed that when I enable threaded busypoll, bpftrace hangs when starting up. dmesg showed: rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 10658 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 40793 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 131273 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 402058 jiffies old. INFO: rcu_tasks detected stalls on tasks: 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idle_cpu: -1/64 task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 flags:0x00004000 Call Trace: <TASK> ? napi_threaded_poll_loop+0x27c/0x2c0 ? __pfx_napi_threaded_poll+0x10/0x10 ? napi_threaded_poll+0x26/0x80 ? kthread+0xfa/0x240 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30 </TASK> The cause is that in threaded busypoll, the main loop is in napi_threaded_poll rather than napi_threaded_poll_loop, where the latter rarely iterates more than once within its loop. For rcu_softirq_qs_periodic inside napi_threaded_poll_loop to report its qs state, the last_qs must be 100ms behind, and this can't happen because napi_threaded_poll_loop rarely iterates in threaded busypoll, and each time napi_threaded_poll_loop is called last_qs is reset to latest jiffies. This patch changes so that in threaded busypoll, last_qs is saved in the outer napi_threaded_poll, and whether busy_poll_last_qs is NULL indicates whether napi_threaded_poll_loop is called for busypoll. This way last_qs would not reset to latest jiffies on each invocation of napi_threaded_poll_loop. | ||||
| CVE-2026-23312 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: validate USB endpoints The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. | ||||
| CVE-2026-43389 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm: memfd_luo: always dirty all folios A dirty folio is one which has been written to. A clean folio is its opposite. Since a clean folio has no user data, it can be freed under memory pressure. memfd preservation with LUO saves the flag at preserve(). This is problematic. The folio might get dirtied later. Saving it at freeze() also doesn't work, since the dirty bit from PTE is normally synced at unmap and there might still be mappings of the file at freeze(). To see why this is a problem, say a folio is clean at preserve, but gets dirtied later. The serialized state of the folio will mark it as clean. After retrieve, the next kernel will see the folio as clean and might try to reclaim it under memory pressure. This will result in losing user data. Mark all folios of the file as dirty, and always set the MEMFD_LUO_FOLIO_DIRTY flag. This comes with the side effect of making all clean folios un-reclaimable. This is a cost that has to be paid for participants of live update. It is not expected to be a common use case to preserve a lot of clean folios anyway. Since the value of pfolio->flags is a constant now, drop the flags variable and set it directly. | ||||
| CVE-2026-43390 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nstree: tighten permission checks for listing Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use may_see_all_namespaces() helper that centralizes this policy until the nstree adapts. | ||||
| CVE-2026-43391 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: nsfs: tighten permission checks for handle opening Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use may_see_all_namespaces() helper that centralizes this policy until the nstree adapts. | ||||
| CVE-2026-43392 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix starvation of scx_enable() under fair-class saturation During scx_enable(), the READY -> ENABLED task switching loop changes the calling thread's sched_class from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preempt_disable() to scx_bypass() which doesn't protect against fair-class starvation. Note that the original preempt_disable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preempt_enable() as it may have been switched to ext class. Fix it by offloading the enable body to a dedicated system-wide RT (SCHED_FIFO) kthread which cannot be starved by either fair or ext class tasks. scx_enable() lazily creates the kthread on first use and passes the ops pointer through a struct scx_enable_cmd containing the kthread_work, then synchronously waits for completion. The workfn runs on a different kthread from sch->helper (which runs disable_work), so it can safely flush disable_work on the error path without deadlock. | ||||
| CVE-2026-23457 | 1 Linux | 1 Linux Kernel | 2026-05-26 | 8.6 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp() sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary. For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser. Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length. | ||||