meshio CVE-2026-118589

Exploitation requires an application or workflow to read an attacker-controlled VTK 4.2 file through meshio's VTK Reader (meshio/_vtk_42.py) with a manipulated DIMENSIONS field, in meshio versions up to and including 5.3.5; the oversized DIMENSIONS value drives an uncontrolled memory allocation. Limiting factors: impact is confined to availability (memory exhaustion / process crash) with no confidentiality or integrity effect and no code execution; the target must actually accept and parse untrusted VTK input, so systems that only process trusted/internally-generated meshes are not exposed. No vendor fix is documented, so the only risk reduction currently available is avoiding parsing of untrusted VTK 4.2 files.

This is a medium-severity denial-of-service issue (CVSS 4.0 base 6.9), not a high-impact priority. The supplied CVSS 4.0 vector carries impact ONLY on availability of the vulnerable system (VA:L) with VC:N/VI:N/VA:L and no subsequent-system impact - consistent with the CWE-400 uncontrolled memory allocation and the single 'Denial Of Service' tag; there is no confidentiality or integrity exposure and no code execution. The vendor's priority decision label is 'this_month', i.e. deliberate-but-not-emergency, which aligns with a DoS-only finding. No EPSS score is provided in the input, so exploitation probability cannot be quantified; the CVE is NOT in CISA KEV and there is no confirmed active exploitation. The references include a GitHub issue report (issue 1576) describing the flaw rather than verified working exploit code. One signal to verify: the vector states AV:N (network) and PR:N/UI:N, but the described trigger is parsing a manipulated VTK 4.2 file through meshio's reader - so 'remote/network' realistically means an application that ingests an attacker-supplied file, not a listening network service; verify the actual data path in your deployment. Overall this is a real but low-urgency availability risk, dominated by the fact that no vendor fix yet exists (the project was notified via the issue report but has not responded).

An application or pipeline that uses meshio to parse VTK 4.2 files ingests an attacker-supplied mesh file in which the DIMENSIONS argument has been manipulated. The meshio VTK reader (meshio/_vtk_42.py) performs an uncontrolled allocation based on that value, causing the process to consume excessive memory and crash or become unavailable. A public GitHub issue report describing the problem exists; it is not verified as working exploit code, and exploitation yields only denial of service (no code execution or data compromise).