| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Blog2Social: Social Media Auto Post & Scheduler plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 8.9.0. This is due to a missing ownership verification in the B2S_Post_Tools::deleteUserPublishPost() and B2S_Post_Tools::deleteUserSchedPost() functions, neither function includes a blog_user_id constraint in its database query, allowing authenticated attackers to soft-delete any user's B2S post records by supplying arbitrary sequential wp_b2s_posts.id values via the 'postId' parameter. This makes it possible for authenticated attackers to delete other users' published and scheduled social media post records, disrupting content publishing workflows. |
| Missing Authorization vulnerability in WPMU DEV Hustle allows Exploiting Incorrectly Configured Access Control Security Levels.
This issue affects Hustle: through 7.8.10.1. |
| An authorization issue was addressed with improved state management. This issue is fixed in macOS Tahoe 26.4. An app may be able to access sensitive user data. |
| phpVMS is a PHP application to run and simulate an airline. Prior to version 7.0.6, a critical vulnerability in phpVMS allowed unauthenticated access to a legacy import feature. This issue has been patched in version 7.0.6. |
| An authorization issue was addressed with improved state management. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. An app may be able to gain root privileges. |
| Audiobookshelf is a self-hosted audiobook and podcast server. Prior to 2.32.2, the GET /api/libraries/:id/download endpoint validates that the requesting user has access to the library specified in the URL path, but fetches downloadable items solely by attacker-provided IDs without constraining them to that library. An authenticated user with download permission and access to any one library can exfiltrate the full file contents of items belonging to any other library, including libraries they are explicitly denied access to. This vulnerability is fixed in 2.32.2. |
| SKYSEA Client View and SKYMEC IT Manager provided by Sky Co.,LTD. configure the installation folder with improper file access permission settings. A non-administrative user may manipulate and/or place arbitrary files within the installation folder of the product. As a result, arbitrary code may be executed with the administrative privilege. |
| Grav is a file-based Web platform. Prior to 2.0.0-beta.2, a low-privileged user (EX: Content Editor with only pages.update permissions) can bypass the existing Twig sandbox restrictions by utilizing the grav['accounts'] service. Attacker can programmatically load administrative user objects and extract sensitive data, including Bcrypt password hashes and the security salt. This vulnerability is fixed in 2.0.0-beta.2. |
| lxc is a Linux container runtime. In the setuid helper lxc-user-nic, the delete path contains a logic flaw in the find_line() function that allows an unprivileged user to delete OVS-attached network interfaces belonging to other users. When lxc-user-nic delete scans its NIC database to authorize a deletion request, the interface name comparison can set the authorization flag based on a name match alone, even when the ownership, type, and link fields in that database entry belong to a different user. The vulnerable check sits after the goto next label handling, meaning it is reachable on lines where earlier ownership checks failed or were skipped. Because nothing downstream of this authorization signal re-verifies that the matched database line actually belongs to the caller, an unprivileged attacker with a valid lxc-usernet policy entry can trigger deletion of another user's OVS port on the same bridge.
This is limited to multi-tenant environments using lxc-user-nic with OpenVSwitch bridges. The impact is denial of service - one tenant can repeatedly disconnect networking from containers run by another tenant on shared infrastructure. This is patched in version 7.0.0. |
| An authorization issue was addressed with improved state management. This issue is fixed in iOS 15.8.4 and iPadOS 15.8.4, iOS 16.7.11 and iPadOS 16.7.11, iOS 18.3.1 and iPadOS 18.3.1, iPadOS 17.7.5. A physical attack may disable USB Restricted Mode on a locked device. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals. |
| Kimai is an open-source time tracking application. Prior to version 2.54.0, the Team API endpoints use #[IsGranted('edit_team')] instead of #[IsGranted('edit', 'team')], causing Symfony TeamVoter to abstain from voting. This removes entity-level ownership checks on team operations, allowing any user with the edit_team permission to modify any team, not just teams they are authorized to manage. This issue has been patched in version 2.54.0. |
| Grav is a file-based Web platform. Prior to 2.0.0-beta.2, the Login::register() method in the Login plugin accepts attacker-controlled groups and access fields from the registration POST data without server-side validation. When registration is enabled and groups or access are included in the configured allowed fields list, an unauthenticated user can self-register with admin.super privileges by injecting these fields into the registration request. This vulnerability is fixed in 2.0.0-beta.2. |
| Outline is a service that allows for collaborative documentation. Prior to 1.7.0, the shares.create API accepts both collectionId and documentId simultaneously and, when published=false, only verifies read access for each—skipping the "share" permission check. A subsequent shares.update authorizes publication using an OR policy (can share collection OR can share document), so an attacker who holds share permission on one unrelated collection can publish a share that exposes an arbitrary document they cannot legitimately share, making it publicly accessible to unauthenticated users. This vulnerability is fixed in 1.7.0. |
| In Apache Iceberg, the table's metadata files are control files: they tell readers
which data files belong to the table and which table version to read.
`write.metadata.path` is an optional table property that tells Polaris
where to
write those metadata files.
For a table already registered in a
Polaris-managed
catalog, changing only that property through an `ALTER TABLE`-style settings
change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses
the commit-time branch that is supposed to revalidate storage locations.
The full persisted / credential-vending variant requires the affected
catalog
to have `polaris.config.allow.unstructured.table.location=true`, with
`allowedLocations` broad enough to include the attacker-chosen target.
`allowedLocations` is the admin-configured allowlist of storage paths that
the
catalog is allowed to use. Public project materials suggest that this flag
is a
real supported compatibility / layout mode, not just a contrived lab-only
prerequisite.
In that configuration, a user who can change table settings can cause Apache Polaris
itself to write new table metadata to an attacker-chosen reachable storage
location before the intended location-validation branch runs.
If the later concrete-path validation also accepts that location, Polaris
persists the resulting metadata path into stored table state. Later
table-load
and credential APIs can then return temporary cloud-storage credentials for
the
same location without revalidating it. In plain terms, Polaris can later
hand
out temporary storage access for the same attacker-chosen area.
That attacker-chosen area does not need to be limited to the poisoned
table's
own files. If it is a broader storage prefix, another table's prefix, or,
depending on configuration or provider behavior, even a bucket/container
root,
the resulting disclosure or corruption scope can extend to any data and
metadata Polaris can reach there.
The practical consequences are therefore similar to the staged-create
credential-vending issue already discussed: data and metadata reachable in
that
storage scope can be exposed and, if write-capable credentials are later
issued, modified, corrupted, or removed. Even before that later credential
step, Polaris itself performs the metadata write to the unchecked location.
So the core issue is not only later credential vending.
The primary defect
is
that Polaris skips its intended location checks before performing a
security-
sensitive metadata write when only `write.metadata.path` changes.
When `polaris.config.allow.unstructured.table.location=false`, current code
review suggests the later `updateTableLike(...)` validation usually rejects
out-of-tree metadata locations before the unsafe path is persisted. That may
reduce the persisted / credential-vending variant, but it does not prevent
the
underlying defect: Polaris still skips the intended pre-write location check
when only `write.metadata.path` changes. |
| Apache Polaris can issue broad temporary ("vended") storage credentials during
staged
table creation before the effective table location has been validated or
durably reserved.
Those temporary credentials are meant to limit the scope
of
accessible table data and metadata, but this scope limitation becomes
attacker-
directed because the attacker can choose a reachable target location.
In the confirmed variant, if the caller supplies a custom `location` during
stage create and requests credential vending, Apache Polaris uses that location to
construct delegated storage credentials immediately. The stage-create path
itself neither runs the normal location validation nor the overlap checks
before those credentials are issued.
Closely related to that, the staged-create flow also accepts
`write.data.path` / `write.metadata.path` in the request properties and
feeds
those location overrides into the same effective table location set used for
credential vending. Those fields are secondary to the main custom-`location`
exploit, but they are still attacker-influenced location inputs that should
be
validated before any credentials are issued. |
| Audiobookshelf is a self-hosted audiobook and podcast server. Prior to 2.32.2, the GET /api/collections and GET /api/collections/:id endpoints return collections from all libraries without checking whether the requesting user has access to each collection's library. An authenticated user with access to any library can enumerate and read collections (including full book metadata) from libraries they are explicitly restricted from accessing. This vulnerability is fixed in 2.32.2. |
| An access control vulnerability was discovered in the Threat Intelligence functionality due to a specific access restriction not being properly enforced for users with view-only privileges. An authenticated user with view-only privileges for the Threat Intelligence functionality can perform administrative actions on it, altering the rules configuration, and/or affecting their availability. |
| Due to missing authorization check in SAP S/4HANA Condition Maintenance, an authenticated attacker could gain unauthorized access to view and modify condition table records, resulting in low impact on the confidentiality and integrity of the data. Additionally, this vulnerability may prevent the legitimate user from accessing the records, causing low impact on application availability. |
| Due to missing authorization check in SAP Strategic Enterprise Management (Scorecard Wizard in Business Server Pages), an authenticated attacker could access information that they are otherwise unauthorized to view. This vulnerability also enables the attacker to change the default settings and modify value fields, which will mislead risk evaluations and falsely lower assessed risk levels. This results in a low impact on the confidentiality and integrity of the data. There is no impact on the application�s availability. |
| Due to insufficient authorization checks in the SAP Incentive and Commission Management application, authenticated users could invoke a remote-enabled function module to perform table update operations. This vulnerability has a low impact on integrity with no impact on confidentiality and availability of the application. |
