| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A logic issue was addressed with improved restrictions. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to access sensitive user data. |
| The NS Maintenance Mode for WP WordPress plugin through 1.3.1 lacks authorization in its subscriber export function allowing unauthenticated attackers to download a list of a site's subscribers containing their name and email address |
| The Doppler Forms WordPress plugin through 2.5.1 registers an AJAX action install_extension without verifying user capabilities or using a nonce. As a result, any authenticated user — including those with the Subscriber role — can install and activate additional Doppler Forms WordPress plugin through 2.5.1 (limited to those whitelisted by the main Doppler Forms WordPress plugin through 2.5.1). |
| This issue was addressed by restricting options offered on a locked device. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An attacker with physical access may be able to access contacts from the lock screen. |
| The issue was addressed by adding additional logic. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An app may be able to access user-sensitive data. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An app may be able to break out of its sandbox. |
| This issue was addressed with additional entitlement checks. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An app may be able to access sensitive user data. |
| A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An app may be able to access sensitive user data. |
| This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An app may be able to access user-sensitive data. |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. An app may be able to access user-sensitive data. |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1. A sandboxed app may be able to access sensitive user data. |
| A logic issue was addressed with improved checks. This issue is fixed in iOS 26 and iPadOS 26. An attacker with physical access to an iOS device may be able to view notification contents from the Lock Screen. |
| This issue was addressed with improved entitlements. This issue is fixed in iOS 26.1 and iPadOS 26.1, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1, tvOS 26.1, visionOS 26.1. An app may be able to break out of its sandbox. |
| This issue was addressed by restricting options offered on a locked device. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2, iOS 26.1 and iPadOS 26.1. An attacker with physical access to a locked device may be able to view sensitive user information. |
| The age-restriction WordPress plugin through 3.0.2 does not have authorisation in the age_restrictionRemoteSupportRequest function, allowing any authenticated users, such as subscriber to create an admin user with a hardcoded username and arbitrary password. |
| A permissions issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Tahoe 26.1. An app may be able to break out of its sandbox. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.1. An app may be able to access protected user data. |
| The HelloLeads CRM Form Shortcode WordPress plugin through 1.0 does not have authorisation and CSRF check when resetting its settings, allowing unauthenticated users to reset them |
| In the Linux kernel, the following vulnerability has been resolved:
landlock: Fix handling of disconnected directories
Disconnected files or directories can appear when they are visible and
opened from a bind mount, but have been renamed or moved from the source
of the bind mount in a way that makes them inaccessible from the mount
point (i.e. out of scope).
Previously, access rights tied to files or directories opened through a
disconnected directory were collected by walking the related hierarchy
down to the root of the filesystem, without taking into account the
mount point because it couldn't be found. This could lead to
inconsistent access results, potential access right widening, and
hard-to-debug renames, especially since such paths cannot be printed.
For a sandboxed task to create a disconnected directory, it needs to
have write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to
the underlying source of the bind mount, and read access to the related
mount point. Because a sandboxed task cannot acquire more access
rights than those defined by its Landlock domain, this could lead to
inconsistent access rights due to missing permissions that should be
inherited from the mount point hierarchy, while inheriting permissions
from the filesystem hierarchy hidden by this mount point instead.
Landlock now handles files and directories opened from disconnected
directories by taking into account the filesystem hierarchy when the
mount point is not found in the hierarchy walk, and also always taking
into account the mount point from which these disconnected directories
were opened. This ensures that a rename is not allowed if it would
widen access rights [1].
The rationale is that, even if disconnected hierarchies might not be
visible or accessible to a sandboxed task, relying on the collected
access rights from them improves the guarantee that access rights will
not be widened during a rename because of the access right comparison
between the source and the destination (see LANDLOCK_ACCESS_FS_REFER).
It may look like this would grant more access on disconnected files and
directories, but the security policies are always enforced for all the
evaluated hierarchies. This new behavior should be less surprising to
users and safer from an access control perspective.
Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and
fix the related comment.
Because opened files have their access rights stored in the related file
security properties, there is no impact for disconnected or unlinked
files. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.2. An app may be able to access protected files within an App Sandbox container. |
