CVEs.

Vulnerabilities published in the last two years in software made by the companies on the wall: clients, SDKs, agents and self-hosted editions. A CVE here does not mean the hosted service was affected or breached.

NVD data refreshed 2 h ago

Severity of matching CVEs

CVSS base severity, as scored in NVD

Critical
00%
High
00%
Medium
34100%
Low or not scored
00%
Matching CVEs
34
Last two years
Critical
0
CVSS 9.0 and above
High
0
CVSS 7.0 to 8.9
Known exploited
0
On CISA's KEV list

Matching CVEs published

By month, last two years

Peak 14 · October 2026

  • Total: 34
  • December 2024: 0
  • January 2025: 1
  • February 2025: 0
  • March 2025: 2
  • April 2025: 2
  • May 2025: 0
  • June 2025: 0
  • July 2025: 1
  • August 2025: 0
  • September 2025: 0
  • October 2025: 0
  • November 2025: 0
  • December 2025: 0
  • January 2026: 0
  • February 2026: 2
  • March 2026: 0
  • April 2026: 1
  • May 2026: 0
  • June 2026: 3
  • July 2026: 3
  • August 2026: 1
  • September 2026: 0
  • October 2026: 14
  • November 2026: 4

Most CVEs

In each company's software, last two years

  1. Microsoft 365990
  2. NVIDIA590
  3. GitLab436
  4. Apple (iCloud, App Store and services)348
  5. MongoDB Atlas320
  6. Mattermost Cloud310

