Export limit exceeded: 29730 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (29730 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-42261 | 1 Legeling | 1 Prompthub | 2026-05-12 | 7.1 High |
| PromptHub is an all-in-one AI toolbox for prompt, skill, and agent management. From version 0.4.9 to before version 0.5.4, apps/web/src/routes/skills.ts exposes an authenticated endpoint POST /api/skills/fetch-remote that fetches a user-supplied URL server-side and reflects the response body (up to 5 MB) back to the caller. The SSRF protection in apps/web/src/utils/remote-http.ts (isPrivateIPv6) attempts to block private/loopback destinations, but multiple alternate-but-valid IPv6 representations bypass the check. The bypasses reach any IPv4 address (loopback, RFC1918, link-local) via IPv4-mapped IPv6 in hex form, and the canonical ::1 via any representation that isn't the literal string "::1". Any authenticated user (role: user or admin) can trigger the SSRF. On deployments configured with ALLOW_REGISTRATION=true — a supported and documented configuration — this means any internet user who can register. This issue has been patched in version 0.5.4. | ||||
| CVE-2026-45215 | 2 Saad Iqbal, Wordpress | 2 Wp Easypay, Wordpress | 2026-05-12 | 5.3 Medium |
| Insertion of Sensitive Information Into Sent Data vulnerability in Saad Iqbal WP EasyPay wp-easy-pay allows Retrieve Embedded Sensitive Data.This issue affects WP EasyPay: from n/a through <= 4.3.0. | ||||
| CVE-2026-42613 | 1 Getgrav | 1 Grav | 2026-05-12 | 9.4 Critical |
| 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. | ||||
| CVE-2026-42873 | 1 Labredescefetrj | 1 Wegia | 2026-05-12 | 0 Low |
| 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. | ||||
| CVE-2026-42812 | 1 Apache | 1 Polaris | 2026-05-12 | 9.9 Critical |
| 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. | ||||
| CVE-2026-42811 | 1 Apache | 1 Polaris | 2026-05-12 | 9.9 Critical |
| 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. | ||||
| CVE-2026-42810 | 1 Apache | 1 Polaris | 2026-05-12 | 9.9 Critical |
| 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. | ||||
| CVE-2026-42809 | 1 Apache | 1 Polaris | 2026-05-12 | 9.9 Critical |
| 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. | ||||
| CVE-2026-43873 | 1 Wwbn | 1 Avideo | 2026-05-12 | 7.5 High |
| WWBN AVideo is an open source video platform. In versions up to and including 29.0, plugin/CloneSite/cloneClient.json.php echoes the local CloneSite shared secret ($objClone->myKey, a constant md5($global['systemRootPath'] . $global['salt'])) into the HTTP response body on every unauthenticated request. The unauthenticated error branch was intended to reject non-admin callers without a valid key, but the rejection message interpolates the expected key before die(). When the victim has CloneSite configured with a remote cloneSiteURL (standard federation/backup setup), the leaked myKey is exactly the credential that authenticates the victim to that remote server's cloneServer.json.php, allowing the attacker to impersonate the victim and trigger a full mysqldump of the remote's database to the remote's public videos/clones/ directory Commit e6566f56a28f4556b2a0a09d03717a719dcb49da contains an updated fix. | ||||
| CVE-2026-43899 | 1 Thinkinai | 1 Deepchat | 2026-05-12 | 9.6 Critical |
| DeepChat is an open-source artificial intelligence agent platform that unifies models, tools, and agents. Prior to v1.0.4-beta.1, An incomplete mitigation for CVE-2025-55733 leaves DeepChat vulnerable to an arbitrary protocol execution bypass (RCE). While the patch correctly restricted api.openExternal() inside the renderer's preload/index.ts script, it structurally neglected to sanitize native Electron pop-up window handlers. An attacker or a compromised AI endpoint returning a Markdown link can trigger a target="_blank" native window interception in tabPresenter.ts, which forwards the malicious URL directly to shell.openExternal(url) and completely bypasses the isValidExternalUrl security boundary. This vulnerability is fixed in v1.0.4-beta.1. | ||||
| CVE-2026-5266 | 1 Wikimedia | 1 Echo | 2026-05-12 | N/A |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation Echo. This vulnerability is associated with program files includes/Api/ApiEchoNotifications.Php. This issue affects Echo: from * before 1.43.7, 1.44.4, 1.45.2. | ||||
| CVE-2026-44658 | 1 Zen-browser | 1 Desktop | 2026-05-12 | 2.4 Low |
| Zen is a firefox-based browser. Prior to 1.19.12b, RSS feed URLs entered by the user are validated to http: or https: in promptForFeedUrl, but item links inside the feed are not subject to the same restriction. The provider maps each RSS/Atom item link into item.url, filters only for presence and date, and returns the item list. The live-folder manager later creates pinned lazy tabs from these values with gBrowser.addTrustedTab(item.url, ...). This vulnerability is fixed in 1.19.12b. | ||||
| CVE-2026-28870 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-05-12 | 5.5 Medium |
| An information leakage was addressed with additional validation. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.4 and iPadOS 26.4, macOS Tahoe 26.4, tvOS 26.4, visionOS 26.4, watchOS 26.4. An app may be able to access sensitive user data. | ||||
| CVE-2026-43108 | 1 Linux | 1 Linux Kernel | 2026-05-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei It looks element length declared in servreg_loc_pfr_req_ei for reason not matching servreg_loc_pfr_req's reason field due which we could observe decoding error on PD crash. qmi_decode_string_elem: String len 81 >= Max Len 65 Fix this by matching with servreg_loc_pfr_req's reason field. | ||||
| CVE-2026-28877 | 1 Apple | 6 Ios And Ipados, Ipados, Iphone Os and 3 more | 2026-05-11 | 5.5 Medium |
| 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.4 and iPadOS 26.4, macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4, visionOS 26.4, watchOS 26.4. An app may be able to access sensitive user data. | ||||
| CVE-2026-28878 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-05-11 | 6.5 Medium |
| A privacy issue was addressed by removing sensitive data. This issue is fixed in iOS 18.7.7 and iPadOS 18.7.7, iOS 26.4 and iPadOS 26.4, macOS Sequoia 15.7.7, macOS Sonoma 14.8.5, macOS Tahoe 26.4, tvOS 26.4, visionOS 26.4, watchOS 26.4. An app may be able to enumerate a user's installed apps. | ||||
| CVE-2025-71255 | 2 Google, Unisoc | 17 Android, Sc7731e, Sc9832e and 14 more | 2026-05-11 | 7.5 High |
| In Modem IMS, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | ||||
| CVE-2026-6392 | 1 Tanium | 1 Threat Response | 2026-05-11 | 2.7 Low |
| Tanium addressed an information disclosure vulnerability in Threat Response. | ||||
| CVE-2025-71251 | 2 Google, Unisoc | 17 Android, Sc7731e, Sc9832e and 14 more | 2026-05-11 | 7.5 High |
| In IMS, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | ||||
| CVE-2026-34086 | 1 Wikimedia | 1 Abusefilter | 2026-05-11 | N/A |
| Vulnerability in Wikimedia Foundation AbuseFilter. This issue affects AbuseFilter: from * before 1.43.7, 1.44.4, 1.45.2. | ||||