Skip to main content
CVE Vulnerability Database

CVE-2024-4294: Doctor Appointment Management System RCE

CVE-2024-4294 is a critical remote code execution vulnerability in Phpgurukul Doctor Appointment Management System that exploits improper resource identifier control. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2024-4294 Overview

CVE-2024-4294 is an Insecure Direct Object Reference (IDOR) vulnerability in PHPGurukul Doctor Appointment Management System 1.0. The flaw resides in /doctor/view-appointment-detail.php, where the editid parameter lacks proper access control. An authenticated attacker can manipulate the editid value to view or modify appointment records belonging to other users. The issue is tracked under VulDB identifier VDB-262226 and maps to [CWE-99] (Improper Control of Resource Identifiers) and [CWE-639] (Authorization Bypass Through User-Controlled Key). The exploit has been publicly disclosed, increasing exposure risk for internet-facing deployments.

Critical Impact

A low-privileged, remote attacker can access, modify, or disrupt appointment records belonging to arbitrary users by tampering with the editid parameter.

Affected Products

  • PHPGurukul Doctor Appointment Management System 1.0
  • Component: /doctor/view-appointment-detail.php
  • CPE: cpe:2.3:a:phpgurukul:doctor_appointment_management_system:1.0.0

Discovery Timeline

  • 2024-04-27 - CVE-2024-4294 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-4294

Vulnerability Analysis

The vulnerability is a classic Insecure Direct Object Reference. The PHP script /doctor/view-appointment-detail.php accepts an editid query parameter and uses it directly to look up appointment records without verifying that the authenticated session owns the referenced record. Any authenticated user can substitute another user's identifier and retrieve or alter data that should be scoped to a different account.

Because the attack requires only low-level authentication and executes over the network with low complexity, exploitation is straightforward. An attacker iterates numeric or predictable editid values and enumerates appointment records across the tenant. The scope is unchanged, but confidentiality, integrity, and availability of appointment data are all impacted.

The EPSS probability is 0.855%, reflecting the availability of a public proof-of-concept described in the GitHub IDOR analysis.

Root Cause

The application performs no server-side authorization check tying the editid parameter to the current session. It trusts the client-supplied identifier as sufficient to authorize record access. This is the core pattern captured by [CWE-639] and [CWE-99].

Attack Vector

An attacker authenticates to the application with any valid low-privilege doctor account. The attacker then issues a GET request to /doctor/view-appointment-detail.php?editid=<victim_id>, substituting the identifier of another appointment. The server returns or accepts modifications to the referenced record without validating ownership.

See the public IDOR analysis and VulDB entry #262226 for full request-level details.

Detection Methods for CVE-2024-4294

Indicators of Compromise

  • Sequential or enumerated values of the editid parameter appearing in web server access logs for /doctor/view-appointment-detail.php.
  • Requests to view-appointment-detail.php from a single session referencing editid values that do not belong to that authenticated user.
  • Unexpected modifications or reads of appointment records tied to sessions that do not own those records.

Detection Strategies

  • Instrument the application to log the authenticated user identifier alongside the editid parameter, then alert when the two do not match.
  • Deploy a Web Application Firewall (WAF) rule that flags high-volume requests to /doctor/view-appointment-detail.php with rapidly changing editid values from a single session.
  • Run authenticated dynamic application security testing (DAST) with two accounts to confirm whether cross-tenant record access is possible.

Monitoring Recommendations

  • Baseline normal request rates to view-appointment-detail.php and alert on deviations indicative of enumeration.
  • Forward web server and PHP application logs to a centralized analytics platform for correlation across sessions and identifiers.
  • Monitor database audit trails for SELECT and UPDATE statements on the appointments table where the session owner differs from the record owner.

How to Mitigate CVE-2024-4294

Immediate Actions Required

  • Restrict access to /doctor/view-appointment-detail.php to trusted networks or take the application offline until access controls are added.
  • Add a server-side authorization check that compares the session's user identifier against the owner of the record referenced by editid.
  • Rotate credentials for any doctor accounts that may have been used to access unauthorized records.

Patch Information

No vendor advisory or official patch is listed in the NVD data for CVE-2024-4294. Consult the VulDB CTI report #262226 and the VulDB submission #323597 for the latest remediation status. Operators should apply a code-level fix that enforces ownership validation before returning or modifying appointment records.

Workarounds

  • Implement per-request authorization: verify that the appointment referenced by editid belongs to the authenticated doctor before rendering or updating it.
  • Replace predictable numeric identifiers with unguessable values such as UUIDv4 to raise the cost of enumeration.
  • Apply WAF rules that block requests where editid is manipulated to values outside the authenticated user's known set.
  • Enable verbose access logging on the affected endpoint to support incident response.
bash
# Configuration example: Apache mod_rewrite guard requiring an authenticated session cookie
# and rate-limiting access to the vulnerable endpoint until a code fix is deployed.
<Location "/doctor/view-appointment-detail.php">
    Require valid-user
    # Rate limit to slow enumeration (requires mod_ratelimit)
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 50
</Location>

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.