Post

CVE-2026-14224: Subscriber+ IDOR in Easy Appointments

Public-safe summary of CVE-2026-14224, a Subscriber+ IDOR in Easy Appointments that can allow cross-user appointment metadata modification and notification-recipient redirection.

CVE-2026-14224: Subscriber+ IDOR in Easy Appointments

CVE-2026-14224: Subscriber+ IDOR in Easy Appointments

Overview

I discovered an insecure direct object reference vulnerability in the Easy Appointments WordPress plugin.

The vulnerability affects Easy Appointments versions up to and including 3.12.26 and has been assigned:

  • Official CVE Record: CVE-2026-14224
  • Affected plugin: Easy Appointments
  • Vulnerability type: Insecure Direct Object Reference / Broken Access Control
  • Minimum required access: Subscriber
  • Affected versions: 3.12.26 and earlier
  • Fixed version: Not publicly available in this write-up
  • CVSS: Not publicly available in this write-up
  • CWE: Not publicly available in this write-up
  • Published date: 2026-06-13
  • Researcher: Duy

Summary

Easy Appointments allows authenticated users to edit appointment-related customer data through its appointment-edit workflow.

In the affected version, a Subscriber can obtain a valid appointment-edit nonce from an appointment they own and then reuse that nonce while supplying another user’s appointment identifier.

The vulnerable server-side flow validates the generic appointment-edit nonce but does not verify that the selected appointment belongs to the current user before replacing custom metadata for the supplied appointment.

In the tested scenario, this allowed Subscriber A to modify EMAIL-type metadata associated with Subscriber B’s appointment.

Expected Behavior

An authenticated user should only be able to update custom metadata associated with appointments they are authorized to manage.

A nonce obtained from one appointment should not authorize metadata modification for an unrelated appointment owned by another user.

Before updating appointment metadata, the server should resolve the supplied appointment object and verify ownership or an equivalent authorization rule against the current user.

Actual Behavior

The affected AJAX workflow accepts an attacker-controlled appointment identifier and validates a generic appointment-edit nonce.

The handler does not perform an appointment ownership check before deleting and replacing custom metadata for the selected appointment.

As a result, a Subscriber can reuse a nonce obtained from their own appointment while targeting another user’s appointment.

Vulnerability Chain

A high-level chain is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Subscriber owns Appointment A
        |
        v
Subscriber obtains a valid edit nonce for Appointment A
        |
        v
Subscriber supplies Appointment B's identifier to the customer-data update workflow
        |
        v
Server validates the generic nonce but does not verify ownership of Appointment B
        |
        v
Foreign appointment metadata is replaced
        |
        v
Later notification workflow consumes the modified metadata as trusted appointment data

The core issue is an authorization mismatch: proof that a user can edit one appointment is treated as sufficient authorization to modify metadata for a different appointment selected by request input.

Required Conditions / Attack Preconditions

The tested behavior required:

  1. Easy Appointments version 3.12.26 or earlier.
  2. A logged-in user with Subscriber-level access.
  3. At least two appointments owned by different users.
  4. The attacker can obtain a normal edit nonce from an appointment they own.
  5. The customer notification workflow is enabled.
  6. A later administrator status change triggers the normal customer notification path.

The final notification effect depends on the site’s notification configuration and template design.

Trust-Boundary Analysis

The intended trust boundary is the appointment object.

A user who can edit Appointment A should not automatically gain authority over Appointment B.

In the vulnerable flow, authorization is tied to a reusable action nonce rather than the specific appointment object being modified. The request-selected appointment identifier therefore crosses the authorization boundary without a corresponding ownership check.

This allows data controlled by one user to influence metadata attached to another user’s appointment.

Impact

A Subscriber can influence notification-recipient selection for another user’s appointment by modifying foreign EMAIL-type metadata.

In the tested configuration, a later routine administrator status change caused a customer notification for the victim appointment to be sent to an attacker-controlled email address instead of the intended recipient.

The generated notification contained appointment-specific information associated with the victim appointment in the tested configuration.

The plugin also supports richer notification templates containing appointment, service, worker, location, and custom-field placeholders. The exact exposure depends on the affected site’s notification-template configuration.

Technical Validation

The issue was validated in a controlled WordPress test environment using Easy Appointments 3.12.26.

Testing confirmed that:

  1. Subscriber A could obtain an edit nonce from an appointment they owned.
  2. Subscriber A could not access the normal edit form for Subscriber B’s appointment.
  3. The customer-data update workflow accepted Subscriber A’s nonce while targeting Subscriber B’s appointment identifier.
  4. The server returned a successful update response.
  5. The victim-owned appointment remained associated with the victim user, but its EMAIL-type metadata was replaced.
  6. A later normal administrator status change consumed the modified metadata during customer notification routing.

Proof of Concept

The operational proof of concept is intentionally withheld.

This public write-up does not include:

  • raw HTTP requests,
  • curl commands,
  • session handling details,
  • concrete local target paths,
  • nonce extraction steps,
  • request payloads,
  • enumeration steps, or
  • direct exploitation instructions.

The purpose of this write-up is to document the affected boundary, impact, and remediation direction without accelerating exploitation against sites that have not yet updated.

Remediation

Site owners should update Easy Appointments once a fixed version is available.

Plugin maintainers should ensure that the customer-data update workflow performs object-level authorization before modifying appointment metadata.

At minimum, the server should:

  1. Resolve the supplied appointment identifier server-side.
  2. Verify that the current user is authorized to modify that specific appointment.
  3. Bind edit authorization to the appointment object, not only to a generic action nonce.
  4. Reject metadata updates for appointments outside the current user’s permitted scope.
  5. Prefer canonical appointment/customer records for notification-recipient selection where possible.

Secure Design Recommendations

Bind nonces to object authorization

A nonce should not be treated as a complete authorization decision.

Even when a nonce is valid, the server should still verify whether the current user is allowed to modify the specific object referenced by request input.

Validate ownership before mutation

Before replacing appointment metadata, the handler should confirm that the selected appointment belongs to the current user or that the user has a privileged role allowed to manage other users’ appointments.

Avoid trusting mutable metadata for recipient routing

Notification routing should prefer canonical appointment or customer records, especially when metadata can be edited through lower-privileged workflows.

If custom metadata can influence notification recipients, that metadata should be protected by strict authorization checks.

Add regression tests for cross-object updates

Regression tests should cover cases where a user obtains a valid edit token or nonce for one appointment and then attempts to apply it to another user’s appointment.

The expected result should be a denial before any metadata mutation occurs.

Disclosure Timeline

DateEvent
2026Vulnerability discovered and reproduced in a controlled environment
2026Vulnerability submitted for coordinated disclosure
2026-06-13CVE-2026-14224 published

Additional dates may be added after the complete disclosure process concludes.

Research Credit

This vulnerability was independently discovered and reported by:

Duy

  • Research focus: WordPress plugin security, application security, and authorization boundary analysis

References

Responsible Disclosure Notice

This write-up intentionally omits operational exploitation details and raw proof-of-concept material.

The information published here is intended to document the affected authorization boundary, help defenders understand the risk, and encourage secure remediation without providing a copy-paste exploitation path.

This post is licensed under CC BY 4.0 by the author.