CVE-2026-77387: 
Python vulnerability analysis and mitigation

CVE-2026-77387 is a Regular Expression Denial of Service (ReDoS) vulnerability in the geopy Python geocoding library affecting all versions up to and including 2.4.1. The flaw exists in geopy.Point and Point.from_string(), which can consume excessive CPU time when processing long, malformed coordinate strings due to catastrophic backtracking in the POINT_PATTERN regular expression. Geocoder reverse methods called with string inputs also reach the vulnerable code path. The vulnerability was reported on June 30, 2026, patched on July 10, 2026, and the security advisory was published July 12, 2026. It carries a CVSS v3.1 base score of 4.0 (Medium) (GitHub Advisory).

The root cause is classified as CWE-1333 (Inefficient Regular Expression Complexity). The POINT_PATTERN regex in geopy/point.py begins with .*? (to allow coordinates embedded after leading text) and matches whitespace in several overlapping places, creating overlapping quantifiers that trigger quadratic backtracking on adversarial inputs. An attacker-supplied string such as '<' + ' ' * 3000 + 'X' — a leading non-word character followed by thousands of spaces and a non-matching terminator — causes the regex engine to backtrack extensively, consuming approximately 206ms per request compared to ~0.01ms for a normal input. The numeric Point constructor is unaffected; only the string-parsing path via Point.__init__() and Point.from_string() is vulnerable (GitHub Issue, GitHub Advisory).

Successful exploitation causes a denial of service against any web application that passes user-controlled strings to geopy.Point() or Point.from_string() without input length validation. Each adversarial request blocks a server thread for approximately 200ms, and 100 concurrent malicious requests can exhaust a thread pool for roughly 20 seconds, rendering the service unresponsive to legitimate users. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Issue, GitHub Advisory).

A proof-of-concept Python script demonstrating the timing difference between normal and adversarial inputs is publicly available in the GitHub issue report (GitHub Issue). The EPSS score is 0.0, and there is no evidence of in-the-wild exploitation or inclusion in the CISA KEV catalog. No authentication is required to exploit the vulnerability, but the target application must accept user-supplied coordinate strings and pass them directly to the vulnerable API without length validation. The NVD SSVC assessment classifies exploitation status as "poc" and automatable as "no" (Feedly).

1. Reconnaissance: Identify a web application using geopy ≤ 2.4.1 that accepts user-supplied location or coordinate strings (e.g., GET /api/nearby?location=...), as geopy has approximately 2 million monthly PyPI downloads.
2. Craft adversarial payload: Construct a malformed coordinate string designed to trigger catastrophic backtracking: adversarial = '<' + ' ' * 3000 + 'X'. URL-encoded form: location=%3C%20%20%20...%20X.
3. Send malicious request: Submit the crafted payload to the vulnerable endpoint, e.g., GET /api/nearby?location=%3C%20%20%20...%20X. The application passes the string to geopy.Point(location) as per standard usage.
4. Trigger regex backtracking: The POINT_PATTERN regex in geopy/point.py enters quadratic backtracking on the input, blocking the server thread for approximately 200ms per request.
5. Amplify with concurrent requests: Send 100 or more concurrent requests with the adversarial payload to exhaust the server's thread pool, causing the service to become unresponsive to legitimate traffic for approximately 20 seconds or more (GitHub Issue).

• Network: Repeated HTTP requests to location/geocoding API endpoints (e.g., /api/nearby, /api/geocode) with unusually long query parameter values (>256 characters) containing leading special characters (<, >) followed by large amounts of whitespace.
• Logs: Web server access logs showing high-volume requests to coordinate-parsing endpoints with URL-encoded payloads containing %3C (less-than sign) followed by many %20 (space) sequences; elevated request latency or timeout errors on geocoding endpoints.
• Process: Python worker processes showing sustained high CPU utilization during request processing; thread pool exhaustion indicators in application performance monitoring (GitHub Issue).

Upgrade geopy to version 2.5.0 or later, which fixes the issue by rejecting any coordinate string longer than 256 characters before applying the regex, raising a ValueError for oversized inputs (geopy Release, Fix Commit). As a workaround for applications that cannot immediately upgrade, enforce a maximum length limit (e.g., 256 characters) on coordinate strings before passing them to geopy.Point() or Point.from_string(), and optionally apply a character class pre-check to reject strings containing unexpected characters. Additionally, implement rate limiting on geocoding API endpoints to reduce the impact of repeated malicious requests (GitHub Advisory).