CVE-2025-71256 is a high-severity vulnerability in the NR modem components of Unisoc (Shanghai) Technologies Co. , Ltd. T8100, T9100, T8200, and T8300 chipsets. The issue stems from improper input validation, which can be exploited remotely to cause a denial of service without requiring any user interaction or additional privileges. This vulnerability affects devices running Android versions 13 through 16. No official patch or remediation has been documented yet, and there are no known exploits in the wild at this time.
CVE-2025-71255 is a high-severity vulnerability in the modem IMS component of various Unisoc (Shanghai) Technologies chipsets. It involves improper input validation that could allow a remote denial of service without requiring any privileges or user interaction. The affected products include multiple Unisoc chipsets running Android versions 13 through 16. No patch or official remediation has been confirmed yet, and there are no known exploits in the wild at this time.
CVE-2025-71254 is a high-severity vulnerability in the modem IMS component of various Unisoc (Shanghai) Technologies chipsets running Android versions 13 through 16. The issue stems from improper input validation, which can be exploited remotely to cause a denial of service without requiring any privileges or user interaction. No confidentiality or integrity impacts are reported. There is no information about an available patch or official remediation at this time.
CVE-2025-71253 is a high-severity vulnerability in the modem IMS component of various Unisoc (Shanghai) Technologies chipsets affecting multiple Android versions from 13 to 16. The issue arises from improper input validation, which could allow a remote attacker to cause a denial of service without requiring any privileges or user interaction. There is no indication of impact on confidentiality or integrity, only availability. No official patch or remediation guidance has been provided yet, and no known exploits are reported in the wild. Users of affected devices should monitor vendor advisories for updates.
CVE-2025-71252 is a high-severity vulnerability in the modem IMS component of various Unisoc (Shanghai) Technologies chipsets running Android versions 13 through 16. It involves improper input validation that could allow a remote attacker to cause a denial of service without requiring any privileges or user interaction. No information about available patches or official remediation has been provided. There are no known exploits in the wild at this time.
CVE-2025-71251 is a high-severity vulnerability in Unisoc (Shanghai) Technologies Co. , Ltd.products involving improper input validation in the IMS component. This flaw can cause a system crash leading to a remote denial of service without requiring any privileges or user interaction. It affects multiple Unisoc chipsets running Android versions 13 through 16. No patch or official remediation guidance is currently available, and no known exploits have been reported in the wild.
CVE-2026-40068 is a high-severity vulnerability in anthropics Claude Code versions 2.1.63 through 2.1.83. The issue arises from improper input validation of the git worktree commondir file used in folder trust determination logic. An attacker can craft a malicious repository with a commondir file that points to a path the victim has previously trusted, causing Claude Code to bypass its trust confirmation dialog and execute hooks defined in . claude/settings.json without user consent. Exploitation requires the victim to clone the malicious repository and run Claude Code within it, and the attacker must know or guess a trusted path on the victim's system.
Sandboxie versions 1.17.2 and earlier contain a local denial of service vulnerability in the kernel driver. An unprivileged process inside a Standard Sandbox can send a malformed IOCTL to the SandboxieDriverApi device, causing a kernel crash (BSOD). This affects the Standard Sandbox configuration regardless of administrator privilege dropping, but not the Security Hardened Sandbox configuration. The issue is fixed in version 1.17.3. Users unable to update can mitigate by using the Security Hardened Sandbox configuration.
A race condition exists in PaperCut MF when processing badge-swipe data from certain HP multifunction devices. Under specific network conditions involving dropped packets and out-of-order sequence counters, the server may incorrectly process fragmented data chunks. If a sequence reset notification fails to reach the server, the server may reject the initial data chunk while erroneously accepting subsequent chunks before a connection reset completes.
This leads to the registration of a truncated badge ID string. While this typically results in an authentication failure, the vulnerability is compounded in environments utilizing custom badge-ID post-processing scripts. In such configurations, the truncated string may be transformed into a valid ID belonging to a different user, leading to unauthorized session establishment (Incorrect User Login) on the device.
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.
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 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.
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.
An issue in the component DirectIo64.sys of PassMark BurnInTest v11.0 Build 1011, OSForensics v11.1 Build 1007, and PerformanceTest v11.1 Build 1004 allows attackers to access kernel memory and escalate privileges via a crafted IOCTL 0x8011E044 call.
CVE-2026-5174 is an improper input validation vulnerability in Progress Software MOVEit Automation that allows privilege escalation. It affects multiple versions of MOVEit Automation released from 2024.0.0 up to versions prior to 2025.1.5. The vulnerability has a high severity rating with a CVSS score of 7.7. No official patch or remediation guidance has been provided yet, and there are no known exploits in the wild at this time.
Insufficient validation of node IDs in Qt SVG module allows arbitrary QML/JavaScript code injection when loading malicious SVG files through the VectorImage component in Qt Quick. While QML execution is typically more restricted than native code execution, this could still lead to denial of service, information disclosure, or other impacts depending on the application's privilege level and data access.
CVE-2026-1858 is a medium severity vulnerability in GNU wget2 where the software improperly validates server certificates. Specifically, wget2 accepts TLS server certificates that have incorrect Key Usage (KU) or Extended Key Usage (EKU) attributes. This flaw could allow an attacker who has compromised a certificate issued for a different purpose to reuse it for TLS server authentication, potentially undermining the security of TLS connections. No official patch or remediation guidance is currently available from the vendor. The vulnerability has not been reported as exploited in the wild.
MISP Collections did not validate UUID fields according to RFC 4122, allowing malformed UUIDs to be submitted. This could cause integrity issues or unexpected behavior in code relying on valid UUIDs. The issue is fixed in MISP version 2.5.37 by enforcing model-level validation requiring valid RFC 4122 UUIDs.
NVIDIA FLARE SDK prior to version 2.7.2 contains an improper input validation vulnerability involving path traversal. Exploiting this flaw could allow an attacker with limited privileges to cause information disclosure. The vulnerability has a CVSS score of 6.5, indicating a medium severity level. No official patch or remediation guidance has been provided yet by NVIDIA. There are no known exploits in the wild at this time.
CVE-2024-54011 is a medium severity vulnerability in the Hanwha Vision QND-8080R camera system caused by improper input validation. This flaw can lead to service disruption when the device processes certain crafted requests. The vulnerability was discovered by penetration testers at Amazon. The manufacturer has released patch firmware addressing this issue, though specific patch details were not provided in the input data. No known exploits in the wild have been reported. The vulnerability has a CVSS 4.0 base score of 5.3, indicating a moderate impact primarily due to service disruption without elevated privileges or user interaction required.