CVE-2026-5326: Insecure Direct Object Reference (IDOR) in SourceCodester Leave Application System

The SourceCodester Leave Application System 1.0 is a PHP-based web application designed to manage employee time-off requests, staff records, and administrative duties. The system relies on an SQLite3 database backend to retrieve and store records. Due to a design oversight in the user access architecture, the dynamic routing system exposes an open attack surface to unauthenticated web clients.

This vulnerability is cataloged as CVE-2026-5326. It centers on the User Information Handler loaded via the routing path '/index.php?page=manage_user'. The component is designed to show profile details of specific accounts based on the value passed to the 'id' query parameter.

Because the system is deployed with public-facing administrative routes, the lack of session protection on these pathways directly exposes private user records. Any remote actor can issue request parameters targeting specific database indices, resulting in unauthorized data exposure.

The underlying security flaw is classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-285 (Improper Authorization). The failure occurs because the web application's design does not couple database lookups to the server-side session authentication tokens of the active request.

When a request containing the parameter 'id' is directed to the application, the backend retrieves the value directly from the global HTTP '$_GET' array. The software then uses this untrusted integer value to construct a query and locate the corresponding row within the SQLite3 database.

The application code lacks any condition to determine if the active session possesses the permission to access the requested profile. It does not verify whether the requesting user is an administrator, nor does it confirm if the request matches the session owner's ID. This complete authorization void allows unauthenticated users to enumerate database records step-by-step.

The vulnerable code path highlights the mechanism where client inputs flow into raw queries without security validation filters. The dynamic template engine processes parameters without verifying authorization states.

// Vulnerable Implementation
// Location: index.php / manage_user.php
 
if (isset($_GET['id'])) {
    // Input is fetched directly from the client without verification
    $user_id = $_GET['id']; 
    
    // The application queries the SQLite3 database using the unsanitized ID
    $query = "SELECT * FROM users WHERE id = :id";
    $stmt = $db->prepare($query);
    $stmt->bindValue(':id', $user_id, SQLITE3_INTEGER);
    $result = $stmt->execute();
    
    // Fetch the sensitive user record and render it
    $user_data = $result->fetchArray(SQLITE3_ASSOC);
    
    // Security Flaw: There is no check to verify if the requester has permission to view $user_id
}

To repair this vulnerability, developers must implement session ownership validation controls. The following patch verifies the active session identifier and checks the user's role before querying the database engine.

// Patched Implementation
// Location: index.php / manage_user.php
 
if (session_status() == PHP_SESSION_NONE) {
    session_start();
}
 
// Step 1: Enforce active session authentication
if (!isset($_SESSION['user_id'])) {
    http_response_code(401);
    exit("Access Denied: Unauthenticated access attempt.");
}
 
if (isset($_GET['id'])) {
    $requested_id = intval($_GET['id']);
    $current_user_id = intval($_SESSION['user_id']);
    $current_user_role = $_SESSION['role'] ?? 'employee';
 
    // Step 2: Ensure session owner matching or administrative privilege
    if ($requested_id !== $current_user_id && $current_user_role !== 'admin') {
        http_response_code(403);
        exit("Access Denied: You do not have permissions to access this resource.");
    }
 
    // Step 3: Secure database query execution after authorization success
    $query = "SELECT * FROM users WHERE id = :id";
    $stmt = $db->prepare($query);
    $stmt->bindValue(':id', $requested_id, SQLITE3_INTEGER);
    $result = $stmt->execute();
    $user_data = $result->fetchArray(SQLITE3_ASSOC);
}

Exploiting this flaw is highly reliable and requires no active pre-conditions like session state hijacking or credential guessing. The attack vector consists entirely of changing the 'id' parameter in HTTP GET requests.

An attacker begins by sending a standard request to retrieve a valid URL path. The original query is structured to access a specific profile. The attacker alters the numeric value of the 'id' parameter to targeted numbers like '1', which represents the system administrator account.

The SQLite3 database processes the query and returns the record for the administrator profile. This profile is rendered by the template, leaking administrative usernames, email details, and operational records. Attackers can automate the extraction process by executing sequential loops that query multiple IDs.

The concrete security impact of CVE-2026-5326 is restricted to a complete compromise of read confidentiality. The vulnerability does not provide an direct channel to write data, modify configuration files, or execute binary code on the hosting server system.

However, the lack of data integrity controls does not diminish the overall severity. Threat actors can harvest employee emails, full names, and organizational hierarchies. This information is valuable for organizing credential harvesting attacks and targeted social engineering schemes.

The vulnerability carries a CVSS base score of 5.3 under CVSS v3.1 and 6.9 under CVSS v4.0. The ease of remote execution and the zero required privileges make this flaw an attractive target for automated scraping campaigns.

Since there is no vendor patch available for this software, administrators must manually review the code files to correct the logic. Implementing session-based query limits is the most effective approach to remediate the vulnerability.

Every parameter-driven query inside the user information templates must run through an validation block. This block compares the parameter against the user's session variables. If the request comes from an external user or does not match the active session, the application must reject the transaction and log an authentication warning.

Additional defense measures include wrapping database lookups in a secure routing filter. Replacing raw database primary keys with non-sequential identifiers like Universally Unique Identifiers (UUIDs) also reduces the success rate of automated parameter enumeration attacks.