TALOS 2026 2412

A invalid pointer dereference vulnerability exists in the vtkPNGReader::ExecuteInformation functionality of vtk (version(s): 9.6). A specially crafted .png file can lead to a denial of service. An attacker can provide a malicious file to trigger this vulnerability.

Confirmed Vulnerable Versions

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

vtk (version(s): 9.6)

vtk -

7.5 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWE-825 - Expired Pointer Dereference

VTK, or the Visualization Toolkit, is an open-source software system for 3D computer graphics, image processing, and scientific visualization. It provides a large collection of algorithms and data structures for rendering, volume visualization, geometric processing, and interaction.

The interesting part of the crash details is the following : #3 0x00007f00855f1dae in vtkPNGReader::vtkInternals::HandleLibPngError (this= , pngPtr= , infoPtr= , fp=0x515000003000) at /opt/vtk-src/IO/Image/vtkPNGReader.cxx:265

So when looking into the call stack we can observe that vtkPNGReader::vtkInternals::HandleLibPngError is called from vtkPNGReader::ExecuteInformation

Following source extract of vtkPNGReader::ExecuteInformation calling HandleLibPngError LINE70 then continue flow of execution.

Looking into HandleLibPngError source code :

We notice some setjmp instruction in order to call png_destroy_read_struct which will be use in case of error and cause the stack and some registers to be saved for later reuse. Then HandleLibPngError ends and flow continue execution coming back to vtkPNGReader::ExecuteInformation LINE71 to init and read png info through call to png_read_info LINE73 . The issue is happening as vtkPNGReader::ExecuteInformation() crashes with SIGSEGV or SIGABRT when processing a malformed PNG file, as longjmp is triggered by png_read_info . This is happening because the longjmp returns into HandleLibPngError . At the time longjmp fires, HandleLibPngError() has already returned and its stack frame has been overwritten by subsequent calls ( InitLibPngInput , png_read_info ). The fp parameter slot in that dead frame now contains garbage from whatever the last callee placed there. The issue is the fclose(fp) LINE153 as fp is not pointing anymore to the file pointer. The correct approach should have been to implement the setjmp directly into vtkPNGReader::ExecuteInformation .

fclose() dereferences fp as a FILE structure: 1. Reads fp->_IO_file_jumps — the FILE vtable pointer 2. Calls a function pointer from that vtable ( _IO_FINISH )

If the attacker controls the memory region fp points to (e.g., via the PNG file content loaded in heap), they can supply a crafted vtable and redirect execution.

glibc ≥ 2.24 includes _IO_vtable_check() which validates that the vtable is within the expected range. This converts some exploitation attempts into SIGABRT instead of arbitrary code execution. However, this mitigation is absent on glibc <= 2.24 and on other C libraries.

Vendor Response (CVE-2026-41216)

Vendor Link:

2026-06-23 - Vendor Notification 2026-06-25 - Vendor Acknowledged 2026-06-30 - 7-Day 2026-07-02 - Follow-Up Sent 2026-07-07 - Vendor Replied, Dev Team Working 2026-08-07 - 45-Day 2026-08-22 - 60-Day 2026-09-15 - Follow-Up Sent 2026-09-21 - 90-Day 2026-09-23 - Vendor Replied, Dev Team Working 2026-10-12 - Advised Vendor Cisco Will Publish And Close Out

Emmanuel Tacheau of Cisco Talos