Skip to content

Instantly share code, notes, and snippets.

@RajChowdhury240
Created November 23, 2025 16:56
Show Gist options
  • Select an option

  • Save RajChowdhury240/d318dd28d29a20f9d6eb26a83f744cf1 to your computer and use it in GitHub Desktop.

Select an option

Save RajChowdhury240/d318dd28d29a20f9d6eb26a83f744cf1 to your computer and use it in GitHub Desktop.

Security Vulnerability Report - FPDF Directory

Date: Generated on scan
Severity Levels: Critical, High, Medium, Low


Executive Summary

This directory contains multiple web vulnerabilities, with the most critical being in index.php which appears to be an intentionally vulnerable CTF (Capture The Flag) demonstration file. The FPDF library itself (fpdf.php) also contains a potential Local File Inclusion vulnerability in the _loadfont method.


Critical Vulnerabilities

1. Local File Inclusion (LFI) / Remote Code Execution (RCE)

File: index.php
Lines: 39-50
Severity: CRITICAL
CVSS Score: 9.8 (Critical)

Description: The index.php file contains a Local File Inclusion vulnerability that allows arbitrary PHP code execution through the ?load parameter.

Vulnerable Code:

if (isset($_GET['load'])) {
    $file = $_GET['load'];
    $target = $uploadDir . '/' . $file;
    if (is_file($target)) {
        include $target;  // VULNERABLE: Executes PHP from uploaded file
    }
}

Attack Vector:

  1. Attacker uploads a malicious PHP file via the upload form
  2. Attacker accesses ?load=malicious.php
  3. PHP code in the uploaded file is executed on the server

Impact:

  • Complete server compromise
  • Data exfiltration
  • Server-side code execution
  • Potential for lateral movement in the network

Remediation:

  • Remove this file if it's not needed (it's marked as CTF demo)
  • If needed, implement strict whitelist of allowed filenames
  • Use realpath() and verify the resolved path is within the upload directory
  • Never use include/require with user-controlled paths
  • Consider using a database to store font metadata instead of file includes

2. Unrestricted File Upload

File: index.php
Lines: 19-34
Severity: CRITICAL
CVSS Score: 9.1 (Critical)

Description: The file upload functionality accepts any file type without proper validation, allowing attackers to upload malicious files including PHP shells, executables, and other dangerous content.

Vulnerable Code:

if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_FILES['fontfile'])) {
    $f = $_FILES['fontfile'];
    if ($f['error'] === UPLOAD_ERR_OK) {
        // NOTE: intentionally allowing any extension for CTF demonstration.
        $name = basename($f['name']);
        $dest = $uploadDir . '/' . $name;
        move_uploaded_file($f['tmp_name'], $dest);
    }
}

Issues:

  • No file type validation (MIME type, extension, magic bytes)
  • No file size limits
  • No content validation
  • Files are stored with original names (potential overwrite attacks)
  • basename() alone doesn't prevent all path traversal attempts

Attack Vector:

  • Upload PHP web shells (e.g., shell.php with <?php system($_GET['cmd']); ?>)
  • Upload executable files
  • Upload files with double extensions (e.g., shell.php.jpg)
  • Overwrite existing files

Impact:

  • Remote code execution (when combined with LFI)
  • Denial of service (disk space exhaustion)
  • Malware distribution
  • Data corruption

Remediation:

  • Implement strict whitelist of allowed file extensions
  • Validate MIME types server-side
  • Check file magic bytes (file signatures)
  • Rename uploaded files with random names
  • Store files outside web root when possible
  • Implement file size limits
  • Scan uploaded files with antivirus
  • Use a content security policy

High Vulnerabilities

3. Local File Inclusion in FPDF Library

File: fpdf.php
Lines: 1134-1145
Severity: HIGH
CVSS Score: 7.5 (High)

Description: The _loadfont() method in the FPDF library uses include() to load font definition files. If user input can influence the $path parameter, this could lead to Local File Inclusion.

Vulnerable Code:

protected function _loadfont($path)
{
    // Load a font definition file
    include($path);  // Potential LFI if $path is user-controlled
    if(!isset($name))
        $this->Error('Could not include font definition file: '.$path);
    // ...
}

Context: This method is called from AddFont() which constructs the path from user-provided $file and $dir parameters. While there are some checks (line 455-456), the path construction could still be vulnerable if not used carefully.

Attack Vector: If an application using FPDF allows users to specify font file paths:

$pdf->AddFont('custom', '', '../config.php');  // Could include sensitive files

Impact:

  • Information disclosure (reading sensitive files)
  • Code execution (if PHP files are included)
  • Server compromise

Remediation:

  • Validate that font paths are within the allowed font directory
  • Use realpath() and verify the resolved path
  • Implement a whitelist of allowed font files
  • Consider using a safer method than include() (e.g., JSON/INI parsing)

4. Information Disclosure via Error Messages

File: index.php
Lines: 5-6
Severity: MEDIUM
CVSS Score: 5.3 (Medium)

Description: Error reporting is enabled and errors are displayed to users, potentially exposing sensitive information about the application structure, file paths, and system configuration.

Vulnerable Code:

error_reporting(E_ALL);
ini_set('display_errors', 1);

Impact:

  • File system structure disclosure
  • Database connection details (if errors occur)
  • Application logic exposure
  • Stack traces revealing code structure

