CVE-2026-52837: Unauthenticated PII Leakage in Easy!Appointments Booking Reschedule Endpoint

Easy!Appointments uses a Model-View-Controller (MVC) architecture built on top of the PHP programming language and CodeIgniter framework. The primary vulnerability is located within the scheduling and rescheduling workflow, specifically handled by the booking front-end controller. This specific interface acts as an unauthenticated gateway, allowing external clients or guest users to manage, confirm, or modify scheduled appointments without requiring a persistent login session or prior administrative validation. Consequently, any exposed route within this component is highly accessible to remote actors, creating a significant attack surface if input handling or access controls are not rigorously enforced.\n\nThe vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-639 (Authorization Bypass Through User-Controlled Key). The flaw is exposed when an unauthenticated actor accesses the rescheduling interface by supplying a valid 12-character alphanumeric appointment token via the URL path. Instead of restricting the response to booking metadata, the backend retrieves the entire user profile from the database and inserts it into the HTML body. This behavior bypasses traditional authorization checks, allowing any anonymous client who obtains a valid scheduling hash to read the complete database profile of the linked customer, effectively exposing personal data without verification.\n\nFrom an architectural perspective, this data leakage represents a failure to separate data representation from the underlying database models. In secure software designs, only explicitly defined data views should be passed to user-facing templates. By contrast, the vulnerable controller directly extracts raw rows from the customer table and forwards them to the template engine. When the template engine serializes this raw model output into inline client-side variables, it breaks the principle of least privilege. The resulting leakage exposes not only standard contact information but also secondary attributes, metadata, and internal directory configurations that were never intended for public presentation.\n\nThe attack vector is straightforward and operates entirely over the network via standard HTTP GET requests. Because the endpoint is designed to be accessible to guest users to facilitate quick appointment modifications, there are no built-in rate-limiting, session-handling, or multi-factor authentication steps to block unauthorized access. An attacker who is able to capture or guess a single valid appointment token can fetch the associated customer record with absolute reliability and zero user interaction, making this a critical information disclosure vector for any target organization deploying the vulnerable software versions.

The root cause of CVE-2026-52837 is a database-to-view sanitization failure inside application/controllers/Booking.php within the Booking::index() method. When a client initiates a request to reschedule an appointment, the controller parses the 12-character hash directly from the URL route. The application uses this token to query the ea_appointments database table to retrieve the specific booking details. Once the appointment record is found, the system extracts the associated customer identifier (id_users_customer) to fetch the corresponding customer record from the ea_users database table.\n\nAfter the controller retrieves the customer record via the $this->customers_model->find() method, the application stores the raw database row as a PHP array. In the vulnerable implementation, the controller directly assigns this unfiltered array to the view variables array without running any sanitization, filtering, or key-whitelisting routines. When the PHP engine compiles the view template, it serializes this complete array structure directly into a global JavaScript object called vars embedded in the raw HTML response. This design flaw ensures that all database columns associated with the customer's record are transmitted to the user's web browser as plaintext.\n\nAn inspection of the database schema for the ea_users table reveals that it stores both public details and highly sensitive metadata. The unconstrained serialization of this database row causes the immediate exposure of personal identifiers, including email addresses, physical mailing addresses, telephone numbers, user-defined custom attributes, and local timezone configurations. Most critically, for enterprise deployments integrating centralized authentication, the table can store sensitive directory information, such as LDAP Distinguished Names (DNs). The exposure of LDAP DNs is a severe security issue, as it reveals the internal hierarchy, organizational units, and domain controllers of the target enterprise directory.\n\nWhile the vulnerability requires a valid 12-character appointment hash to execute, the application does not treat this hash with the level of confidentiality required for a primary authorization key. The 12-character token is frequently leaked through multiple insecure channels, such as in the bodies of confirmation and reminder emails, browser cache histories, and outbound HTTP Referer headers when clicking external maps or service links. Furthermore, administrative users and system operators can view these hashes in plain text in their management panels, creating multiple opportunities for an attacker to capture active tokens and subsequently trigger the backend data disclosure routine.

