CVE-2026-42552: Flight PHP Information Disclosure Flaw

CVE-2026-42552 Overview

CVE-2026-42552 affects Flight, an extensible micro-framework for PHP. The default error handler Engine::_error() writes full exception messages, exception codes, and stack traces directly into HTTP 500 responses. Stack traces include absolute filesystem paths, exposing internal directory structure and module organization. The handler operates without any debug gating, so production deployments leak the same diagnostic data as development environments. Attackers can use this information to map application internals, harvest secrets interpolated into exception messages, and chain the disclosure with other weaknesses such as Local File Inclusion (LFI) or path traversal. The issue is fixed in Flight 3.18.1.

Critical Impact

Production Flight applications prior to 3.18.1 leak absolute paths, exception details, and stack traces in HTTP 500 responses, providing attackers with reconnaissance primitives for follow-on exploitation.

Affected Products

• Flight PHP micro-framework versions prior to 3.18.1
• flightphp/core package distributed via Composer
• Applications deploying Flight with the default error handler enabled

Discovery Timeline

• 2026-05-13 - CVE-2026-42552 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42552

Vulnerability Analysis

The vulnerability falls under [CWE-209]: Generation of Error Message Containing Sensitive Information. Flight's Engine::_error() method serves as the default exception handler invoked when an uncaught exception bubbles up during request processing. Instead of returning a generic HTTP 500 response, the handler serializes the exception object's message, numeric code, and complete stack trace into the response body.

Stack traces in PHP include absolute filesystem paths for every frame, the calling class and method names, and arguments passed to those methods. When an exception is constructed with interpolated values, such as database connection strings, API tokens, or user input, those values appear verbatim in the HTTP response.

The handler does not check an application environment flag or debug mode toggle before emitting this output. Developers who deploy Flight without overriding the default error handler expose this diagnostic surface to unauthenticated network clients.

Root Cause

The root cause is missing environment-aware gating in the default error handler. Production frameworks typically distinguish between development output and production output through a debug flag. Flight's Engine::_error() emits verbose diagnostics unconditionally, treating every deployment as a development environment for error reporting purposes.

Attack Vector

An unauthenticated attacker triggers an exception by sending malformed input to any endpoint, requesting non-existent routes that surface framework errors, or supplying values that cause downstream library exceptions. The HTTP 500 response body contains the exception data. Attackers parse responses to extract document roots, vendor directory paths, configuration file locations, and class hierarchies. This information enables targeted path traversal payloads, LFI exploitation, and identification of additional vulnerable components.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-qrch-52m5-vv85.

Detection Methods for CVE-2026-42552

Indicators of Compromise

• HTTP 500 response bodies containing Stack trace: strings or #0 /var/www/ style frame markers returned to external clients
• Web server access logs showing repeated requests producing 500 status codes from a single source
• Requests targeting framework-specific paths or malformed query parameters designed to trigger exceptions

Detection Strategies

• Inventory Composer dependencies and flag any project where flightphp/core resolves to a version below 3.18.1
• Scan HTTP responses from production endpoints for stack trace signatures and absolute path patterns
• Review application logs for uncaught exceptions that were rendered to clients rather than handled internally

Monitoring Recommendations

• Configure web application firewalls to inspect outbound 500 responses for stack trace patterns and absolute path leakage
• Alert on bursts of 500 responses from a single source IP, which may indicate reconnaissance probing
• Track Composer lock file changes in CI to detect when Flight versions regress below the fixed release

How to Mitigate CVE-2026-42552

Immediate Actions Required

• Upgrade flightphp/core to version 3.18.1 or later using composer update flightphp/core
• Audit application code and configuration for secrets that may have been embedded in exception messages and rotate any that could have leaked
• Review web server and CDN logs for historical 500 responses that may have already disclosed internal paths

Patch Information

The fix is available in Flight 3.18.1. Refer to the GitHub Security Advisory GHSA-qrch-52m5-vv85 for release details and the corresponding code change.

Workarounds

• Override the default error handler by registering a custom handler via Flight::map('error', ...) that returns a generic message in production
• Set display_errors = Off in php.ini for production servers and route errors to log files instead of HTTP responses
• Place a reverse proxy or WAF rule in front of the application to strip response bodies on 500 status codes

# Upgrade Flight to the patched release
composer require flightphp/core:^3.18.1

# Verify the installed version
composer show flightphp/core | grep versions