ReportizFlow
Filtered by vendor
Subscriptions
Total
1711 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-41288 | 1 Watchguard | 1 Single Watchguard Agent | 2026-05-06 | N/A |
| Incorrect permission assignment for a resource in the patch management component of the WatchGuard Agent on Windows allows an authenticated local user to elevate their privileges to NT AUTHORITY\\SYSTEM. | ||||
| CVE-2026-41686 | 1 Anthropics | 1 Anthropic-sdk-typescript | 2026-05-05 | N/A |
| Claude SDK for TypeScript provides access to the Claude API from server-side TypeScript or JavaScript applications. From version 0.79.0 to before version 0.91.1, the BetaLocalFilesystemMemoryTool in the Anthropic TypeScript SDK created memory files and directories using the Node.js default modes (0o666 for files, 0o777 for directories), leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. This issue has been patched in version 0.91.1. | ||||
| CVE-2026-42812 | 1 Apache | 1 Polaris | 2026-05-04 | 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-6499 | 1 Ilm Informatique | 1 Openconcerto | 2026-05-04 | N/A |
| Incorrect Permission Assignment for Critical Resource vulnerability in ILM Informatique OpenConcerto allows Replace Binaries. This issue affects OpenConcerto: 1.7.5. | ||||
| CVE-2025-25373 | 1 Nasa | 1 Core Flight System | 2026-04-30 | 9.8 Critical |
| The Memory Management Module of NASA cFS (Core Flight System) Aquila has insecure permissions, which can be exploited to gain an RCE on the platform. | ||||
| CVE-2025-24203 | 1 Apple | 2 Ipad Os, Macos | 2026-04-28 | 5 Medium |
| The issue was addressed with improved checks. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6, macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.4, visionOS 2.4, watchOS 11.4. An app may be able to modify protected parts of the file system. | ||||
| CVE-2026-41366 | 1 Openclaw | 1 Openclaw | 2026-04-28 | 5.5 Medium |
| OpenClaw before 2026.3.31 contains a local roots self-whitelisting vulnerability in appendLocalMediaParentRoots that allows model-initiated arbitrary host file read. Attackers can exploit improper media parent directory validation to exfiltrate credentials and access sensitive files. | ||||
| CVE-2025-31262 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2026-04-28 | 5.5 Medium |
| A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, tvOS 18.3, visionOS 2.3, watchOS 11.3. An app may be able to modify protected parts of the file system. | ||||
| CVE-2025-24212 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2026-04-28 | 6.3 Medium |
| This issue was addressed with improved checks. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6, macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.4, visionOS 2.4, watchOS 11.4. An app may be able to break out of its sandbox. | ||||
| CVE-2025-43243 | 1 Apple | 4 Macos, Macos Sequoia, Macos Sonoma and 1 more | 2026-04-28 | 9.8 Critical |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to modify protected parts of the file system. | ||||
| CVE-2025-43247 | 1 Apple | 4 Macos, Macos Sequoia, Macos Sonoma and 1 more | 2026-04-28 | 5.5 Medium |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. A malicious app with root privileges may be able to modify the contents of system files. | ||||
| CVE-2025-43268 | 1 Apple | 2 Macos, Macos Sequoia | 2026-04-28 | 7.8 High |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.6. A malicious app may be able to gain root privileges. | ||||
| CVE-2025-43470 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5.5 Medium |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.1. A standard user may be able to view files made from a disk image belonging to an administrator. | ||||
| CVE-2026-2637 | 1 Iboysoft | 2 Iboysoft Ntfs, Ntfs For Mac | 2026-04-27 | 7.8 High |
| iBoysoft NTFS for Mac contains a local privilege escalation vulnerability in its privileged helper daemon ntfshelperd. The daemon exposes an NSConnection service that runs as root without implementing any authentication or authorization checks. This issue affects iBoysoft NTFS: 8.0.0. | ||||
| CVE-2025-52627 | 1 Hcltech | 1 Aion | 2026-04-25 | 5.5 Medium |
| Root File System Not Mounted as Read-Only configuration vulnerability. This can allow unintended modifications to critical system files, potentially increasing the risk of system compromise or unauthorized changes.This issue affects AION: 2.0. | ||||
| CVE-2026-35367 | 1 Uutils | 1 Coreutils | 2026-04-24 | 3.3 Low |
| The nohup utility in uutils coreutils creates its default output file, nohup.out, without specifying explicit restricted permissions. This causes the file to inherit umask-based permissions, typically resulting in a world-readable file (0644). In multi-user environments, this allows any user on the system to read the captured stdout/stderr output of a command, potentially exposing sensitive information. This behavior diverges from GNU coreutils, which creates nohup.out with owner-only (0600) permissions. | ||||
| CVE-2026-35341 | 1 Uutils | 1 Coreutils | 2026-04-24 | 7.1 High |
| A vulnerability in uutils coreutils mkfifo allows for the unauthorized modification of permissions on existing files. When mkfifo fails to create a FIFO because a file already exists at the target path, it fails to terminate the operation for that path and continues to execute a follow-up set_permissions call. This results in the existing file's permissions being changed to the default mode (often 644 after umask), potentially exposing sensitive files such as SSH private keys to other users on the system. | ||||
| CVE-2025-41118 | 1 Grafana | 1 Pyroscope | 2026-04-24 | 9.1 Critical |
| Pyroscope is an open-source continuous profiling database. The database supports various storage backends, including Tencent Cloud Object Storage (COS). If the database is configured to use Tencent COS as the storage backend, an attacker could extract the secret_key configuration value from the Pyroscope API. To exploit this vulnerability, an attacker needs direct access to the Pyroscope API. We highly recommend limiting the public internet exposure of all our databases, such that they are only accessible by trusted users or internal systems. This vulnerability is fixed in versions: 1.15.x: 1.15.2 and above. 1.16.x: 1.16.1 and above. 1.17.x: 1.17.0 and above (i.e. all versions). Thanks to Théo Cusnir for reporting this vulnerability to us via our bug bounty program. | ||||
| CVE-2026-21727 | 1 Grafana | 2 Grafana, Grafana Correlations | 2026-04-24 | 3.3 Low |
| --- title: Cross-Tenant Legacy Correlation Disclosure and Deletion draft: false hero: image: /static/img/heros/hero-legal2.svg content: "# Cross-Tenant Legacy Correlation Disclosure and Deletion" date: 2026-01-29 product: Grafana severity: Low cve: CVE-2026-21727 cvss_score: "3.3" cvss_vector: "CVSS:3.3/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N" fixed_versions: - ">=11.6.11 >=12.0.9 >=12.1.6 >=12.2.4" --- A cross-tenant isolation vulnerability was found in Grafana’s Correlations feature affecting legacy correlation records. Due to a backward compatibility condition allowing org_id = 0 records to be returned across organizations, a user with datasource management privileges could read and permanently delete legacy correlation data belonging to another organization. This issue affects correlations created prior to Grafana 10.2 and is fixed in >=11.6.11, >=12.0.9, >=12.1.6, and >=12.2.4. Thanks to Gyu-hyeok Lee (g2h) for reporting this vulnerability. | ||||
| CVE-2008-0890 | 1 Redhat | 1 Directory Server | 2026-04-23 | N/A |
| Red Hat Directory Server 7.1 before SP4 uses insecure permissions for certain directories, which allows local users to modify JAR files and execute arbitrary code via unknown vectors. | ||||