🚨 CVE-2026-66149
Improper Control of Generation of Code ('Code Injection') Vulnerability in the SonicWall Email Security appliance allows an authenticated attacker with access to the SonicWall Email Security restricted CLI can inject arbitrary OS commands that execute as root via netmask.
🎖@cveNotify
Improper Control of Generation of Code ('Code Injection') Vulnerability in the SonicWall Email Security appliance allows an authenticated attacker with access to the SonicWall Email Security restricted CLI can inject arbitrary OS commands that execute as root via netmask.
🎖@cveNotify
🚨 CVE-2026-66150
Improper Control of Generation of Code ('Code Injection') Vulnerability in the SonicWall Email Security appliance allows an authenticated attacker with access to the SonicWall Email Security restricted CLI can inject arbitrary OS commands that execute as root via SNMP.
🎖@cveNotify
Improper Control of Generation of Code ('Code Injection') Vulnerability in the SonicWall Email Security appliance allows an authenticated attacker with access to the SonicWall Email Security restricted CLI can inject arbitrary OS commands that execute as root via SNMP.
🎖@cveNotify
🚨 CVE-2026-66154
An insufficient certificate validation in a privileged communication workflow, was identified in a GMS application 9.5.1 (Build 9510.1044) and earlier versions which, under a successful MitM attack and controlled network conditions, could permit unauthorized changes.
🎖@cveNotify
An insufficient certificate validation in a privileged communication workflow, was identified in a GMS application 9.5.1 (Build 9510.1044) and earlier versions which, under a successful MitM attack and controlled network conditions, could permit unauthorized changes.
🎖@cveNotify
🚨 CVE-2026-12232
The Intel ALH digital-audio-interface driver function dai_alh_get_properties() in drivers/dai/intel/alh/alh.c used a caller-supplied int stream_id with no range validation. The value indexes the fixed-size static const uint8_t alh_handshake_map[64] array and scales a FIFO register address, so an out-of-range stream_id produces an out-of-bounds read of one byte at an attacker-chosen signed offset from the array. That byte is written into prop->dma_hs_id and the resulting struct dai_properties is copied back to the caller, leaking it.
dai_get_properties_copy() is a Zephyr __syscall, and its verifier z_vrfy_dai_get_properties_copy() (drivers/dai/dai_handlers.c) validates only the device-object permission and the destination buffer, not stream_id. A user-mode thread that has been granted access to the ALH DAI device object can therefore call the syscall with an arbitrary stream_id, crossing the userspace/kernel sandbox boundary.
The impact is a one-byte-per-call arbitrary-offset kernel information disclosure (and leakage of a computed kernel address via fifo_address); a stream_id that resolves to an unmapped page faults in kernel context, giving a local denial of service. Exploitation requires CONFIG_USERSPACE and device access, making this a local, moderate-severity issue. The fix rejects negative and too-large stream_id values up front and returns NULL, which the copy wrapper maps to -ENOENT.
🎖@cveNotify
The Intel ALH digital-audio-interface driver function dai_alh_get_properties() in drivers/dai/intel/alh/alh.c used a caller-supplied int stream_id with no range validation. The value indexes the fixed-size static const uint8_t alh_handshake_map[64] array and scales a FIFO register address, so an out-of-range stream_id produces an out-of-bounds read of one byte at an attacker-chosen signed offset from the array. That byte is written into prop->dma_hs_id and the resulting struct dai_properties is copied back to the caller, leaking it.
dai_get_properties_copy() is a Zephyr __syscall, and its verifier z_vrfy_dai_get_properties_copy() (drivers/dai/dai_handlers.c) validates only the device-object permission and the destination buffer, not stream_id. A user-mode thread that has been granted access to the ALH DAI device object can therefore call the syscall with an arbitrary stream_id, crossing the userspace/kernel sandbox boundary.
The impact is a one-byte-per-call arbitrary-offset kernel information disclosure (and leakage of a computed kernel address via fifo_address); a stream_id that resolves to an unmapped page faults in kernel context, giving a local denial of service. Exploitation requires CONFIG_USERSPACE and device access, making this a local, moderate-severity issue. The fix rejects negative and too-large stream_id values up front and returns NULL, which the copy wrapper maps to -ENOENT.
🎖@cveNotify
GitHub
drivers: dai: intel: alh: sanity check stream_id in get_properties · zephyrproject-rtos/zephyr@b470bfc
dai_alh_get_properties() used the caller-provided stream_id without
any validation. The value is used to index the fixed-size
alh_handshake_map[] array and to compute the FIFO register offset, so
a...
any validation. The value is used to index the fixed-size
alh_handshake_map[] array and to compute the FIFO register offset, so
a...
🚨 CVE-2026-12233
The PSA Protected Storage credential backend (subsys/net/lib/tls_credentials/tls_credentials_trusted.c) declared its credential-store mutex as a plain zero-filled static struct k_mutex credential_lock; and never called k_mutex_init() on it. A statically zero-filled k_mutex has an uninitialized wait queue (its dlist head/tail are NULL instead of the self-referential sentinels that k_mutex_init/K_MUTEX_DEFINE install). The uncontended lock path does not touch the wait queue, so the defect is latent and serialized use behaves correctly.
When two execution contexts contend on the lock, k_mutex_lock() pends the blocking thread on the wait queue via z_pend_curr(), which calls sys_dlist_append() on the zeroed list and dereferences a NULL tail pointer (tail->next = node), faulting the kernel. The lock is held during TLS handshake credential loading and by all credential add/get/delete operations, so a deployment performing concurrent TLS handshakes (for example a server handling multiple simultaneous connections from a remote peer) or a credential-management operation concurrent with a handshake can trigger the dereference.
The impact is a denial of service: a deterministic kernel panic / device reset on the first contention. There is no memory corruption beyond the NULL dereference and no confidentiality or integrity impact; mutual exclusion on the fast path remains correct. Exposure is limited to builds with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled (PSA Protected Storage / TF-M platforms); the default volatile RAM backend initializes its lock correctly and is unaffected.
The fix initializes the mutex statically with K_MUTEX_DEFINE(credential_lock), providing a valid wait queue so the contended path no longer touches a NULL list.
🎖@cveNotify
The PSA Protected Storage credential backend (subsys/net/lib/tls_credentials/tls_credentials_trusted.c) declared its credential-store mutex as a plain zero-filled static struct k_mutex credential_lock; and never called k_mutex_init() on it. A statically zero-filled k_mutex has an uninitialized wait queue (its dlist head/tail are NULL instead of the self-referential sentinels that k_mutex_init/K_MUTEX_DEFINE install). The uncontended lock path does not touch the wait queue, so the defect is latent and serialized use behaves correctly.
When two execution contexts contend on the lock, k_mutex_lock() pends the blocking thread on the wait queue via z_pend_curr(), which calls sys_dlist_append() on the zeroed list and dereferences a NULL tail pointer (tail->next = node), faulting the kernel. The lock is held during TLS handshake credential loading and by all credential add/get/delete operations, so a deployment performing concurrent TLS handshakes (for example a server handling multiple simultaneous connections from a remote peer) or a credential-management operation concurrent with a handshake can trigger the dereference.
The impact is a denial of service: a deterministic kernel panic / device reset on the first contention. There is no memory corruption beyond the NULL dereference and no confidentiality or integrity impact; mutual exclusion on the fast path remains correct. Exposure is limited to builds with CONFIG_TLS_CREDENTIALS_BACKEND_PROTECTED_STORAGE enabled (PSA Protected Storage / TF-M platforms); the default volatile RAM backend initializes its lock correctly and is unaffected.
The fix initializes the mutex statically with K_MUTEX_DEFINE(credential_lock), providing a valid wait queue so the contended path no longer touches a NULL list.
🎖@cveNotify
GitHub
net: tls_credentials: Fix uninitilized mutex · zephyrproject-rtos/zephyr@29581d5
credentials_lock in tls_credentials_trusted.c was not initialized before
use.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
use.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
🚨 CVE-2026-12234
The userspace syscall verifiers z_vrfy_zsock_sendmsg() and z_vrfy_zsock_recvmsg() in subsys/net/lib/sockets/sockets.c snapshot the caller-supplied struct net_msghdr into a kernel-side copy with k_usermode_from_copy(), but then re-read the still-live user struct for subsequent decisions. The kernel iovec shadow buffer is sized from one read of msg->msg_iovlen, while the population loop is bounded by a second, live read of the same field.
Because msg points into ordinary user memory, a cooperating second thread in the same memory domain can inflate msg->msg_iovlen in the window between the sizing read and the loop test (a classic double-fetch / TOCTOU). The population loop then iterates past the number of net_iovec slots actually allocated, writing attacker-influenced iov_base/iov_len values beyond the end of the kernel-heap shadow buffer. The recvmsg verifier has the same defect on both its inbound and result write-back loops.
The code is reachable from an unprivileged user thread whenever CONFIG_USERSPACE is enabled and the zsock_sendmsg/zsock_recvmsg syscalls are available. A successful race corrupts kernel-managed heap memory across the user-to-kernel privilege boundary, yielding a local privilege-escalation primitive or, at minimum, a kernel-fault denial of service. The fix copies the header once and derives every size, bound, and gate from the snapshot, copying each iovec entry atomically so its base and length can no longer be raced apart.
🎖@cveNotify
The userspace syscall verifiers z_vrfy_zsock_sendmsg() and z_vrfy_zsock_recvmsg() in subsys/net/lib/sockets/sockets.c snapshot the caller-supplied struct net_msghdr into a kernel-side copy with k_usermode_from_copy(), but then re-read the still-live user struct for subsequent decisions. The kernel iovec shadow buffer is sized from one read of msg->msg_iovlen, while the population loop is bounded by a second, live read of the same field.
Because msg points into ordinary user memory, a cooperating second thread in the same memory domain can inflate msg->msg_iovlen in the window between the sizing read and the loop test (a classic double-fetch / TOCTOU). The population loop then iterates past the number of net_iovec slots actually allocated, writing attacker-influenced iov_base/iov_len values beyond the end of the kernel-heap shadow buffer. The recvmsg verifier has the same defect on both its inbound and result write-back loops.
The code is reachable from an unprivileged user thread whenever CONFIG_USERSPACE is enabled and the zsock_sendmsg/zsock_recvmsg syscalls are available. A successful race corrupts kernel-managed heap memory across the user-to-kernel privilege boundary, yielding a local privilege-escalation primitive or, at minimum, a kernel-fault denial of service. The fix copies the header once and derives every size, bound, and gate from the snapshot, copying each iovec entry atomically so its base and length can no longer be raced apart.
🎖@cveNotify
GitHub
net: sockets: fix TOCTOU in recvmsg/sendmsg · zephyrproject-rtos/zephyr@2e0f9cf
z_vrfy_zsock_sendmsg() and z_vrfy_zsock_recvmsg() copy the user
msghdr into msg_copy but then re-read msg->msg_iovlen (and other
fields) live to size the allocation, bound the loop, and gate...
msghdr into msg_copy but then re-read msg->msg_iovlen (and other
fields) live to size the allocation, bound the loop, and gate...
🚨 CVE-2026-12235
The Linkable Loadable Extensions (llext) subsystem mis-handles PLT/RELA relocation entries when linking a relocatable (partially-linked) ELF extension. In llext_link_plt() (subsys/llext/llext_link.c), the relocatable branch (tgt != NULL, the path used for Xtensa relocatable objects) computed the patch address as ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset and then performed the relocation write there without validating rela.r_offset. Its sibling shared/dynamic branch already rejected out-of-range offsets via llext_file_offset().
rela.r_offset is read directly from the ELF's RELA table, so a crafted entry with an offset larger than the target section makes the write land arbitrarily far outside the extension's text buffer. The result is an attacker-influenced out-of-bounds write (the location via r_offset, the written value being the resolved symbol address) performed in supervisor context at link time, before any extension code runs.
The path is reached from llext_load() whenever an application loads an attacker-influenced ELF extension on Xtensa with writable storage; llext is documented to accept extensions of untrusted origin. Impact is supervisor-context memory corruption (integrity and availability loss, and a sandbox-boundary escape for user-mode extensions). Exploitation is gated by the Xtensa relocatable PLT path and writable storage, and turning the out-of-range write into a useful primitive is non-trivial.
The fix adds a bound check rejecting any RELA entry whose r_offset >= tgt->sh_size, mirroring the existing validation in the shared branch.
🎖@cveNotify
The Linkable Loadable Extensions (llext) subsystem mis-handles PLT/RELA relocation entries when linking a relocatable (partially-linked) ELF extension. In llext_link_plt() (subsys/llext/llext_link.c), the relocatable branch (tgt != NULL, the path used for Xtensa relocatable objects) computed the patch address as ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset and then performed the relocation write there without validating rela.r_offset. Its sibling shared/dynamic branch already rejected out-of-range offsets via llext_file_offset().
rela.r_offset is read directly from the ELF's RELA table, so a crafted entry with an offset larger than the target section makes the write land arbitrarily far outside the extension's text buffer. The result is an attacker-influenced out-of-bounds write (the location via r_offset, the written value being the resolved symbol address) performed in supervisor context at link time, before any extension code runs.
The path is reached from llext_load() whenever an application loads an attacker-influenced ELF extension on Xtensa with writable storage; llext is documented to accept extensions of untrusted origin. Impact is supervisor-context memory corruption (integrity and availability loss, and a sandbox-boundary escape for user-mode extensions). Exploitation is gated by the Xtensa relocatable PLT path and writable storage, and turning the out-of-range write into a useful primitive is non-trivial.
The fix adds a bound check rejecting any RELA entry whose r_offset >= tgt->sh_size, mirroring the existing validation in the shared branch.
🎖@cveNotify
GitHub
llext: bound-check r_offset in Xtensa PLT relocatable branch · zephyrproject-rtos/zephyr@106540a
The PLT relocation loop has two branches depending on whether the
ELF is relocatable (tgt != NULL) or shared/dynamic (tgt == NULL).
The shared branch already validates r_offset via llext_file_offs...
ELF is relocatable (tgt != NULL) or shared/dynamic (tgt == NULL).
The shared branch already validates r_offset via llext_file_offs...
🚨 CVE-2026-64954
Velociraptor allows scheduling new collections via VQL queries in notebooks. For a user to schedule a new collection, they require the COLLECT_CLIENT permission. However, this is not enforced when the user can run a VQL query which resets the authorization provider.
This allows a user who can run arbitrary VQL (usually with the "analyst" role) to launch new collections (usually requires the "investigator" role). This vulnerability is an escalation from an analyst to investigator role.
🎖@cveNotify
Velociraptor allows scheduling new collections via VQL queries in notebooks. For a user to schedule a new collection, they require the COLLECT_CLIENT permission. However, this is not enforced when the user can run a VQL query which resets the authorization provider.
This allows a user who can run arbitrary VQL (usually with the "analyst" role) to launch new collections (usually requires the "investigator" role). This vulnerability is an escalation from an analyst to investigator role.
🎖@cveNotify
🚨 CVE-2026-12976
The LearnPress WordPress plugin before 4.4.4 does not verify that a user is enrolled in a course before processing AI-assistant requests against that course's lesson content, allowing any authenticated user such as a subscriber to obtain material from paid courses they have not enrolled in.
🎖@cveNotify
The LearnPress WordPress plugin before 4.4.4 does not verify that a user is enrolled in a course before processing AI-assistant requests against that course's lesson content, allowing any authenticated user such as a subscriber to obtain material from paid courses they have not enrolled in.
🎖@cveNotify
WPScan
LearnPress < 4.4.4 - Subscriber+ Sensitive Information Exposure via AI Assistant
See details on LearnPress < 4.4.4 - Subscriber+ Sensitive Information Exposure via AI Assistant CVE 2026-12976. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13168
The Eventin WordPress plugin before 4.1.20 does not properly restrict access to stored customer records, allowing users with contributor-level access and above to read other customers' personal data such as names and email addresses.
🎖@cveNotify
The Eventin WordPress plugin before 4.1.20 does not properly restrict access to stored customer records, allowing users with contributor-level access and above to read other customers' personal data such as names and email addresses.
🎖@cveNotify
WPScan
Eventin < 4.1.20 - Contributor+ Customer PII Disclosure via REST API
See details on Eventin < 4.1.20 - Contributor+ Customer PII Disclosure via REST API CVE 2026-13168. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13171
The Eventin WordPress plugin before 4.1.20 does not perform an authorization check on its waiting-list registration handler, allowing unauthenticated users to create WordPress user accounts for arbitrary email addresses and inject order records.
🎖@cveNotify
The Eventin WordPress plugin before 4.1.20 does not perform an authorization check on its waiting-list registration handler, allowing unauthenticated users to create WordPress user accounts for arbitrary email addresses and inject order records.
🎖@cveNotify
WPScan
Eventin < 4.1.20 - Unauthenticated Account Creation via Waiting List Endpoint
See details on Eventin < 4.1.20 - Unauthenticated Account Creation via Waiting List Endpoint CVE 2026-13171. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13177
The Eventin WordPress plugin before 4.1.20 does not properly restrict access to individual order records, allowing users with contributor-level access and above to read other customers' order data including personal information by iterating order identifiers.
🎖@cveNotify
The Eventin WordPress plugin before 4.1.20 does not properly restrict access to individual order records, allowing users with contributor-level access and above to read other customers' order data including personal information by iterating order identifiers.
🎖@cveNotify
WPScan
Eventin < 4.1.20 - Contributor+ Order Information Disclosure via IDOR
See details on Eventin < 4.1.20 - Contributor+ Order Information Disclosure via IDOR CVE 2026-13177. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13612
The KiviCare WordPress plugin before 4.5.2 does not verify that the requesting user owns the records being accessed, allowing authenticated patient-level users to read other patients' bills, invoices and appointment details.
🎖@cveNotify
The KiviCare WordPress plugin before 4.5.2 does not verify that the requesting user owns the records being accessed, allowing authenticated patient-level users to read other patients' bills, invoices and appointment details.
🎖@cveNotify
WPScan
KiviCare < 4.5.2 - Patient+ Cross-Patient Bill, Invoice and Appointment Disclosure via IDOR
See details on KiviCare < 4.5.2 - Patient+ Cross-Patient Bill, Invoice and Appointment Disclosure via IDOR CVE 2026-13612. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13613
The KiviCare WordPress plugin before 4.5.2 does not properly sanitise and escape user-supplied parameters before using them in a SQL query, allowing authenticated users with a clinic staff-level role to perform SQL injection.
🎖@cveNotify
The KiviCare WordPress plugin before 4.5.2 does not properly sanitise and escape user-supplied parameters before using them in a SQL query, allowing authenticated users with a clinic staff-level role to perform SQL injection.
🎖@cveNotify
WPScan
KiviCare < 4.5.2 - Doctor/Receptionist+ SQL Injection via settings/listing REST Endpoint
See details on KiviCare < 4.5.2 - Doctor/Receptionist+ SQL Injection via settings/listing REST Endpoint CVE 2026-13613. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14857
The WP Crowdfunding WordPress plugin before 2.2.1 does not verify ownership of a campaign before allowing its update history to be modified and a notification email sent to its backers, allowing any authenticated users such as Subscribers to alter other users' campaigns.
🎖@cveNotify
The WP Crowdfunding WordPress plugin before 2.2.1 does not verify ownership of a campaign before allowing its update history to be modified and a notification email sent to its backers, allowing any authenticated users such as Subscribers to alter other users' campaigns.
🎖@cveNotify
WPScan
WP Crowdfunding < 2.2.1 - Subscriber+ Campaign Update Modification via IDOR
See details on WP Crowdfunding < 2.2.1 - Subscriber+ Campaign Update Modification via IDOR CVE 2026-14857. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14858
The WP Crowdfunding WordPress plugin before 2.2.1 does not verify order ownership before returning order details, allowing any authenticated users such as Subscribers to read the personal data of any WooCommerce order and enumerate every order in the store.
🎖@cveNotify
The WP Crowdfunding WordPress plugin before 2.2.1 does not verify order ownership before returning order details, allowing any authenticated users such as Subscribers to read the personal data of any WooCommerce order and enumerate every order in the store.
🎖@cveNotify
WPScan
WP Crowdfunding < 2.2.1 - Subscriber+ Order Data Disclosure via IDOR
See details on WP Crowdfunding < 2.2.1 - Subscriber+ Order Data Disclosure via IDOR CVE 2026-14858. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14859
The WP Crowdfunding WordPress plugin before 2.2.1 does not check the campaign-submission capability in one of its AJAX actions, allowing any authenticated users such as Subscribers to create crowdfunding campaign posts despite not being granted that permission.
🎖@cveNotify
The WP Crowdfunding WordPress plugin before 2.2.1 does not check the campaign-submission capability in one of its AJAX actions, allowing any authenticated users such as Subscribers to create crowdfunding campaign posts despite not being granted that permission.
🎖@cveNotify
WPScan
WP Crowdfunding < 2.2.1 - Subscriber+ Campaign Creation via Missing Authorization
See details on WP Crowdfunding < 2.2.1 - Subscriber+ Campaign Creation via Missing Authorization CVE 2026-14859. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14925
The Import WP WordPress plugin before 2.14.23 does not perform any authorization check on one of its export-file download handlers, allowing unauthenticated attackers to download export files generated by administrators, which may contain user personal data such as email addresses, login names and roles. Exploitation requires an unconsumed export to already exist and a low-entropy, time-based download key to be obtained.
🎖@cveNotify
The Import WP WordPress plugin before 2.14.23 does not perform any authorization check on one of its export-file download handlers, allowing unauthenticated attackers to download export files generated by administrators, which may contain user personal data such as email addresses, login names and roles. Exploitation requires an unconsumed export to already exist and a low-entropy, time-based download key to be obtained.
🎖@cveNotify
WPScan
Import WP < 2.14.23 - Unauthenticated Sensitive Information Exposure via Export File Download
See details on Import WP < 2.14.23 - Unauthenticated Sensitive Information Exposure via Export File Download CVE 2026-14925. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-15039
The giftware WordPress plugin before 4.2.10 does not validate the type of uploaded files in one of its upload paths, allowing unauthenticated users to upload arbitrary files, including PHP code, which can lead to remote code execution.
🎖@cveNotify
The giftware WordPress plugin before 4.2.10 does not validate the type of uploaded files in one of its upload paths, allowing unauthenticated users to upload arbitrary files, including PHP code, which can lead to remote code execution.
🎖@cveNotify
WPScan
Gift Cards For WooCommerce Pro < 4.2.10 - Unauthenticated Arbitrary File Upload
See details on Gift Cards For WooCommerce Pro < 4.2.10 - Unauthenticated Arbitrary File Upload CVE 2026-15039. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-15249
The Patterns Kit WordPress plugin through 1.0.3 does not escape a link attribute before its client-side script inserts it into the page, allowing users with a role as low as Contributor to store a payload that executes in the browser of a user who views the content and clicks the affected element.
🎖@cveNotify
The Patterns Kit WordPress plugin through 1.0.3 does not escape a link attribute before its client-side script inserts it into the page, allowing users with a role as low as Contributor to store a payload that executes in the browser of a user who views the content and clicks the affected element.
🎖@cveNotify
WPScan
Patterns Kit <= 1.0.3 - Contributor+ Stored XSS via YouTube Popup Link
See details on Patterns Kit <= 1.0.3 - Contributor+ Stored XSS via YouTube Popup Link CVE 2026-15249. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-15388
The Cookie Consent WordPress plugin before 0.0.10 does not correctly enforce its intended administrator-only capability check on its consent-settings REST routes, so they fall back to an authentication-only gate, allowing any authenticated user such as a subscriber to update the Cookie Consent WordPress plugin before 0.0.10's consent settings and, on sites connected to the vendor's paid plan, read stored visitor consent logs.
🎖@cveNotify
The Cookie Consent WordPress plugin before 0.0.10 does not correctly enforce its intended administrator-only capability check on its consent-settings REST routes, so they fall back to an authentication-only gate, allowing any authenticated user such as a subscriber to update the Cookie Consent WordPress plugin before 0.0.10's consent settings and, on sites connected to the vendor's paid plan, read stored visitor consent logs.
🎖@cveNotify
WPScan
Cookie Consent < 0.0.10 - Subscriber+ Consent Settings Update and Consent Log Disclosure
See details on Cookie Consent < 0.0.10 - Subscriber+ Consent Settings Update and Consent Log Disclosure CVE 2026-15388. View the latest Plugin Vulnerabilities on WPScan.