LatePoint CVE-2026-18441

Exploitable ONLY when the site is configured with customer authentication disabled (guest checkout enabled) - this is the decisive limiting factor; sites requiring customer login for booking are not exposed via the unauthenticated path. The specific vulnerable feature is the set_customer_object step handler (steps_controller.php), which trusts a user-controlled customer[id] key without ownership/identity validation. No user interaction is needed and the attack is network-remote and automatable by simple integer iteration. Impact is confined to reading customer PII (first name, last name, email, phone); no write, code execution, or availability effect.

This is a genuine but bounded privacy risk, not a critical-severity emergency. The vendor CVSS of 4.3 (medium) reflects confidentiality-only impact (C:L, I:N, A:N) limited to PII fields. Note a signal conflict worth flagging: the vendor vector carries PR:L (authenticated) while the description explicitly states 'unauthenticated attackers' and the exploit gate is guest-checkout/anonymous booking - my independent read is PR:N, which would raise the base score to ~5.3. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data, so this maps to 'no public exploit identified at time of analysis.' The four trac source-line references (steps_controller, steps_helper, model.php, latepoint.php) plus a Wordfence threat-intel entry confirm the code path is real and well-characterized. Realistic priority: moderate - the IDOR is trivially automatable (integer iteration of customer[id]) and unauthenticated where guest checkout is on, making mass PII harvesting feasible, but there is no code execution, integrity, or availability impact. Prioritize patching for sites running guest checkout; deprioritize where customer authentication is enforced.

On a LatePoint booking site with guest checkout enabled, an attacker enters the booking flow and issues repeated requests to the set_customer_object step, incrementing the customer[id] parameter. Because the user-controlled key is not validated against the requester's identity, each response leaks another customer's first name, last name, email, and phone number, letting the attacker script a full enumeration of the customer database. No public exploit code is identified, but the attack is a straightforward scripted loop.