Total
363216 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-48714 | 1 I18next | 1 I18next-http-middleware | 2026-06-16 | 9.1 Critical |
| i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. In versions prior to 3.9.7, the missingKeyHandler blocked the literal request-body keys __proto__, constructor, and prototype (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as "__proto__.polluted". Downstream backends that split the missing-key string on a configured keySeparator (notably i18next-fs-backend ≤ 2.6.5) hand these keys to an unguarded setPath() walker that writes to Object.prototype. Applications that expose missingKeyHandler to untrusted input AND use i18next-fs-backend ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. This issue has been fixed in version 3.9.7. If developers cannot upgrade immediately, they should do the following: do not expose missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), add a request-body filter ahead of the handler that rejects any top-level key containing __proto__, constructor, or prototype after splitting on their configured keySeparator, and disable missing-key persistence (saveMissing: false) when accepting writes from untrusted input. | ||||
| CVE-2026-34040 | 2 Docker, Moby | 2 Engine, Moby | 2026-06-16 | 8.8 High |
| Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ). This issue has been patched in version 29.3.1. | ||||
| CVE-2026-33997 | 2 Docker, Moby | 2 Engine, Moby | 2026-06-16 | 6.8 Medium |
| Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user. Plugins that request exactly one privilege are also affected, because no comparison is performed at all. This issue has been patched in version 29.3.1. | ||||
| CVE-2026-26791 | 1 Gl-inet | 3 Ar300m16, Ar300m16 Firmware, Gl-ar300m16 | 2026-06-16 | 9.8 Critical |
| GL-iNet GL-AR300M16 v4.3.11 was discovered to contain a command injection vulnerability via the string port parameter in the enable_echo_server function. This vulnerability allows attackers to execute arbitrary commands via a crafted input. | ||||
| CVE-2026-49768 | 2 Happyforms, Wordpress | 2 Happyforms, Wordpress | 2026-06-16 | 9.8 Critical |
| Unauthenticated PHP Object Injection in Happyforms <= 1.26.13 versions. | ||||
| CVE-2026-53475 | 1 Kubev2v | 2 Assisted-migration-agent, Assisted Migration Agent | 2026-06-16 | 9.3 Critical |
| A flaw was found in assisted-migration-agent. The application hardcodes insecure Transport Layer Security (TLS) connections when communicating with vCenter. This vulnerability allows a Man-in-the-Middle (MITM) attacker to intercept and harvest vCenter administrator credentials. This can lead to unauthorized access to vCenter. | ||||
| CVE-2026-42384 | 2 Nsquared, Wordpress | 2 Simply Schedule Appointments, Wordpress | 2026-06-16 | 7.5 High |
| Unauthenticated Sensitive Data Exposure in Simply Schedule Appointments < 1.6.11.2 versions. | ||||
| CVE-2026-53474 | 2 Kebev2v, Kubev2v | 2 Migration Assessment, Migration-planner | 2026-06-16 | 9.6 Critical |
| A flaw was found in migration-planner. A remote authenticated attacker could exploit this vulnerability by uploading a specially crafted RVTools .xlsx file. Due to improper input sanitization, malicious SQL embedded within a spreadsheet cell is executed when cluster names are processed. This SQL Injection allows for arbitrary file reading on the system, potentially exposing sensitive information such as Kubernetes service account tokens and other credentials, which could lead to a full compromise of the SaaS environment. | ||||
| CVE-2026-49110 | 2 Wordpress, Wp Swings | 2 Wordpress, Upsell Order Bump Offer For Woocommerce | 2026-06-16 | 7.5 High |
| Unauthenticated Broken Authentication in Upsell Order Bump Offer for WooCommerce <= 3.1.4 versions. | ||||
| CVE-2026-39491 | 2 Artbees, Wordpress | 2 Jupiter X Core, Wordpress | 2026-06-16 | 6.5 Medium |
| Subscriber Cross Site Scripting (XSS) in JupiterX Core <= 4.14.1 versions. | ||||
| CVE-2026-53473 | 1 Kubev2v | 2 Migration-planner-ui-app, Migration Planner Ui | 2026-06-16 | 7.3 High |
| A flaw was found in migration-planner-ui-app. An attacker can register a malicious discovery agent with a specially crafted credentialUrl containing JavaScript code. When an organizational user clicks this link in the user interface, the embedded malicious code executes within the user's browser session. This cross-site scripting (XSS) vulnerability allows the attacker to compromise the victim's Red Hat Single Sign-On (SSO) session, potentially leading to unauthorized cross-tenant data access and API actions. | ||||
| CVE-2026-39503 | 2 Awesomemotive, Wordpress | 2 Easy Digital Downloads, Wordpress | 2026-06-16 | 7.5 High |
| Unauthenticated Broken Access Control in Easy Digital Downloads <= 3.6.5 versions. | ||||
| CVE-2026-39447 | 2 Nsquared, Wordpress | 2 Simply Schedule Appointments, Wordpress | 2026-06-16 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in Simply Schedule Appointments <= 1.6.10.6 versions. | ||||
| CVE-2026-34900 | 2 Liquid Web / Stellarwp, Wordpress | 2 Givewp, Wordpress | 2026-06-16 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in GiveWP <= 4.14.2 versions. | ||||
| CVE-2026-6250 | 1 Tp-link | 2 Tapo C110, Tapo C110 Firmware | 2026-06-16 | 8.1 High |
| An authenticated format string vulnerability exists in the ONVIF service of Tapo C110 v2 due to improper handling of user-controlled input. Externally controlled data is interpreted as a format string, which can be used to manipulate stack memory, including control flow data such as return addresses. A remote authenticated attacker may redirect execution flow to existing internal functions, triggering an unauthorized factory reset, leading to loss of configuration, deletion of stored credentials and service disruption. | ||||
| CVE-2026-23970 | 2 Themeisle, Wordpress | 2 Redirection For Contact Form 7, Wordpress | 2026-06-16 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in Redirection for Contact Form 7 <= 3.2.8 versions. | ||||
| CVE-2026-27333 | 2 Videowhisper.com, Wordpress | 2 Paid Videochat Turnkey Site, Wordpress | 2026-06-16 | 8.1 High |
| Unauthenticated Deserialization of untrusted data in Paid Videochat Turnkey Site <= 7.3.23 versions. | ||||
| CVE-2026-45985 | 1 Linux | 1 Linux Kernel | 2026-06-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency. | ||||
| CVE-2026-45986 | 1 Linux | 1 Linux Kernel | 2026-06-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak. | ||||
| CVE-2026-45987 | 1 Linux | 1 Linux Kernel | 2026-06-16 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value. | ||||