🔴CVE-2026-14266

Overview

This advisory addresses a known security vulnerability identified in a third-party component used within DPGW. Unlike most advisories in this tracker, the affected component is not a bundled Java dependency but the external 7-Zip binary that DPGW invokes on the host/container to extract user-uploaded archives.

Vulnerability Details

  • CVE ID: CVE-2026-14266
  • Dependency Name: 7-Zip (7z / 7zip system binary; installed in the DPGW container via dnf install 7zip from EPEL)
  • Affected Version of Dependency: 7-Zip 21.07 – 26.01 (fixed in 26.02)
  • Severity Score: ZDI/CNA 7.0 High (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)

Affected Versions of DPGW

  • <= 1.14.08-REL (container bundles the 7zip binary and uses it for archive import)
  • <= 1.13.29-REL (container bundles the 7zip binary and uses it for archive import)

The 1.12 and 1.11 branches do not ship the 7-Zip-based archive extraction feature (SevenZipExtractor / ImportInput7Zip / the @sevenzip-command parameter are absent) and do not bundle the 7zip binary in their container images. Those branches are not affected.

Risk Assessment & Applicability

Usage
DPGW uses the external 7-Zip binary to unpack archives uploaded by users during DICOM import. The upload endpoint /private/dicom-import (DicomImportServlet) accepts zip, 7z, rar and iso archives (including password-protected ones); when the @sevenzip-command global parameter is set (default 7z), SevenZipExtractor shells out to the binary as 7z x -y -o<dir> [-p<password>] <file> (ProcessBuilder) and the archive contents are extracted server-side. The binary is provided by the host system — in the standard container image it is installed with dnf install -y ... 7zip (from EPEL); in bare-metal deployments the operator installs the 7zip OS package (documented in the Release Notes).

Analysis
CVE-2026-14266 is a heap-based buffer overflow in 7-Zip’s XZ decompression code. When 7-Zip decodes crafted XZ-compressed chunked data, it corrupts the heap and may execute arbitrary code in the context of the process performing the extraction. The vulnerability is triggered purely by extracting a malicious archive — no separate configuration or feature toggle is required beyond decompression itself. It affects every 7-Zip release from 21.07 through 26.01 and is fixed in 26.02.
DPGW exercises exactly this code path: it invokes the system 7-Zip binary to extract archive content supplied by a user. An attacker who can reach the DICOM import feature can therefore submit a crafted archive that causes code execution as the DPGW service account (uid 1000 inside the container).
The attack is gated by DPGW’s authorization model. The /private/dicom-import endpoint requires an authenticated principal holding ROLE_LOCDATA_IMPORT together with one of the import sub-roles (ROLE_LOCDATA_IMPORT_ARCHIVE, ROLE_LOCDATA_USER_READ or ROLE_LOCDATA_STATION_READ). It is not reachable anonymously. However, once an authorized user (or a stolen/forged session of one) uploads the archive, extraction runs automatically server-side with no further interaction, so the practical scenario is a malicious or compromised authorized user, or an authorized user tricked into importing an attacker-supplied archive.

Status
Affected

Severity Score in the context of DPGW: 7.5 High CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
The base ZDI score assumes a desktop scenario (a victim opens a local malicious file: AV:L, PR:N, UI:R). In DPGW the picture differs: the payload is delivered over the network by an authenticated upload (AV:N), the attacker must hold import privileges (PR:L), and extraction is triggered server-side automatically without a separate victim interaction (UI:N). Attack complexity remains high (AC:H) because reliable heap-overflow exploitation is difficult, and the impact remains High/High/High because successful exploitation yields code execution as the DPGW service account.

Impact on DPGW

Successful exploitation would allow an authenticated user with DICOM-import privileges to achieve remote code execution as the DPGW service account inside the container, by uploading a crafted archive. This could lead to:

  • arbitrary code execution in the DPGW process context (uid 1000);
  • read/write access to storage and data reachable by the DPGW service account;
  • potential lateral movement or service compromise depending on the deployment.

Deployments that do not grant import roles to untrusted users, and that keep the web tier reachable only from trusted networks, have a correspondingly reduced exposure — but any authorized importer able to reach the endpoint can trigger the vulnerable code path.

Remediation & Mitigations

Scheduled fix
he fix is an update of the external 7-Zip binary to 26.02 or later; no DPGW Java code change is required. For the standard container image this means rebuilding the DPGW image once the base repositories (EPEL) provide 7-Zip 26.02+, so that dnf install 7zip pulls the patched binary. This will roll into the maintained 1.13 and 1.14 branches as part of routine image maintenance.

  • 1.14 branch — image rebuild bundling 7-Zip 26.02+
  • 1.13 branch — image rebuild bundling 7-Zip 26.02+

User Actions

  • Containerized deployments: upgrade to a DPGW image built with 7-Zip 26.02 or later. Operators can check the bundled version by running 7z (or the value of @sevenzip-command) inside the container and confirming the reported version is 26.02+.
  • Bare-metal deployments: update the host 7zip OS package to 26.02 or later.
  • Interim mitigation: restrict DICOM-import roles (ROLE_LOCDATA_IMPORT and the import sub-roles) to trusted users only, and/or unset the @sevenzip-command global parameter to disable server-side archive extraction until the binary is patched (this disables import of 7z/rar/iso and password-protected archives).