Drupal 11.x-dev - Full Path Disclosure

Drupal 11.x-dev — Full Path Disclosure (CVE-2024-45440)

This article explains the Full Path Disclosure issue reported as CVE-2024-45440 against Drupal 11.x-dev, why it matters, how it arises, and practical guidance for detection, mitigation, and secure coding practices. The objective is to help site owners, developers, and defenders understand the risk and remediate it safely.

Summary of the vulnerability

Item	Details
Identifier	CVE-2024-45440
Product / Version	Drupal 11.x-dev (development branch)
Vulnerable component	core/authorize.php (improper handling of a missing file used for hash_salt)
Impact	Full filesystem path disclosure (leaks absolute path(s) such as /var/www/html/...settings.php in response bodies or error fragments)
Attack surface	Unauthenticated HTTP requests to affected endpoints can cause messages or HTML fragments that expose server path information
Severity	Information disclosure — lowers difficulty for further attacks (information can help privilege escalation, targeted exploitation, or mapping)

Technical root cause (high level)

The issue stems from server-side code that attempts to obtain a secret (hash_salt) using a file read operation (e.g., file_get_contents) and exposes diagnostic information when the file is missing or unreadable. In some cases the resulting error or HTML rendering includes the absolute filesystem path (for example a reference to settings.php). When display of error information or un-sanitized content is allowed, external clients can observe those full paths.

This is a classic information disclosure vulnerability: the application was not sufficiently defensive when a dependent file was absent, and the resulting response included implementation-specific details that should never be revealed to untrusted users.

Why full path disclosure matters

• Reconnaissance: Full path information helps attackers map directory structure and locate configuration files (e.g., settings.php), symbolic links, and custom deployment layouts.
• Privilege escalation & lateral movement: Knowing paths can help craft more effective local exploits or locate backup files containing secrets.
• Targeted exploitation: Attackers can tailor payloads to known file-system layout or exploit misconfigurations (e.g., weak file permissions).

Safe detection and monitoring guidance

Defenders should look for evidence of filesystem paths in HTTP responses, logs, and error reports. Focus on identifying unintentional disclosures rather than actively scanning external systems.

• Inspect web server and application logs for responses that contain absolute paths like /var/www/, C:\, or filenames such as settings.php.
• Use automated log search tools to flag occurrences of server-path-like patterns in HTML or error text. Example patterns for defenders (use with your logging tool; avoid external probing): /([A-Za-z]:\\|/)(.*?settings\.php).
• Set up WAF rules to block or log suspicious requests that attempt to provoke errors (e.g., requests targeting developer-only endpoints or authorization endpoints from untrusted sources).
• Review access logs for repeated access attempts to sensitive endpoints that might try to elicit diagnostic output.

Immediate mitigation steps for site operators

• Patch immediately: upgrade Drupal core to the patched release that addresses CVE-2024-45440. Check the official Drupal security advisory and apply the vendor-provided patch.
• Disable error display in production: ensure PHP and web application settings do not expose diagnostic messages to clients.
• Harden error logging: log errors to files not accessible from the web and avoid logging full filesystem paths in response bodies or messages returned to callers.
• Reduce attack surface: restrict access to development-only endpoints, and remove or disable debug modules/features on production systems.
• Apply least privilege file permissions: configuration and secret files should be readable only by the application process and not world-readable.

Recommended PHP / runtime configuration

• php.ini settings for production:
  • display_errors = Off
  • log_errors = On
  • error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT (adjust as appropriate)
  • error_log = /var/log/php_errors.log
• Configure the web server to return generic error pages for 4xx/5xx responses and avoid exposing stack traces or file paths in HTML.
• Establish centralized logging and monitoring so sensitive disclosures can be detected and triaged quickly.

Secure coding practices to prevent similar issues

• Validate and harden all file access logic: always check is_readable() or equivalent before attempting to load files.
• Avoid echoing or embedding internal paths, filenames, or system errors in responses to untrusted users. Use generic messages and write details to server-side logs only.
• Use the error suppression operator and explicit checks sparingly and document why they are safe; prefer controlled exception handling and centralized error handlers.
• Store secrets in protected configuration (outside webroot) and load them with defensive code that does not reveal the path if the file is missing.

Safe example: defensively loading a salt file in PHP

<?php
// Defensive pattern: do not reveal the full path or file contents to visitors.
// Load a secret salt file if readable; otherwise log and continue with a safe fallback.

$salt_file = '/var/www/private/hash_salt.txt';
$hash_salt = '';

if (is_readable($salt_file)) {
    // Suppress warnings from file_get_contents and check return value.
    $contents = @file_get_contents($salt_file);
    if ($contents !== false) {
        $hash_salt = trim($contents);
    } else {
        // Log a non-sensitive message — no path returned to the client.
        error_log('Unable to read salt file (I/O error).');
    }
} else {
    // Non-sensitive log; do not include the path in the message.
    error_log('Salt file not readable or does not exist.');
}

// Use $hash_salt safely in application logic. Ensure fallback behavior does not
// compromise security (e.g., do not switch to a predictable default).
?>

Explanation: This snippet demonstrates non-invasive defensive checks before reading a file and uses error_log for server-side diagnostics only. The code avoids returning file paths or internal details to the client. The use of the error suppression operator (@) is limited to preventing unhandled warnings; the code still checks for failure and logs a generic message.

Composer-based remediation (safe update procedure)

If your site is managed with Composer, update Drupal core and dependencies using standard Composer flows. Example safe steps:

# Backup code and database first (always).
# From the project root:
composer update drupal/core 'drupal/core-*' --with-dependencies
# Run database updates and clear caches
drush updb -y
drush cr

Explanation: The above are typical administrator actions to update Drupal core and dependencies. Always backup files and databases before an update and test updates in a staging environment prior to production rollout.

Post-patch validation and monitoring

• After applying the vendor patch or upgrade, verify that the affected endpoint no longer returns internal path fragments or sensitive diagnostics.
• Run an internal vulnerability scan (in a controlled environment) or code audit to confirm the fix and look for similar patterns elsewhere in the codebase.
• Monitor logs and alerts for any signs that the vulnerability was exploited prior to patching (look for unexpected requests to authorization or developer endpoints and any logs noting path-like strings in responses).

Responsible disclosure and resources

Follow vendor advisories and the official Drupal security advisories for patch availability and upgrade instructions. CVE-2024-45440 corresponds to the disclosure ID; consult the Drupal Security Team's announcement and apply their recommended upgrades or patches. If you discover evidence of exploitation, preserve logs and consult incident response procedures before taking systems offline.

Summary

Full Path Disclosure vulnerabilities like CVE-2024-45440 are information disclosure issues that reduce the secrecy of server internals and can assist subsequent attacks. The recommended response is immediate patching, ensuring production systems never display debug output to remote clients, applying secure file-handling patterns in application code, tightening file permissions, and enhancing monitoring. Applying these mitigations reduces risk and improves overall resilience.