CVE-2026-15830

This vulnerability causes a segmentation fault in the GEOS C library when processing deeply nested geometry collections. That matters because the crash happens below Python's exception handling—your Django application's error handlers never get a chance to respond. The process simply terminates, creating an instant service outage rather than a catchable exception. The attack surface is larger than a single endpoint. Five input vectors can trigger this: WKT parsing, WKB parsing, hex-encoded WKB, form fields, and field lookups. An attacker doesn't need to find the one unguarded path—they can use whatever geometry input your application exposes. If you accept geometry data from users through any of these channels, you have a potential denial-of-service vector. The fix must live at the binding layer, not at every individual call site. Adding depth checks to each form field or serializer would be incomplete and create maintenance burden. The proper remediation is Django's GEOS bindings validating geometry depth before passing data to the C library—ideally using functions that return error codes rather than crashing. One operational complication: your Django patch may not be sufficient. GeoDjango wraps GEOS, a separately-versioned C library. If your system runs an older GEOS version with the same underlying unbounded recursion flaw, applying Django's patch alone leaves you vulnerable. Audit your deployed GEOS version independently. For organizations on Django 4.2.x LTS, the "may also be affected" disclosure provides no actionable certainty. You have no official answer on whether this vulnerability applies to your version, leaving a change-management gap: either upgrade production on faith or accept unquantified risk. Treat geometry inputs as untrusted until you can verify your Django and GEOS versions include the fix.

Reviewed through automated stages and approved by a human before publication.