Remediation:

  • Disable display_errors in production
  • Set display_errors = Off in php.ini
  • Use error_log instead of displaying errors
  • Implement custom error handlers
  • Return generic error messages to users

Medium Vulnerabilities

5. Path Traversal Potential

File: index.php
Line: 24, 40
Severity: MEDIUM
CVSS Score: 6.5 (Medium)

Description: While basename() is used, there are still potential path traversal risks, especially when combined with the LFI vulnerability.

Vulnerable Code:

$name = basename($f['name']);  // Reduces but doesn't eliminate risk
$file = $_GET['load'];  // No sanitization

Issues:

  • basename() prevents directory traversal in filename, but doesn't validate the result
  • No validation that the file is actually a font file
  • No check for null bytes or other dangerous characters

Remediation:

  • Use realpath() and verify the resolved path is within allowed directory
  • Implement strict filename validation (alphanumeric + specific chars only)
  • Check for null bytes and other dangerous characters
  • Use a whitelist approach

6. Missing Security Headers

File: index.php
Severity: MEDIUM
CVSS Score: 4.3 (Medium)

Description: The application doesn't set important security headers that could prevent various attacks.

Missing Headers:

  • Content-Security-Policy (prevents XSS)
  • X-Frame-Options (prevents clickjacking)
  • X-Content-Type-Options: nosniff (prevents MIME sniffing)
  • Strict-Transport-Security (if using HTTPS)
  • X-XSS-Protection

Remediation: Add security headers:

header('X-Content-Type-Options: nosniff');
header('X-Frame-Options: DENY');
header('X-XSS-Protection: 1; mode=block');
header('Content-Security-Policy: default-src \'self\'');

7. No CSRF Protection

File: index.php
Lines: 77-80
Severity: MEDIUM
CVSS Score: 6.1 (Medium)

Description: The file upload form lacks CSRF (Cross-Site Request Forgery) protection, allowing attackers to trick authenticated users into uploading files.

Impact:

  • Unauthorized file uploads
  • Potential for account takeover if combined with other vulnerabilities

Remediation:

  • Implement CSRF tokens
  • Use SameSite cookies
  • Verify the Origin/Referer header

Low Vulnerabilities

8. No Authentication/Authorization

File: index.php
Severity: LOW
CVSS Score: 3.1 (Low)

Description: The application has no authentication mechanism, allowing anyone to upload files and execute code.

Remediation:

  • Implement proper authentication
  • Use role-based access control (RBAC)
  • Restrict file upload to authorized users only

9. Directory Listing Exposure

File: index.php
Lines: 100-109
Severity: LOW
CVSS Score: 3.7 (Low)

Description: The application lists uploaded files, which could aid attackers in identifying uploaded malicious files.

Remediation:

  • Don't list files publicly
  • Implement access controls
  • Use random filenames instead of original names

10. Insecure File Permissions

File: index.php
Line: 14
Severity: LOW
CVSS Score: 2.5 (Low)

Description: The upload directory is created with 0755 permissions, which may be too permissive.

Remediation:

  • Use more restrictive permissions (e.g., 0750 or 0700)
  • Ensure the web server user has appropriate permissions
  • Consider storing uploads outside the web root

11. Potential Local File Disclosure in Tutorial Files

Files: tutorial/tuto3.php, tutorial/tuto4.php
Lines: 54, 80
Severity: LOW (if user input is introduced)
CVSS Score: 3.1 (Low)

Description: Tutorial files use file_get_contents($file) with hardcoded filenames. While currently safe, if these are modified to accept user input, they could lead to Local File Disclosure.

Current Code:

$txt = file_get_contents($file);  // Currently hardcoded, but vulnerable if made dynamic

Remediation:

  • If user input is needed, implement strict whitelist of allowed files
  • Use realpath() and verify the resolved path is within allowed directory
  • Never allow user input to directly specify file paths
  • Consider using a file ID mapping system instead of direct paths

Recommendations Summary

Immediate Actions (Critical)

  1. Remove or secure index.php - This file is marked as a CTF demo and should not be in production
  2. Disable error display - Set display_errors = Off in production
  3. Implement file upload validation - Whitelist, MIME checking, magic bytes validation
  4. Fix LFI vulnerability - Never use include/require with user input

Short-term Actions (High Priority)

  1. Review FPDF _loadfont usage - Ensure font paths are never user-controlled
  2. Add security headers - Implement CSP, X-Frame-Options, etc.
  3. Implement CSRF protection - Add tokens to all forms
  4. Add authentication - Restrict access to sensitive functionality

Long-term Actions (Best Practices)

  1. Security audit - Regular code reviews and penetration testing
  2. Input validation framework - Implement consistent validation across the application
  3. Logging and monitoring - Track suspicious activities
  4. Security training - Educate developers on secure coding practices

Testing Recommendations

  1. Automated Scanning:

    • Use tools like OWASP ZAP, Burp Suite, or Acunetix
    • Run static analysis tools (PHPStan, Psalm with security plugins)
  2. Manual Testing:

    • Test file upload with various file types
    • Attempt path traversal attacks (../, ..\\, null bytes)
    • Test LFI with various payloads
    • Verify error handling doesn't leak information
  3. Code Review:

    • Review all user input handling
    • Check all file operations
    • Verify all include/require statements
    • Review authentication and authorization logic

References


Report Generated: Automated security scan
Next Review: After remediation implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment