Search

Search Results (384355 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2025-53999 2 Themegoods, Wordpress 2 Altair, Wordpress 2026-08-20 6.5 Medium
Unauthenticated Broken Access Control in Altair <= 5.2.2 versions.
CVE-2022-2586 4 Canonical, Linux, Redhat and 1 more 6 Ubuntu Linux, Linux Kernel, Enterprise Linux and 3 more 2026-08-20 5.3 Medium
It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted.
CVE-2026-73935 1 Oracle 1 Helidon 2026-08-20 7.5 High
Vulnerability in the Helidon product of Oracle Fusion Middleware (component: Imperative Web Server). The supported version that is affected is 4.5.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP/2 to compromise Helidon. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Helidon. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
CVE-2026-73936 1 Oracle 1 Helidon 2026-08-20 7.5 High
Vulnerability in the Helidon product of Oracle Fusion Middleware (component: Imperative Web Server). The supported version that is affected is 4.5.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Helidon. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Helidon. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
CVE-2026-18231 2026-08-20 5.3 Medium
The WP Directory Kit WordPress plugin before 1.5.7 does not perform any authorization check on one of its public AJAX actions and returns unfiltered database rows, allowing unauthenticated attackers to retrieve the usernames and email addresses of users holding the WP Directory Kit WordPress plugin before 1.5.7's own roles.
CVE-2026-66592 2 Rtcamp, Wordpress 2 Rtmedia For Wordpress, Buddypress And Bbpress, Wordpress 2026-08-20 9.3 Critical
Unauthenticated SQL Injection in rtMedia for WordPress, BuddyPress and bbPress <= 4.7.11 versions.
CVE-2026-18778 2 Truebooker, Wordpress 2 Truebooker, Wordpress 2026-08-20 5.3 Medium
The TrueBooker WordPress plugin before 1.2.7 does not have proper authorisation checks in some of its AJAX actions, allowing unauthenticated users to retrieve the personal information of customers who booked an appointment, including their name, email address, phone number and postal address.
CVE-2026-71866 1 Orval-labs 1 Orval 2026-08-20 N/A
Orval generates type-safe JavaScript clients in TypeScript from OpenAPI v3 and Swagger v2 specifications. From version 8.19.0 until 8.21.0, a double quote in a schema property name is emitted into the generated zod.object({...}) schema without safe encoding. This permits attacker-controlled JavaScript to be evaluated when the generated zod schema module is imported, resulting in code execution in the developer, CI, test, or application environment. The affected code is packages/zod/src/index.ts and zod object-key generation. This issue is fixed in version 8.21.0.
CVE-2026-72716 1 Orval-labs 1 Orval 2026-08-20 N/A
Orval generates type-safe JavaScript clients in TypeScript from OpenAPI v3 and Swagger v2 specifications. Prior to 8.21.0, a ${...} expression or backtick in a query parameter default is emitted into a module-level template literal emitted by zod schema generation without safe encoding. This permits attacker-controlled JavaScript to be evaluated when the generated zod schema module is imported, resulting in code execution in the developer, CI, test, or application environment. The affected code is packages/zod/src/index.ts function formatDefaultValue. This issue is fixed in version 8.21.0.
CVE-2026-55191 1 Freerdp 1 Freerdp 2026-08-20 8.8 High
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.27.0, FreeRDP clients that negotiate RDPGFX AVC444 with an H.264 decoder backend calculate the intermediate YUV444 allocation size in libfreerdp/codec/h264.c with 32-bit multiplication in avc444_ensure_buffer. A malicious RDP server can supply surface dimensions for which piDstStride multiplied by padDstHeight wraps to a small nonzero value, causing winpr_aligned_recalloc to allocate an undersized buffer before YUV420CombineToYUV444 writes using the actual stride and rectangle dimensions. This can cause a client crash and may permit code execution through attacker-influenced heap corruption. This issue is fixed in version 3.27.0.
CVE-2026-63652 1 Freerdp 1 Freerdp 2026-08-20 6.5 Medium
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.28.0, rdpsnd_server_recv_formats in channels/rdpsnd/server/rdpsnd_main.c frees context->client_formats on a malformed Client Audio Formats PDU without clearing the owning pointer or num_client_formats. An authenticated RDP client can trigger an error such as a cbSize larger than the remaining record, leave the dangling pointer in the server context, and cause rdpsnd_server_context_free to free the same allocation again at session teardown. This reliably terminates the server and can create allocator-dependent heap corruption. This issue is fixed in version 3.28.0.
CVE-2026-28164 2 Hashthemes, Wordpress 2 Easy Elementor Addons, Wordpress 2026-08-20 9.6 Critical
Cross-Site Request Forgery (CSRF) vulnerability in HashThemes Easy Elementor Addons allows Cross Site Request Forgery. This issue affects Easy Elementor Addons: from n/a through 2.3.7.
CVE-2026-76572 1 Pkp 1 Pkp-lib 2026-08-20 4.7 Medium
A vulnerability was detected in pkp pkp-lib up to 3.3.0-22/3.4.0-10/3.5.0-4. The affected element is the function _transformPHP of the file classes/xslt/XSLTransformer.php. The manipulation results in xml external entity reference. The attack can be executed remotely. Upgrading to version 3.3.0-23, 3.4.0-11 and 3.5.0-5 is sufficient to fix this issue. The patch is identified as 78c699370ea43ae2784e1c4ace7c947d207f2b47. Upgrading the affected component is advised.
CVE-2026-6321 2 Fast-uri, Openjsf 2 Fast-uri, Fast-uri 2026-08-20 7.5 High
fast-uri decoded percent-encoded path separators and dot segments before applying dot-segment removal in its normalize() and equal() functions. Encoded path data was treated like real slashes and parent-directory references, so distinct URIs could collapse onto the same normalized path. Applications that normalize or compare attacker-controlled URLs to enforce path-based policy can be bypassed, with a path that appears confined under an allowed prefix normalizing to a different location. Versions <= 3.1.0 are affected. Update to 3.1.1 or later.
CVE-2026-53143 1 Linux 1 Linux Kernel 2026-08-20 7.8 High
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)
CVE-2026-52991 1 Linux 1 Linux Kernel 2026-08-20 7.8 High
In the Linux kernel, the following vulnerability has been resolved: sched/psi: fix race between file release and pressure write A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1]. Consider the following scenario involving execution on two separate CPUs: CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered. Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write(). And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point *after* the live kn lock has been successfully acquired. In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition: CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== ============================= kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this. Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation. [1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---
CVE-2026-50010 1 Netty 1 Netty 2026-08-20 7.5 High
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
CVE-2026-47691 1 Netty 1 Netty 2026-08-20 8.7 High
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
CVE-2026-45674 1 Netty 1 Netty 2026-08-20 8.7 High
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
CVE-2026-45416 1 Netty 1 Netty 2026-08-20 7.5 High
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue.