Description

CDT before 1.4.5 contains an out-of-bounds read vulnerability in the opposedVertexInd() function when constraint edge intersections are computed in floating point and round outside adjacent triangles. Attackers can supply nearly-degenerate constraint edges through geometry data to trigger an out-of-bounds array access that crashes the calling process.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-09-05T12:16:46.490Z",
  "pubdate": "2026-09-05T12:16:46.490Z",
  "executiveSummary": "CDT versions prior to 1.4.5 are susceptible to an out-of-bounds read vulnerability residing within the opposedVertexInd() function.\nThis flaw is triggered during the computation of constraint edge intersections, specifically when floating-point inaccuracies cause calculated coordinates to fall outside the bounds of adjacent triangle structures.\nBy supplying maliciously crafted, nearly-degenerate constraint edge geometry data, an attacker can force the application to perform an out-of-bounds array access.\nThe primary impact of this vulnerability is a denial-of-service condition, resulting in the immediate crash of the calling process.\nThe vulnerability does not require authentication or elevated privileges, provided the attacker can submit arbitrary geometry data to the processing engine.\nThis represents a critical stability risk for applications relying on CDT for constrained Delaunay triangulation, particularly in environments where untrusted geometric input is processed.",
  "technicalDetails": "The vulnerability is localized within the opposedVertexInd() function in the CDT library. The root cause is an improper validation of array indices derived from floating-point geometric calculations.\nIn the context of constrained Delaunay triangulation, the library must frequently identify adjacent vertices when constraint edges intersect triangle boundaries. The algorithm relies on the assumption that geometric intersections will map cleanly to defined vertex indices within the current data structure.\nWhen nearly-degenerate constraint edges—edges with extremely small lengths or specific angular orientations—are processed, floating-point rounding errors can lead to coordinate results that project outside the expected triangle domain.\nThe opposedVertexInd() function uses these computed coordinates to determine an index for an adjacent vertex lookup. Because the floating-point calculation produces a value outside the legitimate range of the array, the function proceeds to perform an out-of-bounds memory read.\nThe attack flow requires the adversary to construct a specific geometry input file or stream containing degenerate constraints designed to maximize rounding discrepancies. Upon ingestion, the library parses these constraints and passes them to the triangulation engine. During the intersection calculation phase, the logic within opposedVertexInd() fails to bounds-check the resulting index before utilizing it to access the internal triangle adjacency array.\nThe subsequent memory access is illegitimate, resulting in the segmentation fault or crash of the host process. There is no evidence currently suggesting that this read primitive can be leveraged for arbitrary code execution, though it consistently facilitates application-level denial-of-service. The vulnerability is triggered automatically upon processing the malicious geometry, requiring no further interaction or authentication by the user."
}