| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev100, the set_config_value() API method (@permission(Perms.SETTINGS)) in src/pyload/core/api/__init__.py gates security-sensitive options behind a hand-maintained allowlist ADMIN_ONLY_CORE_OPTIONS. The allowlist contains ("proxy", "username") and ("proxy", "password") — which protect the proxy credentials — but it does not include ("proxy", "enabled"), ("proxy", "host"), ("proxy", "port"), or ("proxy", "type"). Any authenticated user with the non-admin SETTINGS permission can enable proxying and point pyload at any host they control. From that point, every outbound download, captcha fetch, update check, and plugin HTTP call is transparently routed through the attacker. This is a direct continuation of the fix family CVE-2026-33509 / CVE-2026-35463 / CVE-2026-35464 / CVE-2026-35586, each of which patched a different missed option in the same allowlist. This vulnerability is fixed in 0.5.0b3.dev100. |
| 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. |
| Missing Authorization vulnerability in Arraytics Timetics allows Exploiting Incorrectly Configured Access Control Security Levels.
This issue affects Timetics: from n/a through 1.0.53. |
| Missing Authorization vulnerability in mingocommerce Delete All Posts allows Exploiting Incorrectly Configured Access Control Security Levels.
This issue affects Delete All Posts: through 1.1.1. |
| Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content, media, configuration, users, and system management. Prior to 1.0.0-beta.15, an insecure direct object reference and logic flaw in the Grav API plugin (UsersController::update) allows any authenticated user with basic API access (api.access) to modify their own permission configuration. An attacker can exploit this to escalate their privileges to Super Administrator (admin.super and api.super), leading to full system compromise and potential RCE. This vulnerability is fixed in 1.0.0-beta.15. |
| In Meari client applications embedding "com.meari.sdk" (including CloudEdge 5.5.0 build 220, Arenti 1.8.1 build 220, and related white-label <= 1.8.x), the integrated call path to openapi-euce.mearicloud.com can be abused to retrieve WAN IP data for arbitrary devices. The root cause is a server-side authorization failure in "GET /openapi/device/status". |
| In Meari IoT Cloud alert image storage on Alibaba OSS (latest observed; storage service version not disclosed), motion snapshots are retrievable without authentication, signed URLs, or expiry enforcement. URLs function as direct object references and remain valid beyond expected operational windows. |
| Clerk JavaScript is the official JavaScript repository for Clerk authentication. has(), auth.protect(), and related authorization predicates in @clerk/shared, @clerk/nextjs, @clerk/backend, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions. This call shape can be bypassed if certain conditions are met: a has() or auth.protect() call that combines a reverification check with any of role, permission, feature, or plan, or that combines a billing check (feature or plan) with a role or permission check. This vulnerability is fixed in @clerk/clerk-js 5.125.10 and 6.7.5. |
