CVE-2025-15647 in CDT
Summary
by MITRE • 09/05/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The identified vulnerability resides within the CDT library prior to version 1.4.5, specifically affecting the opposedVertexInd() function which is responsible for computing geometric relationships during triangulation processes. This flaw manifests as an out-of-bounds read error that occurs under specific computational conditions involving floating-point arithmetic and constraint edge intersections. The core technical issue arises when the calculation of intersection points between constraint edges results in coordinates that fall outside the expected adjacent triangles due to rounding errors inherent in floating-point representation. In robust geometric algorithms, such boundary cases must be handled with precise tolerance checks or alternative logic paths; however, this implementation fails to account for these edge cases adequately, leading directly to memory safety violations when the algorithm attempts to access array indices based on incorrect vertex identification.
From a technical perspective, this vulnerability is classified as CWE-125, which denotes an out-of-bounds read operation. The attack vector involves supplying nearly-degenerate constraint edges through geometry data inputs. A degenerate triangle or edge in computational geometry refers to shapes with zero area or collinear vertices that create ambiguous geometric states. When attackers craft input datasets containing such pathological geometries, the floating-point rounding errors cause the opposedVertexInd() function to miscalculate vertex indices. Consequently, the application attempts to read from memory locations outside the bounds of allocated arrays. This behavior is particularly dangerous because it does not necessarily require complex exploitation techniques; simply providing malformed geometric data can trigger the fault immediately upon processing.
The operational impact of this vulnerability primarily centers on availability and potential information disclosure through crash analysis. The immediate consequence is a denial of service, as the out-of-bounds read triggers an exception or segmentation fault that crashes the calling process. For applications relying on CDT for mesh generation, pathfinding, or spatial analysis, such crashes can lead to significant downtime and data loss if state recovery mechanisms are not robustly implemented. Furthermore, depending on the memory layout of the host application, reading out-of-bounds might expose sensitive information stored in adjacent memory regions, although the primary risk described is the stability failure. In security frameworks like MITRE ATT&CK, this behavior aligns with techniques related to resource exhaustion or denial of service via software faults, often categorized under initial access vectors if exploited within a larger attack chain involving untrusted data ingestion.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The most effective remediation is upgrading the CDT library to version 1.4.5 or later, where this specific logic error in opposedVertexInd() has been addressed with proper boundary checks and tolerance handling for floating-point comparisons. For systems unable to upgrade immediately, developers should implement input validation layers that filter out nearly-degenerate geometries before they reach the triangulation engine. This includes checking triangle areas against a minimum epsilon value and validating edge intersections for numerical stability. Additionally, employing memory-safe languages or runtime protections such as Address Sanitizer during development can help identify similar issues in other parts of the codebase. Regular security audits focusing on geometric computation libraries are recommended to ensure that floating-point precision issues do not lead to broader system vulnerabilities.