To understand the vulnerability, it is necessary to examine the data flow within the controller before the patch was applied. In all versions up to and including 1.5.2, the controller logic in application/controllers/Booking.php queries the model and immediately assigns the returned dataset to the view container. The following code snippet shows the vulnerable path where the customer array is mapped directly:\n\nphp\n// Vulnerable implementation in Version <= 1.5.2\n$customer = $this->customers_model->find($appointment['id_users_customer']);\n// The raw, unfiltered database array is assigned to the view data structure\n$view_data['customer_data'] = $customer;\n\n\nBecause no intermediary cleaning occurs, this raw array contains all columns from the database, which are subsequently rendered inside the view using json_encode() within an inline script block, writing the sensitive data directly into the DOM of the output page.\n\nThe vulnerability was addressed in commit 40bb0b31b531540bc9006efce4220eb0a437ed2b, which was integrated into the official 1.6.0 release. The developer introduced a data filtering step directly after the database lookup by utilizing a model-level helper method named only(). The following snippet highlights the specific changes made in the patched controller file /application/controllers/Booking.php:\n\nphp\n// Patched implementation in Version 1.6.0\n$customer = $this->customers_model->find($appointment['id_users_customer']);\n// The only() method restricts the customer array keys to a predefined whitelist\n$this->customers_model->only($customer, $this->allowed_customer_fields);\n\n\nBy invoking this method, the controller filters the $customer array, removing any keys that are not explicitly defined in the $this->allowed_customer_fields array property before the template engine can access the data.\n\nFrom a code review perspective, security engineers must analyze how PHP handles array manipulation in this specific patch to verify its resilience. In PHP, arrays are passed by value by default. If the helper method only() in the customer model does not accept its first parameter as a reference (e.g., public function only(array &$array, array $keys)), the operation will only modify a local copy within the function's scope, leaving the original $customer array inside the controller completely untouched. If this pass-by-reference notation is omitted or modified in future releases, the filtering will fail quietly, causing the application to silently revert to exposing the full, unfiltered database row to the template engine.\n\nAdditionally, the security margin of this fix is heavily bound to the definition of the $this->allowed_customer_fields property. If this property is configured to include sensitive fields such as email, phone_number, or address to satisfy specific user-interface requirements, those fields will continue to be serialized and sent to unauthenticated clients. To establish a secure-by-default posture, the whitelist must be strictly limited to the minimum set of non-sensitive attributes needed for the rescheduling interface, such as the user's first name, last name, and numeric ID, while completely excluding all contact, configuration, or identity directory paths.

