What is the CVSS score of CVE-2026-42552?

CVE-2026-42552 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Which versions of FlightPHP Core are affected by CVE-2026-42552?

FlightPHP Core versions before 3.18.1 expose sensitive internal application details, filesystem paths, and potentially embedded secrets in error responses accessible to unauthenticated users,…. A patch is available.

How to fix or mitigate CVE-2026-42552?

Within 24 hours: Inventory all FlightPHP Core deployments and identify current versions running versions prior to 3.18.1. Within 7 days: Apply vendor patch to FlightPHP 3.18.1 or later across all affected systems and verify flight.debug setting is set to false in production configuration. Within 30 days: Conduct application code review to identify and remediate any secrets or sensitive configuration details that may have been disclosed through error pages during the vulnerability window.

FlightPHP Core CVE-2026-42552

HIGH

Error Message Information Leak (CWE-209)

2026-05-06 https://github.com/flightphp/core

GHSA-qrch-52m5-vv85

PHP Information Disclosure Path Traversal

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

May 06, 2026 - 22:39 vuln.today

Analysis Generated

May 06, 2026 - 22:39 vuln.today

CVE Published

May 06, 2026 - 21:39 nvd

HIGH 7.5

DescriptionGitHub Advisory

Summary

The default error handler Engine::_error() writes the full exception message, exception code, and stack trace (including absolute filesystem paths) directly into the HTTP 500 response, with no debug gating. Production deployments leak internal paths, any secret interpolated into an exception message, and full module structure - giving attackers primitives for chaining other weaknesses (LFI, path traversal).

Affected code

flight/Engine.php (≈ lines 678-704):

php

public function _error(Throwable $e): void
{
    ...
    $msg = sprintf(<<<'HTML'
        <h1>500 Internal Server Error</h1>
            <h3>%s (%s)</h3>
            <pre>%s</pre>
        HTML,
        $e->getMessage(),
        $e->getCode(),
        $e->getTraceAsString()
    );
    $this->response()->cache(0)->clearBody()->status(500)->write($msg)->send();
}

No flight.debug check, no environment gating.

Proof of concept

Any uncaught exception - including those auto-raised from handleError() - returns:

HTTP/1.1 500 Internal Server Error

<h1>500 Internal Server Error</h1>
  <h3>secret path /var/www/config/db.yml; token=LEAKED123 (0)</h3>
  <pre>#0 [internal function]: {closure}()
  #1 /home/user/app/vendor/flightphp/core/flight/core/Dispatcher.php(361)...
  #2 /home/user/app/vendor/flightphp/core/flight/Engine.php(...)
  ...
  </pre>

Reproduced against the live PoC app at /poc5/error.

Impact

Disclosure of absolute filesystem paths (primes weaponization of LFI / path-traversal vulnerabilities in the same application).
Disclosure of secrets (DB credentials, API tokens) when exceptions are constructed with interpolated configuration values.
Enumeration of installed vendor packages and internal application structure.

Patch (fixed in `3.18.1`, commit `b8dd23a`)

A new flight.debug setting (default false) gates the verbose output. In production the handler now emits only <h1>500 Internal Server Error</h1>. Developers can set flight.debug = true in local environments to restore the full trace output.

Credit

Discovered by @Rootingg.

AnalysisAI

FlightPHP Core's default error handler exposes full exception messages, stack traces, and absolute filesystem paths in HTTP 500 responses without any debug-mode gating. All versions before 3.18.1 leak internal application structure, vendor package names, and any secrets interpolated into exception messages to unauthenticated remote attackers. This information disclosure primes follow-on attacks like LFI and path traversal by revealing server paths and configuration file locations. Vendor-released patch in version 3.18.1 introduces a flight.debug setting (default false) that suppresses verbose output in production. CVSS 7.5 reflects network-accessible information disclosure with no privileges required.

Technical ContextAI

FlightPHP is a lightweight PHP micro-framework for building REST APIs and web applications. The vulnerability resides in Engine::_error() (flight/Engine.php lines 678-704), the framework's default uncaught exception handler. This handler directly writes Throwable objects' getMessage(), getCode(), and getTraceAsString() output into HTTP 500 responses as HTML. CWE-209 (Generation of Error Message Containing Sensitive Information) describes this class of flaw: error handlers that fail to sanitize diagnostic data before exposing it to external actors. In production PHP applications, stack traces typically contain absolute filesystem paths (e.g., /var/www/html/vendor/flightphp/core/flight/core/Dispatcher.php), loaded module paths, and class names. Exception messages often include interpolated configuration values like database DSNs or API tokens. Prior to v3.18.1, FlightPHP had no environment-based toggle to suppress this output. The commit b8dd23a introduces a flight.debug boolean configuration option (default false) that gates verbose error output, optionally logging to error_log() instead, and adds htmlspecialchars() escaping to prevent XSS in the debug payload itself.

RemediationAI

Upgrade to FlightPHP Core version 3.18.1 or later via Composer (composer require flightphp/core:^3.18.1). The patch introduces a flight.debug configuration option that defaults to false, suppressing verbose error output in production. Developers should verify flight.debug remains false in production environments; set it to true only in local development. For applications that cannot immediately upgrade, implement a custom error handler by registering a callback with Flight::map('error', function(Throwable $e) { ... }) that logs exceptions server-side via error_log() and returns a generic HTTP 500 message without stack traces or paths. Additional hardening: enable flight.log_errors = true to retain diagnostic data in server logs, configure PHP's display_errors = Off and log_errors = On in php.ini to prevent accidental leakage, and review exception messages throughout the codebase to ensure secrets are never interpolated into exception text. Trade-off: custom error handlers require maintenance across FlightPHP version upgrades and may miss framework-level exceptions if not registered early in the application lifecycle. Official patch from https://github.com/flightphp/core/commit/b8dd23aaa828cb289fa3c84e75b2a3717cab50b0 also adds htmlspecialchars() escaping to debug output, preventing XSS if flight.debug is enabled in staging environments.