| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| barebox prior to version 2026.04.0 contains out-of-bounds read vulnerabilities in ext4 extent parsing due to missing validation of the eh_entries field against buffer capacity in fs/ext4/ext4_common.c. Attackers can supply a malicious ext4 filesystem image via USB, SD card, or network boot to trigger heap out-of-bounds reads during boot-time filesystem parsing, potentially redirecting reads to arbitrary disk offsets. |
| CryptX versions before 0.088 for Perl do not reseed the Crypt::PK PRNG state after forking.
The Crypt::PK::RSA, Crypt::PK::DSA, Crypt::PK::DH, Crypt::PK::ECC, Crypt::PK::Ed25519 and Crypt::PK::X25519 modules seed a per-object PRNG state in their constructors and reuse it without fork detection. A Crypt::PK::* object created before `fork()` shares byte-identical PRNG state with every child process, and any randomized operation they perform can produce identical output, including key generation. Two ECDSA or DSA signatures from different processes are enough to recover the signing private key through nonce-reuse key recovery.
This affects preforking services such as the Starman web server, where a Crypt::PK::* object loaded at startup is inherited by every worker process. |
| WeGIA is a web manager for charitable institutions. In versions prior to 3.6.10, when attempting to upload a file with malicious content to funcionario/docdependente_upload.php, the application responds with an overly descriptive error message. This leads to information disclosure, effectively increasing the attack surface by providing potential attackers with technical insights to refine their exploits. This vulnerability is fixed in 3.6.10. |
| 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. |
| Due to improper Spring Security configuration, SAP Commerce cloud allows an unauthenticated user to perform malicious configuration upload and code injection, resulting in arbitrary server-side code execution, leading to high impact on Confidentiality, Integrity, and Availability of the application. |
| Exposure of session signing secret in Checkmk <2.4.0p23, <2.3.0p45 and 2.2.0 allows an administrator of a remote site with config sync enabled to hijack sessions on the central site by forging session cookies. |
| A vulnerability in the `_create_model_version()` handler of `mlflow/server/handlers.py` in mlflow/mlflow versions 3.9.0 and earlier allows an unauthenticated remote attacker to read arbitrary files from the server's filesystem. The issue arises when a `CreateModelVersion` request includes the tag `mlflow.prompt.is_prompt`, which bypasses source path validation. This enables an attacker to store an arbitrary local filesystem path as the model version source. The `get_model_version_artifact_handler()` function later uses this source to serve files without verifying the model version's prompt status, leading to a complete confidentiality compromise. This issue is fixed in version 3.10.0. |
| pam_authnft is a PAM session module binding nftables firewall rules to authenticated sessions via cgroupv2 inodes. Prior to 0.2.0-alpha, a heap buffer over-read in peer_lookup_tcp (src/peer_lookup.c:134, prior to the fix) allowed a crafted NETLINK_SOCK_DIAG reply to slip past the message-size check, then dereference past the end of the allocation. This vulnerability is fixed in 0.2.0-alpha. |
| Dell PowerScale InsightIQ, versions 5.0.0 through 6.2.0, contains an execution with unnecessary privileges vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to elevation of privileges. |
| The affected devices contain a null pointer dereference vulnerability while processing specially crafted IPv4 requests. This could allow an attacker to cause denial of service condition. A manual restart is required to recover the system. |
| The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can create new VMs using backups of any other user of the environment.
Backup plugin users using CloudStack 4.21.0.0+ are recommended to upgrade to CloudStack version 4.22.0.1, which fixes this issue. |
| The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can restore a volume from any other user's backups and attach the volume to their own VMs.
Backup plugin users using CloudStack 4.21.0.0+ are recommended to upgrade to CloudStack version 4.22.0.1, which fixes this issue. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-21 and 6.9.13-46, a malicious MIFF file could trigger an overflow when a user opens it in the display tool and right-clicks a tile to invoke the Load / Update menu item. This vulnerability is fixed in 7.1.2-21 and 6.9.13-46. |
| Outline is a service that allows for collaborative documentation. Prior to 1.7.1, the Slack integration callback for GET /auth/slack.post accepts an unsigned, session-independent OAuth state value. A third party who can obtain a Slack OAuth code for the same Outline Slack client can make a logged-in Outline user complete the callback and link that user's Outline account to the attacker's Slack team_id and user_id. The linked Slack identity can then use the Slack /outline search command as the victim Outline user. This vulnerability is fixed in 1.7.1. |
| 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. |
| CWE‑331 Insufficient Entropy vulnerability exists that could lead to unauthorized access when an attacker on the network can exploit weaknesses in session‑management protections. |
| Spring AI's chat memory component contained a problematic default that, when not explicitly overridden, could result in unintended data exposure between users. |
| Audiobookshelf is a self-hosted audiobook and podcast server. Prior to 2.33.0, a stored cross-site scripting (XSS) vulnerability exists in the Login Page due to improper sanitization of the authLoginCustomMessage field of the /api/auth-settings endpoint. An attacker with administrative privileges can inject arbitrary HTML/JavaScript that will be rendered on the login page for all users. This vulnerability is fixed in 2.33.0. |
| In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials
that
only work for one table's files, but a crafted namespace or table name can
cause those credentials to work across the configured bucket instead.
Apache Polaris builds Google Cloud Storage downscoped credentials by creating a
Credential Access Boundary (CAB) with CEL conditions that are intended to
restrict access to the requested table's storage path.
The relevant CEL string is built from the bucket name and the table path.
That
table path is derived from namespace and table identifiers. In current code,
that path appears to be inserted into the CEL expression without escaping.
As a result, a namespace or table identifier containing a single quote and
other URI-safe CEL fragments can break out of the intended quoted string and
change the meaning of the CEL condition.
In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated
GCS
credentials whose CEL path restriction had effectively collapsed.
Those delegated credentials could then:
- list another table's object prefix;
- read another table's metadata control file (Iceberg metadata JSON);
- create and delete an object under another table's object prefix;
- and also list, read, create, and delete objects under an unrelated
external
prefix in the same bucket that was not part of any table path.
That last point is important. The issue is not limited to "another table".
In
the confirmed setup, once Apache Polaris returned credentials for the crafted
table,
the path restriction inside the configured bucket was effectively gone.
The practical effect is that temporary credentials for one crafted table
can be
broader than the table Polaris was asked to authorize, and can become
effectively bucket-wide within the configured bucket.
The current GCS testing used a Polaris principal with broad catalog
privileges for setup. A separate least-privilege Polaris RBAC variant
has not yet been tested on GCS. However, the storage-credential
broadening behavior itself has been confirmed on GCS. |
| Apache Polaris accepts literal `*` characters in namespace and table names. When it
later builds temporary S3 access policies for delegated table access, those
same characters appear to be reused unescaped in S3 IAM resource patterns
and
`s3:prefix` conditions.
In S3 IAM policy matching, `*` is treated as a wildcard rather than as
ordinary text. That means temporary credentials issued for one crafted table
can match the storage path of a different table.
In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary-
credential path on both MinIO and real AWS S3, credentials returned for
crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other
tables' S3 locations.
The confirmed behavior includes:
- reading another table's metadata control file ([Iceberg metadata JSON]);
- listing another table's exact S3 table prefix ([table prefix]);
- and, when write delegation was returned for the crafted table, creating
and
deleting an object under another table's exact S3 table prefix.
A control case using ordinary different names did not allow the same
cross-table access.
A least-privilege AWS S3 variant was also confirmed in which the attacker
principal had no Polaris permissions on the victim table and only the
minimal permissions required to create and use a crafted wildcard table
(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that
setup, direct Polaris access to `foo.t1` remained forbidden, but the
attacker
could still create and load `*.*`, receive delegated S3 credentials, and use
those credentials to list, read, create, and delete objects under `foo.t1`.
In Iceberg, the metadata JSON file is a control file: it tells readers which
data files belong to the table, which snapshots exist, and which table
version
to read. So unauthorized access to it is already a meaningful
confidentiality
problem. The confirmed write-capable variant means the issue is not limited
to
disclosure. |
