What is the CVSS score of CVE-2026-22879?

CVE-2026-22879 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

Which versions of VTK-DICOM are affected by CVE-2026-22879?

A heap-based buffer overflow in the vtk-dicom library (CVSS 8.1) enables remote code execution through maliciously crafted DICOM medical image files, directly threatening healthcare IT infrastructure…

How to fix or mitigate CVE-2026-22879?

Within 24 hours: Inventory all systems running vtk-dicom and restrict DICOM file ingestion to validated, trusted sources only; enable detailed logging on DICOM processing endpoints. Within 7 days: Implement network segmentation to isolate DICOM servers from mission-critical systems; deploy input validation controls to reject malformed DICOM elements. Within 30 days: Monitor vendor advisories for patch availability; evaluate alternative DICOM libraries or upgrade to patched vtk-dicom version when released.

VTK-DICOM CVE-2026-22879

EUVD-2026-39582 HIGH

Improper Validation of Array Index (CWE-129)

2026-06-25 talos

GHSA-prp5-qv62-frpc

Buffer Overflow Suse Vtk

8.1

CVSS 3.1 · Vendor: talos

Severity by source

Vendor (talos) PRIMARY

8.1 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.5 HIGH

Attacker-supplied DICOM input typically requires a user to open the file in viewer use (UI:R); heap grooming makes it AC:H; no auth needed (PR:N); full memory-corruption impact yields C/I/A:H.

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SUSE

HIGH

qualitative

Primary rating from Vendor (talos).

CVSS VectorVendor: talos

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 25, 2026 - 22:36 vuln.today

DescriptionCVE.org

vtk vtk-dicom vtkDICOMItem::NewDataElement heap-based buffer overflow vulnerability

AnalysisAI

Heap-based buffer overflow in the vtk-dicom library's vtkDICOMItem::NewDataElement routine allows remote attackers to corrupt heap memory and potentially achieve arbitrary code execution by supplying a maliciously crafted DICOM data element. The flaw affects vtk-dicom (a DICOM I/O module commonly paired with the Visualization Toolkit) and was reported by Cisco Talos (TALOS-2026-2366), carrying a CVSS 3.1 base score of 8.1 with full confidentiality, integrity, and availability impact. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV.

Technical ContextAI

VTK-DICOM is an add-on library to the Visualization Toolkit (VTK) that parses, reads, and writes DICOM medical imaging objects (data sets, series, and pixel data). The vulnerability resides in vtkDICOMItem::NewDataElement, the code path responsible for allocating and populating a new DICOM data element while parsing a sequence/item structure. The CWE-129 classification (Improper Validation of Array Index) indicates the root cause is an out-of-bounds index or length value taken from attacker-controlled DICOM fields that is used without proper bounds checking, leading to a heap write outside the allocated buffer. Because DICOM tag/length encoding is fully attacker-controlled in a malicious file or network stream, a forged element length or count can drive the allocation and copy logic out of bounds.

RemediationAI

No vendor-released patch identified at time of analysis; consult the Talos advisory (https://talosintelligence.com/vulnerability_reports/TALOS-2026-2366) and the upstream vtk-dicom project for a fixed release and upgrade to it once published, then rebuild any downstream applications that statically link or vendor the library. As compensating controls until a patch is confirmed, restrict and validate DICOM input: only accept DICOM objects from trusted sources, place any network-facing DICOM receiver/ingest service behind authentication and network ACLs that limit which hosts may send DICOM, and run the parsing process in a sandbox or low-privilege service account so a heap corruption does not yield host-level code execution. If DICOM ingestion is not required, disable or remove the vtk-dicom parsing path; the trade-off of source-whitelisting and sandboxing is reduced interoperability and added latency for legitimate imaging workflows.