Traccar CVE-2026-52852

Requires an authenticated Traccar account (PR:L) that holds BOTH the permission to manage groups AND the permission to request reports; with those, the attacker creates a cyclic group-parent hierarchy and requests a trips or stops report for a device within it. Exploitation is limited to Traccar versions prior to 6.14.0 and to the reporting/storage-backed lookup path (TripsConfig via ReportUtils.slowTripsAndStops) - the position-ingestion cache-backed path is explicitly outside confirmed scope. No user interaction from a victim is needed (UI:N), and the loop persists after client disconnect, so a single malicious low-privileged user can degrade service; the main limiting factor is the specific group-management + reporting privilege combination.

This is a genuine but moderate, authentication-gated denial-of-service issue, not a critical remote takeover. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) is internally consistent and I agree with it: the impact is availability-only (C:N/I:N/A:H), matching the description of a non-terminating loop that pins a Jetty worker and can exhaust the web/API worker pool. CWE-674 (uncontrolled recursion/loop) is well-chosen - the fix commit confirms the root cause by adding a MAX_GROUP_DEPTH=3 cap in AttributeUtil.lookup and explicit cycle detection in BaseObjectResource.update. Exploitation probability signals are muted: no EPSS score, no CISA KEV listing, and no public exploit code identified, so exploitation status is 'no public exploit identified at time of analysis' - though the GitHub advisory plus fix diff make the mechanism near-trivial to reproduce. The real limiter is privilege: PR:L requires an authenticated account that specifically holds BOTH group-management and report-request permissions, so this is an insider/abused-account risk rather than an anonymous internet threat. One tagging conflict to flag: the input Tag 'Information Disclosure' contradicts the CVSS vector (C:N) - this is a pure DoS, not an info-disclosure flaw. Net: patch on a normal cadence; prioritize higher for multi-tenant Traccar deployments where lower-trust users hold group/report permissions.

An authenticated Traccar user who can manage groups sets a group's parent to form a cycle in the group-parent hierarchy (permitted by GroupResource), then requests a trips or stops report for a device inside that hierarchy. AttributeUtil.lookup walks the parent chain with no cycle detection, visited set, or depth limit, so the storage-backed lookup never returns and pins a Jetty worker thread at high CPU even after the client disconnects; repeating the request across several sessions exhausts the worker pool and takes the web/API offline. No public exploit code exists, but the GitHub advisory and fix commit make the technique easy to reconstruct.