Exploiting CVE-2026-52837 is straightforward and does not require active session cookies, cross-site request forgery tokens, or administrative credentials. The single prerequisite is the acquisition of a valid 12-character alphanumeric appointment_hash associated with an active booking. In practice, this hash can be gathered by intercepting plain-text email notifications, examining web proxy logs, reviewing local browser history on shared terminals, or capturing outbound HTTP Referer headers when a user clicks links to external map or calendar providers from the rescheduling screen.\n\nOnce a valid 12-character hash is captured, the attacker can execute the exploit by crafting a standard HTTP GET request targeting the reschedule endpoint of the vulnerable Easy!Appointments instance. This request does not require any specialized user-agent headers, cookies, or payloads, making it virtually identical to legitimate user traffic. The request is structured as follows:\n\nhttp\nGET /index.php/booking/reschedule/a7b9c1d3e5f7 HTTP/1.1\nHost: target-appointments.local\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nConnection: close\n\n\nUpon receiving this request, the web server processes the route and responds with an HTTP 200 OK status, returning the compiled HTML document containing the inline variables block.\n\nAfter receiving the HTTP response, the attacker parses the HTML body to extract the serialized JavaScript variables. This process can be easily automated using simple command-line tools like curl and grep, or more robust Python script parsers. Within the output, the attacker targets the vars script block, which contains the complete, unsanitized JSON serialization of the user record. An example of the leaked customer object extracted from the page source is illustrated below:\n\njson\n{\n \"id\": \"42\",\n \"first_name\": \"John\",\n \"last_name\": \"Doe\",\n \"email\": \"johndoe@victim-corp.com\",\n \"phone_number\": \"+1-555-0199\",\n \"address\": \"123 Secure Lane, Security City\",\n \"notes\": \"VIP customer. LDAP DN: cn=johndoe,ou=users,dc=victim,dc=com\",\n \"timezone\": \"America/New_York\",\n \"custom_fields\": \"{\\\"internal_id\\\":\\\"secret-999\\\"}\"\n}\n\n\nThis payload provides the attacker with immediate, high-fidelity personal data without generating any security exceptions or application errors.\n\nBelow is a sequence diagram illustrating the lifecycle of the exploit from hash acquisition to data extraction:\n\nmermaid\nsequenceDiagram\n autonumber\n actor Attacker\n participant ExternalServices as \"External Link / Referer\"\n participant Server as \"Easy!Appointments Server\"\n participant DB as \"Database\"\n\n ExternalServices->>Attacker: Leak 12-char appointment hash\n Attacker->>Server: GET /index.php/booking/reschedule/{hash}\n Server->>DB: Query appointment & customer records\n DB-->>Server: Return full 'ea_users' row\n Server->>Server: Inline full row into HTML template\n Server-->>Attacker: HTTP 200 OK (HTML with raw JSON variables)\n Note over Attacker: Extracts email, phone, address, & LDAP DN\n

The CVSS v4.0 score for CVE-2026-52837 is calculated as 6.9, which places it in the Medium severity tier. The attack vector is rated as Network, and the attack complexity and requirements are both rated as Low, signifying that any remote actor can trigger the leak without specialized conditions. The confidentiality impact is rated as Low (VC:L) because, while sensitive personally identifiable information is disclosed, the leak is restricted to a single customer record associated with the supplied hash, rather than allowing an attacker to dump the entire user database in a single query.\n\nDespite the Low confidentiality rating in CVSS, the operational impact of this vulnerability is significant for organizations that handle sensitive user data. Because the leaked records contain physical addresses, phone numbers, email addresses, and names, an attacker can use this data to perform highly targeted social engineering and spear-phishing campaigns. By referencing specific appointment times, locations, and provider details, the fraudulent communications can achieve a high degree of credibility, increasing the success rate of subsequent phishing, credential harvesting, or business email compromise attacks.\n\nFurthermore, the inclusion of internal LDAP Distinguished Names (DNs) and administrative notes within the leaked database row provides adversaries with valuable internal network intelligence. Exposure of LDAP paths allows an attacker to map out the target company's Active Directory structure, user groups, and domain architecture. This internal intelligence significantly reduces the reconnaissance phase of a broader corporate network intrusion, allowing actors to craft highly tailored credential-stuffing or password-spraying attacks against specific directory structures.\n\nAccording to threat intelligence data, the Exploit Prediction Scoring System (EPSS) score is 0.00352, indicating a very low likelihood of widespread exploit automation in the wild over the next 30 days. This vulnerability is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog, and there is no evidence indicating that this specific flaw has been utilized in ransomware operations. The risk remains primarily characterized by targeted, opportunistic attacks against specific self-hosted Easy!Appointments deployments.

The primary and recommended remediation for CVE-2026-52837 is to upgrade the Easy!Appointments installation to version 1.6.0 or later. This release includes the official security patch that enforces model-level array filtering, preventing the serialization of sensitive database columns to client-side views. Before applying the upgrade, administrators should perform a full backup of the web application directory and the underlying MySQL/MariaDB database to prevent any data loss or configuration corruption during the update process.\n\nIn environments where an immediate version upgrade is not feasible due to legacy system dependencies or change-management policies, system administrators must apply a manual code hotfix. This hotfix involves directly modifying /application/controllers/Booking.php to truncate the $customer array before it is parsed by the view template. To apply this change, locate the customer retrieval block near line 280 and replace the raw assignment with a strict array filtering routine:\n\nphp\n$customer = $this->customers_model->find($appointment['id_users_customer']);\nif (method_exists($this->customers_model, 'only')) {\n $this->customers_model->only($customer, ['id', 'first_name', 'last_name']);\n} else {\n $customer = array_intersect_key($customer, array_flip(['id', 'first_name', 'last_name']));\n}\n\n\nThis backup filtering implementation ensures that only non-sensitive fields are preserved, even if the model helper is not available.\n\nIn addition to code-level patches, organizations should implement defense-in-depth measures to mitigate the risk of appointment hash leakage. A strict Referrer-Policy header must be deployed across the web server configuration (such as Apache or Nginx) to prevent the transmission of scheduling URLs containing the 12-character hash to third-party domains. Configuring the web server to append Referrer-Policy: no-referrer to all outgoing HTTP responses ensures that outbound links, such as maps or external integrations, do not expose the sensitive hash in their headers.\n\nFinally, organizations should audit their email configuration to ensure that all booking confirmation, reminder, and rescheduling emails are sent over encrypted TLS connections. This prevents the plaintext capture of scheduling hashes by network adversaries sniffing SMTP traffic. Access to the administrative calendar interface should also be restricted behind virtual private networks (VPNs) or strict IP whitelists to ensure that unauthorized internal or external actors cannot view active appointment hashes through administrative panels.