Matching CVEs

  1. 5.7Med

    CVE-2026-123082 (opens in a new tab)

    Docker Desktop before version 4.94.0 could write the signed-in user's Docker Hub access token (a JWT) in cleartext to application logs and diagnostics bundles. IPC payloads that were bare JSON strings or arrays were not redacted before logging, and a Docker Desktop component logged the token when it requested it from the backend. An attacker with read access to these files could obtain the token and use it to read and modify the user's Docker Hub data as that user while the token remains valid. Docker Desktop 4.94.0 redacts these payloads. The fix does not rewrite logs written by earlier versi

    Docker· Nov 10, 2026

  2. 4.5Med

    CVE-2026-121520 (opens in a new tab)

    In BuildKit versions prior to v0.34.1, a malicious client with access to the BuildKit control APIs can submit a build request that sets an extended attribute on a file outside the BuildKit state directory. Extended attributes in the trusted. or security. namespaces may also be set, potentially giving a program on the host elevated privileges. This issue affects build services that accept build requests from untrusted users. The issue is fixed in v0.34.1.

    Docker· Nov 3, 2026

  3. 5.6Med

    CVE-2026-121541 (opens in a new tab)

    In Docker Buildx versions v0.19.0 through v0.38.0, an untrusted Bake definition that builds multiple targets together may expose files accessible to the Buildx client without the expected fs.read approval. Under certain conditions, filesystem paths from some targets are not verified against the approved entitlements. Users who run untrusted Bake definitions may be affected. The issue is fixed in v0.38.1.

    Docker· Nov 3, 2026

  4. 6.7Med

    CVE-2026-121522 (opens in a new tab)

    In BuildKit versions v0.26.0 through v0.34.1, a specific build definition that resolves metadata for the same Git source reference twice can cause the BuildKit daemon to panic and crash, interrupting builds handled by that daemon. The issue is fixed in v0.34.2.

    Docker· Nov 3, 2026

  5. 5.7Med

    CVE-2026-114409 (opens in a new tab)

    Docker Desktop before version 4.97.0 could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles due to insufficient IPC payload redaction. An attacker with read access to these files could obtain the credentials. These OAuth tokens are not Docker account tokens. Docker Desktop 4.94.0 and 4.95.0 addressed the known logging paths, but logs containing credentials can remain after upgrading. Docker Desktop 4.97.0 fixes the issue and includes cleanup of existing host logs and crash dumps.

    Docker· Oct 27, 2026

  6. 6.7Med

    CVE-2026-105570 (opens in a new tab)

    Docker Sandboxes compared OAuth token-endpoint hostnames case-sensitively when deciding whether to mask managed credential responses, while request routing treated DNS hostnames case-insensitively. Untrusted code inside a sandbox could use a case-variant hostname to reach the genuine provider endpoint while bypassing response masking. If a user completed the OAuth flow, the provider's access and refresh tokens could be returned unmasked to the sandbox, exposing host-managed credentials.

    Docker· Oct 8, 2026

  7. 5.9Med

    CVE-2026-105452 (opens in a new tab)

    Docker Sandboxes could forward a client-supplied credential alongside a credential injected by the host egress proxy. The proxy removed alternate credentials only when their values matched known sentinel values, so untrusted code in an authorized sandbox could supply an unrecognized credential in another supported authentication header. For affected upstream services, this could authenticate the request to an attacker-controlled account and expose data included in the request.

    Docker· Oct 8, 2026

  8. 5.9Med

    CVE-2026-101998 (opens in a new tab)

    Docker Sandboxes could fail open while masking credentials in protected proxy responses. When a response-body read returned data together with an error, affected handlers could forward unmasked bytes. Code inside an authorized sandbox could use this to recover host-managed OAuth access and refresh tokens or a derived Anthropic API key intended to remain outside the sandbox.

    Docker· Oct 8, 2026

  9. 6.9Med

    CVE-2026-92542 (opens in a new tab)

    The firewall rules which mark VXLAN datagrams for encryption indiscriminately match both authentic VXLAN datagrams sent from the kernel and forged datagrams sent by user processes. Any packet sent from the host network namespace of a Linux Swarm node is encrypted with the overlay-network IPsec parameters which meets the following criteria: - UDP datagram - Destination port is the Swarm data-path port - Datagram starts with a VXLAN header for the VNI of an encrypted overlay network which any running container on the node is connected to

    Docker· Oct 7, 2026

  10. 6.9Med

    CVE-2026-93321 (opens in a new tab)

    A malicious frontend can submit an LLB definition that causes buildkitd to panic and terminate, interrupting all builds running on that daemon.

    Docker· Oct 5, 2026

  11. 5.8Med

    CVE-2026-93315 (opens in a new tab)

    When proxy networking with CA injection is enabled, a build can modify its CA bundle before cleanup. This may cause cleanup to block, operate outside the build rootfs, or fail without failing the build.

    Docker· Oct 5, 2026

  12. 6.9Med

    CVE-2026-103433 (opens in a new tab)

    Docker Buildx Bake does not request the expected fs.read approval for certain filesystem inputs. An untrusted Bake definition can expose a readable file through a pathless secret whose ID is interpreted as a client-side pathname, or consume a local OCI image layout outside the project after entitlement validation checks a different path representation. Users who run untrusted Bake definitions are affected.

    Docker· Oct 5, 2026

  13. 6.0Med

    CVE-2026-93326 (opens in a new tab)

    A build step for a Git source, crafted in a specific way, can bypass some policy validation rules. A malicious build definition can make the repository look like it is coming from a different remote URL than it really is when Git clone is happening. If policy is doing more stricter validation, for example based on commit SHA, commit data, or signatures, then all these validations still apply correctly.

    Docker· Oct 5, 2026

  14. 6.8Med

    CVE-2026-93323 (opens in a new tab)

    The Dockerfile frontend loaded the Dockerfile and .dockerignore files of a build context into memory without a size limit. A build context containing an oversized file could make buildkitd allocate memory proportional to that file, potentially exhausting memory and terminating the daemon, which interrupts other builds on the same instance. Fixed by rejecting such files above 16 MiB.

    Docker· Oct 5, 2026

  15. 6.9Med

    CVE-2026-93322 (opens in a new tab)

    A malicious frontend can submit an LLB definition that causes buildkitd to panic and terminate, interrupting all builds running on that daemon.

    Docker· Oct 5, 2026

  16. 6.0Med

    CVE-2026-93320 (opens in a new tab)

    BuildKit may be tricked into performing file actions with special file inodes where regular files are expected. Special files may block operations or, on rootful workers, allow unintended host device access.

    Docker· Oct 5, 2026

  17. 5.7Med

    CVE-2026-93319 (opens in a new tab)

    A malicious external BuildKit frontend can send requests using the internal API that can create conditions for a data race that can cause the BuildKit daemon to panic.

    Docker· Oct 5, 2026

  18. 5.9Med

    CVE-2026-93317 (opens in a new tab)

    An unauthenticated attacker controlling a registry or OCI-layout blob source could provide blob contents that did not match the claimed digest. The resulting snapshot could be cached under that digest and reused by a later victim build, compromising build-input integrity.

    Docker· Oct 5, 2026

  19. 5.7Med

    CVE-2026-18171 (opens in a new tab)

    Docker Sandboxes (sbx) applies the read-only intent of a runtime host mount to the in-guest container bind only: the underlying virtio-fs host-edge grant is added to the sandbox's policy-share allowlist with no access mode. The directory stays writable at its shared-export path, so unprivileged code inside the sandbox can derive that path and write to a host directory the operator attached read-only.

    Docker· Aug 12, 2026

  20. 6.0Med

    CVE-2026-15792 (opens in a new tab)

    A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.

    Docker· Jul 21, 2026

  21. 6.9Med

    CVE-2026-15789 (opens in a new tab)

    A custom client can produce such an upload request to the BuildKit daemon that files can escape from the BuildKit-controlled state directory. The client needs to have valid permissions to access the BuildKit control API to issue builds, e.g., bypass authentication, etc.

    Docker· Jul 21, 2026

  22. 5.6Med

    CVE-2026-15788 (opens in a new tab)

    BuildKit's cache mount source= selector on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root. A build authored by an untrusted user on a WCOW-configured BuildKit daemon can read arbitrary host files reachable to the BuildKit daemon process.

    Docker· Jul 20, 2026

  23. 5.7Med

    CVE-2026-12539 (opens in a new tab)

    Docker Sandboxes (sbx) blocks ICMP egress with an authorizer applied only at network-creation time, and does not re-apply it to networks rebuilt from disk when the Docker daemon restarts, so a restart-surviving sandbox forwards ICMP to arbitrary hosts. A workload inside a sandbox, which the threat model treats as untrusted, can therefore defeat the documented ICMP egress block to perform network reconnaissance and exfiltrate data over an ICMP covert channel, regardless of the configured allowlist.

    Docker· Jun 18, 2026

  24. 5.7Med

    CVE-2026-12039 (opens in a new tab)

    Docker Sandboxes (sbx) enforces an HTTP/S-only egress allowlist but does not apply it to DNS resolution: the per-network embedded DNS server forwards any queried name to the host resolver whenever the network is internet-connected, without consulting the policy. A workload inside a sandbox, which the threat model treats as untrusted, can therefore encode data into DNS labels for an attacker-controlled domain and exfiltrate it through a DNS covert channel, bypassing the configured allowlist.

    Docker· Jun 18, 2026

  25. 6.1Med

    CVE-2026-41568 (opens in a new tab)

    Moby is an open source container framework. In Docker Engine prior to version 29.5.1, Docker Daemon versions 28.5.2 and prior, and Moby Daemon prior to version 2.0.0-beta.14, a race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem. This issue has been patched in Docker Engine version 29.5.1 and Moby Daemon version 2.0.0-beta.14.

    Docker· Jun 12, 2026

  26. 6.8Med

    CVE-2026-33990 (opens in a new tab)

    Docker Model Runner (DMR) is software used to manage, run, and deploy AI models using Docker. Prior to version 1.1.25, Docker Model Runner contains an SSRF vulnerability in its OCI registry token exchange flow. When pulling a model, Model Runner follows the realm URL from the registry's WWW-Authenticate header without validating the scheme, hostname, or IP range. A malicious OCI registry can set the realm to an internal URL (e.g., http://127.0.0.1:3000/), causing Model Runner running on the host to make arbitrary GET requests to internal services and reflect the full response body back to the

    Docker· Apr 1, 2026

  27. 6.8Med

    CVE-2026-2664 (opens in a new tab)

    An out of bounds read vulnerability in the grpcfuse kernel module present in the Linux VM in Docker Desktop for Windows, Linux and macOS up to version 4.61.0 could allow a local attacker to cause an unspecified impact by writing to /proc/docker entries. The issue has been fixed in Docker Desktop 4.62.0 .

    Docker· Feb 24, 2026

  28. 6.7Med

    CVE-2025-14740 (opens in a new tab)

    Docker Desktop for Windows contains multiple incorrect permission assignment vulnerabilities in the installer's handling of the C:\ProgramData\DockerDesktop directory. The installer creates this directory without proper ownership verification, creating two exploitation scenarios: Scenario 1 (Persistent Attack): If a low-privileged attacker pre-creates C:\ProgramData\DockerDesktop before Docker Desktop installation, the attacker retains ownership of the directory even after the installer applies restrictive ACLs. At any time after installation completes, the attacker can modify the directory AC

    Docker· Feb 4, 2026

  29. 5.2Med

    CVE-2025-6587 (opens in a new tab)

    System environment variables are recorded in Docker Desktop diagnostic logs, when using shell auto-completion. This leads to unintentional disclosure of sensitive information such as api keys, passwords, etc. A malicious actor with read access to these logs could obtain secrets and further use them to gain unauthorized access to other systems. Starting with version 4.43.0 Docker Desktop no longer logs system environment variables as part of diagnostics log collection.

    Docker· Jul 3, 2025

  30. 4.3Med

    CVE-2025-4095 (opens in a new tab)

    Registry Access Management (RAM) is a security feature allowing administrators to restrict access for their developers to only allowed registries. When a MacOS configuration profile is used to enforce organization sign-in, the RAM policies are not being applied, which would allow Docker Desktop users to pull down unapproved, and potentially malicious images from any registry.

    Docker· Apr 29, 2025

  31. 5.2Med

    CVE-2025-3911 (opens in a new tab)

    Recording of environment variables, configured for running containers, in Docker Desktop application logs could lead to unintentional disclosure of sensitive information such as api keys, passwords, etc. A malicious actor with read access to these logs could obtain sensitive credentials information and further use it to gain unauthorized access to other systems. Starting with version 4.41.0, Docker Desktop no longer logs environment variables set by the user.

    Docker· Apr 29, 2025

  32. 4.1Med

    CVE-2025-0495 (opens in a new tab)

    Buildx is a Docker CLI plugin that extends build capabilities using BuildKit. Cache backends support credentials by setting secrets directly as attribute values in cache-to/cache-from configuration. When supplied as user input, these secure values may be inadvertently captured in OpenTelemetry traces as part of the arguments and flags for the traced CLI command. OpenTelemetry traces are also saved in BuildKit daemon's history records. This vulnerability does not impact secrets passed to the Github cache backend via environment variables or registry authentication.

    Docker· Mar 17, 2025

  33. 5.2Med

    CVE-2025-1696 (opens in a new tab)

    A vulnerability exists in Docker Desktop prior to version 4.39.0 that could lead to the unintentional disclosure of sensitive information via application logs. In affected versions, proxy configuration data—potentially including sensitive details—was written to log files in clear text whenever an HTTP GET request was made through a proxy. An attacker with read access to these logs could obtain the proxy information and leverage it for further attacks or unauthorized access. Starting with version 4.39.0, Docker Desktop no longer logs the proxy string, thereby mitigating this risk.

    Docker· Mar 6, 2025

  34. 5.9Med

    CVE-2024-10846 (opens in a new tab)

    The compose-go library component in versions v2.10-v2.4.0 allows an authorized user who sends malicious YAML payloads to cause the compose-go to consume excessive amount of Memory and CPU cycles while parsing YAML, such as used by Docker Compose from versions v2.27.0 to v2.29.7 included

    Docker· Jan 23, 2025

Public information only

Everything on this page was already published by the companies themselves or by public bodies. statuswall gathers it in one place, links every item to its original, and adds nothing from private or leaked sources.

Sources

How fresh it is

  • New and changed CVEs: pulled from NVD every two hours; last run 2 h ago
  • Known-exploited flags: updated from CISA in the same run
  • Window: the last two years; older entries drop off automatically

Source: the U.S. National Vulnerability Database, refreshed daily, with the known-exploited flag from CISA's KEV catalog. Descriptions are NVD's. A CVE is listed under a company when NVD names that company's product as affected, or when the company's own CVE authority assigned it; companies whose names are common words are matched only by explicit rules, so some CVEs will be missing. This product uses NVD data but is not endorsed or certified by the NVD. CVE is a registered trademark of The MITRE Corporation.

statuswall is independent and is not affiliated with, sponsored by or endorsed by any company named here. Company and product names are used only to identify whose public information is being referred to. The information is provided as is, for general reference, with no guarantee that it is complete, current or free of error; it is not security, legal or purchasing advice. Where this page and an official source differ, the official source is right.