| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| This issue was addressed with improved state management. This issue is fixed in macOS Tahoe 26.1. An app may be able to access sensitive user data. |
| An information disclosure issue was addressed with improved privacy controls. This issue is fixed in iOS 26.1 and iPadOS 26.1. An app may be able to fingerprint the user. |
| A vulnerability was detected in D-Link DIR-803 up to 1.04. Impacted is an unknown function of the file /getcfg.php of the component Configuration Handler. The manipulation of the argument AUTHORIZED_GROUP results in information disclosure. The attack may be performed from remote. The exploit is now public and may be used. This vulnerability only affects products that are no longer supported by the maintainer. |
| The GenerateBlocks plugin for WordPress is vulnerable to information exposure due to missing object-level authorization checks in versions up to, and including, 2.1.2. This is due to the plugin registering multiple REST API routes under `generateblocks/v1/meta/` that gate access with `current_user_can('edit_posts')`, which is granted to low-privileged roles such as Contributor. The handlers accept arbitrary entity IDs (user IDs, post IDs, etc.) and meta keys, returning any requested metadata with only a short blacklist of password-like keys for protection. There is no object-level authorization ensuring the caller is requesting only their own data, and there is no allowlist of safe keys. This makes it possible for authenticated attackers, with Contributor-level access and above, to exfiltrate personally identifiable information (PII) and other sensitive profile data of administrator accounts or any other users by directly querying user meta keys via the exposed endpoints via the `get_user_meta_rest` function. In typical WordPress + WooCommerce setups, this includes names, email, phone, and address fields that WooCommerce stores in user meta, enabling targeted phishing, account takeover pretexting, and privacy breaches. |
| The Export WP Page to Static HTML & PDF plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 4.3.4 through publicly exposed cookies.txt files containing authentication cookies. This makes it possible for unauthenticated attackers to cookies that may have been injected into the log file if the site administrator triggered a back-up using a specific user role like 'administrator.' |
| The Events Manager – Calendar, Bookings, Tickets, and more! plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 7.2.2.2 via the 'get_location' action due to insufficient restrictions on which locations can be included. This makes it possible for unauthenticated attackers to extract data from password protected, private, or draft event locations that they should not have access to. |
| Icinga DB Web provides a graphical interface for Icinga monitoring. Starting in version 1.2.0 and prior to version 1.2.2, users with access to Icinga Dependency Views, are allowed to see hosts and services that they weren't meant to on the dependency map. However, the name of an object will not be revealed nor does this grant access to a host's or service's detail view. Please note that this only affects the restrictions `filter/hosts` and `filter/services`. `filter/objects` is not affected by this and restricts objects as it is supposed to. Version 1.2.2 applies these restrictions properly. As a workaround, one may downgrade to version 1.1.3. |
| A flaw was found in the XFIXES extension. The XFixesSetClientDisconnectMode handler does not validate the request length, allowing a client to read unintended memory from previous requests. |
| The IDonate – Blood Donation, Request And Donor Management System plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the admin_donor_profile_view() function in versions 2.0.0 to 2.1.9. This makes it possible for authenticated attackers, with Subscriber-level access and above, to expose an administrator’s username, email address, and all donor fields. |
| The incomplete verification mechanism in the AutoBizLine com.mysecondline.app 1.2.91 allows attackers to log in as other users and gain unauthorized access to their personal information. |
| In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report. |
| Ilevia EVE X1 Server version ≤ 4.7.18.0.eden contains a pre-authentication file disclosure vulnerability via the 'db_log' POST parameter. Remote attackers can retrieve arbitrary files from the server, exposing sensitive system information and credentials. |
| The Flock Safety Peripheral com.flocksafety.android.peripheral application 7.38.3 for Android (installed on Falcon and Sparrow License Plate Readers and Bravo Edge AI Compute Devices) contains a cleartext DataDog API key within in its codebase. Because application binaries can be trivially decompiled or inspected, attackers can recover the OAuth secret without special privileges. This secret is intended to remain confidential and should never be embedded directly in client-side software. |
| The LearnPress – WordPress LMS Plugin plugin for WordPress is vulnerable to Sensitive Information Disclosure in all versions up to, and including, 4.2.9.4. This is due to missing capability checks in the REST endpoint /wp-json/lp/v1/load_content_via_ajax which allows arbitrary callback execution of admin-only template methods. This makes it possible for unauthenticated attackers to retrieve admin curriculum HTML, quiz questions with correct answers, course materials, and other sensitive educational content via the REST API endpoint granted they can supply valid numeric IDs. |
| The AuthPolicy metadata on Red Hat Connectivity Link contains an object which stores secretes, however it assumes those secretes are already in the kuadrant-system instead of copying it to the referred namespace. This creates space for a malicious actor with a developer persona access to leak those secrets over HTTP connection, as long the attacker knows the name of the targeted secrets and those secrets are limited to one line only. |
| A flaw was found in Keycloak. Certain endpoints in Keycloak's admin REST API allow low-privilege users to access administrative functionalities. This flaw allows users to perform actions reserved for administrators, potentially leading to data breaches or system compromise. |
| Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.1.102 and Application prior to version 25.1.1413 (VA/SaaS deployments) contains a /api-gateway/identity/search-groups endpoint that does not require authentication. Requests to https://<tenant>.printercloud10.com/api-gateway/identity/search-groups and adjustments to the `Host` header allow an unauthenticated remote attacker to enumerate every group object stored for that tenant. The response includes internal identifiers (group ID, source service ID, Azure AD object IDs, creation timestamps, and tenant IDs). This vulnerability has been confirmed to be remediated, but it is unclear as to when the patch was introduced. |
| Moodle exposed the names of hidden groups to users who had permission to create calendar events but not to view hidden groups. This could reveal private or restricted group information. |
| A possible unauthorized memory access flaw was found in the Linux kernel's cpu_entry_area mapping of X86 CPU data to memory, where a user may guess the location of exception stacks or other important data. Based on the previous CVE-2023-0597, the 'Randomize per-cpu entry area' feature was implemented in /arch/x86/mm/cpu_entry_area.c, which works through the init_cea_offsets() function when KASLR is enabled. However, despite this feature, there is still a risk of per-cpu entry area leaks. This issue could allow a local user to gain access to some important data with memory in an expected location and potentially escalate their privileges on the system. |
| In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp
vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that
is, packet sizes between 128 - 3k bytes).
We noticed MTU-related connectivity issues with Cilium's service load-
balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP
backend service where the XDP LB was doing IPIP encap led to overly large
packet sizes but only for *some* of the packets (e.g. HTTP GET request)
while others (e.g. the prior TCP 3WHS) looked completely fine on the wire.
In fact, the pcap recording on the backend node actually revealed that the
node with the XDP LB was leaking uninitialized kernel data onto the wire
for the affected packets, for example, while the packets should have been
152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes
was padded with whatever other data was in that page at the time (e.g. we
saw user/payload data from prior processed packets).
We only noticed this through an MTU issue, e.g. when the XDP LB node and
the backend node both had the same MTU (e.g. 1500) then the curl request
got dropped on the backend node's NIC given the packet was too large even
though the IPIP-encapped packet normally would never even come close to
the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let
the curl request succeed (which also indicates that the kernel ignored the
padding, and thus the issue wasn't very user-visible).
Commit e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") was too eager
to also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs
to stick to rcd->len which is the actual packet length from the descriptor.
The latter we also feed into vmxnet3_process_xdp_small(), by the way, and
it indicates the correct length needed to initialize the xdp->{data,data_end}
parts. For e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") the
relevant part was adapting xdp_init_buff() to address the warning given the
xdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on
the wire looks good again. |
