Docker Desktop repairs unsafe build source links

Build information helps explain where an image came from, but the application displaying that information still has to treat its fields as untrusted input. A source link can name the repository associated with a build while also being unsafe for a desktop application to handle. Provenance information does not establish the safety of its own presentation.

Docker Desktop 4.34.3, released on October 9, fixes code execution through image build source information. Docker's CVE-2024-9348 record, published October 16, identifies an unsanitized GitHub source link in the Builds view. The same Desktop release updates NVIDIA Container Toolkit to 1.16.2 for separate container security issues.

I value Docker's repeatable build files because the relationship between inputs and an artifact can be inspected. A source link is useful evidence within that process. It also gives the desktop application another value to interpret, so the code that presents and opens it belongs in the security assessment of the build workflow.

The Builds view is the affected component

Docker's CVE record identifies the Builds view module and Desktop versions before 4.34.3. It lists Windows, macOS and Linux, including x86 and ARM in its platform information. The reported issue therefore concerns the desktop interface that consumes build details, rather than a vulnerability limited to one application image architecture.

The description names the GitHub source link and classifies the weakness as improper input validation. Its impact categories include cross-site scripting and remote code inclusion. Those fields establish the kind of input and consequence involved without supplying a complete exploit sequence.

That limit matters. The record does not identify an exact malicious URL scheme, show a native command line, or publish the sanitization patch. Assigning the defect to one of those implementation details would go beyond the available primary source. The defensible account is that insufficiently constrained source-link input could produce remote code execution through the Builds view.

The source link's normal purpose does not make its supplied value trustworthy. A link can be useful for tracing a build back to a repository while still requiring checks before the receiving application uses it. Establishing where an artifact claims to originate is a different operation from granting that field executable meaning in a desktop context.

The disclosure includes conditions on exploitation

Docker assigns the issue a CVSS 4.0 score of 8.9 with high severity. Its vector records high attack complexity, additional attack requirements, and active user interaction. It also records no required privileges and high effects on confidentiality, integrity and availability.

Those conditions should accompany the code-execution description. The record does not establish that every build automatically executes a payload when its result appears in Desktop. Active interaction is part of Docker's assessment, while the detailed actions satisfying it are not described in the published record.

The record credits Cure53 and marks discovery as external. It lists October 9 as the public date and October 16 as its CVE publication date. These dates explain why the packaged release and the more specific record can describe the same issue at different points in the month.

The solution is to update Desktop to 4.34.3 or later. The record does not provide a configuration workaround for this issue. A claim that disabling an unrelated extension setting or changing a container runtime option repairs the Builds view would therefore need evidence the disclosure does not supply.

For an application that displays build history, the relevant security property is that a source field remains constrained when presented to a user and when used after interaction. Merely confirming that a normal GitHub URL opens correctly would not verify the adverse case. The field's allowed interpretation must remain limited even when its input has been crafted to violate those expectations.

NVIDIA's toolkit update addresses another execution path

Desktop 4.34.3 also includes NVIDIA Container Toolkit 1.16.2. NVIDIA's September security bulletin, published September 25, identifies two vulnerabilities repaired in that toolkit release. They concern specially crafted container images and host filesystem access, rather than links in Desktop's build interface.

CVE-2024-0132 is a time-of-check to time-of-use vulnerability in the toolkit's default configuration. NVIDIA says a crafted image may gain access to the host filesystem. Its listed consequences include code execution and privilege escalation, along with disclosure or modification of data and denial of service.

The underlying class of failure concerns a checked object changing before the operation that uses it. A check can establish that one filesystem state meets a requirement, yet a later operation can use a different state if the implementation does not preserve the relationship. NVIDIA classifies this issue as CWE-367, which identifies that race condition.

The bulletin does not give the full filesystem sequence in its description. This class explains why a prior check can be insufficient, but it does not justify inventing the particular filenames, mount operations or process ordering used by an exploit. NVIDIA establishes image-driven access to the host filesystem under the stated default configuration. That scope distinguishes an implementation defect from a general assertion that any GPU-enabled container can access arbitrary host files through an ordinary supported operation.

CDI is an explicit exception

NVIDIA's description says CVE-2024-0132 does not affect use cases using CDI. That exception is part of the vulnerability's scope. An installed toolkit version alone does not establish that an installation uses the affected path.

The bulletin lists Linux as the platform for the toolkit and GPU Operator entries. Toolkit versions through 1.16.1 are affected, with 1.16.2 supplied as the update. For GPU Operator, it lists versions through 24.6.1 and an updated 24.6.2 release.

Those product versions identify different delivery packages for the repaired component. Desktop's release notes specifically identify its bundled toolkit update. They do not establish the installed GPU Operator version on an unrelated cluster or the package version on another machine running image builds.

The bulletin gives CVE-2024-0132 a CVSS 3.1 score of 9.0 and critical severity. Its vector includes low privileges and required user interaction. That score uses a different CVSS version from Docker's Builds view record, so the two numerical values should not be treated as a direct measurement of relative risk for every installation.

The second toolkit issue has a narrower stated impact

NVIDIA also reports CVE-2024-0133 in toolkit 1.16.1 and earlier. In the default mode, a specially crafted container image can create empty files on the host filesystem. The bulletin identifies data tampering as the impact and again excludes CDI use cases.

Its 4.1 CVSS 3.1 score and medium severity differ from the host-access issue. The vector records low integrity impact without confidentiality or availability impact. Creating empty files is a specific modification capability. The bulletin does not describe that capability as arbitrary replacement of existing host file contents, so the two toolkit vulnerabilities should retain their separate stated consequences.

Both appear in the same security update table, and Desktop's release notes name both identifiers. Updating the bundled toolkit therefore addresses two disclosed conditions. The shared fix version does not imply that they have identical mechanics or equal impact.

NVIDIA credits Andres Riancho, Ronen Shustin and Shir Tamari from Wiz Research for reporting the toolkit issues. Its bulletin separates the potential impacts from the affected-product table. That structure is useful because it keeps the vulnerability description and the package needed to replace the affected implementation independently checkable.

One package repairs different input consumers

The Desktop source-link fix and the toolkit fixes share a release package, but their exposure depends on different operations. One consumes build details in a desktop interface. The other processes an image through an affected GPU container configuration. A source-link repair cannot constrain the toolkit's filesystem race, and a toolkit replacement cannot sanitize a value consumed by the Builds view.

My preference for a minimal final image does not remove either responsibility. Minimal packaging limits what belongs to the application artifact. Desktop still interprets build metadata, while runtime integrations still process the image using their own installed code and permissions.

The October update consequently needs to be understood at the component level. Desktop 4.34.3 supplies the Builds view repair and the toolkit replacement together. The CVE records and NVIDIA bulletin identify the distinct inputs, versions and configuration conditions under which those repaired components matter.