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

CVE-2026-42551 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:N/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of Flight PHP are affected by CVE-2026-42551?

Flight PHP framework versions below 3.18.1 contain a critical request method override vulnerability that allows attackers to convert benign GET requests into destructive DELETE or PUT operations…. A patch is available.

How to fix or mitigate CVE-2026-42551?

Within 24 hours: Identify all applications using Flight PHP and confirm installed versions against advisory CVE-2026-42551. Within 7 days: Upgrade all Flight installations to version 3.18.1 or later and verify flight.allow_method_override is set to false (default). Within 30 days: Conduct application testing to confirm DELETE/PUT endpoints reject method-override parameters, audit logs for suspicious GET→DELETE conversions, and review CDN cache policies to prevent poisoning scenarios.

Flight PHP CVE-2026-42551

HIGH

Interpretation Conflict (CWE-436)

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

GHSA-vxrr-w42w-w76g

PHP CSRF

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:N/I:H/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:N/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

May 06, 2026 - 22:40 vuln.today

Analysis Generated

May 06, 2026 - 22:40 vuln.today

CVE Published

May 06, 2026 - 21:38 nvd

HIGH 7.5

DescriptionGitHub Advisory

Summary

Request::getMethod() unconditionally honors the X-HTTP-Method-Override header and the $_REQUEST['_method'] parameter on any HTTP verb (including safe verbs such as GET), with no opt-in and no whitelist of permitted target methods. A GET request can silently become a DELETE or PUT, enabling CSRF escalation against destructive endpoints, bypass of middleware gated on unsafe verbs, and cache poisoning between CDN and origin.

Affected code

flight/net/Request.php (≈ lines 281-292):

php

public static function getMethod(): string
{
    $method = self::getVar('REQUEST_METHOD', 'GET');
    if (self::getVar('HTTP_X_HTTP_METHOD_OVERRIDE') !== '') {
        $method = self::getVar('HTTP_X_HTTP_METHOD_OVERRIDE');
    } elseif (isset($_REQUEST['_method']) === true) {
        $method = $_REQUEST['_method'];
    }
    return strtoupper($method);
}

$_REQUEST aggregates $_GET and $_POST; on PHP runtimes with request_order=GPC it also includes $_COOKIE.

Proof of concept

GET /item/42?_method=DELETE        HTTP/1.1

is dispatched as DELETE /item/42.

GET /item/42                       HTTP/1.1
X-HTTP-Method-Override: DELETE

is also dispatched as DELETE /item/42.

Trivial CSRF vector (no JavaScript required):

html

<img src="https://victim.tld/item/42?_method=DELETE">

loaded on any attacker-controlled page triggers the destructive DELETE on page load, bypassing Same-Origin Policy (image loads are not blocked).

Reproduced against /poc4/item/42.

Impact

GET → DELETE / PUT CSRF on any route registered for unsafe verbs.
Bypass of authentication, CSRF token, or rate-limiting middleware that is gated only on POST/DELETE.
CDN cache poisoning: the CDN caches the GET response body while the origin executed a DELETE.

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

A new flight.allow_method_override setting controls both override vectors. Operators can set it to false to disable X-HTTP-Method-Override and _method entirely.

Credit

Discovered by @Rootingg.

AnalysisAI

Flight PHP micro-framework (< 3.18.1) silently converts GET requests into DELETE or PUT operations via unvalidated X-HTTP-Method-Override headers or _method query parameters, enabling trivial CSRF attacks against destructive endpoints. Attackers can trigger resource deletion using simple HTML image tags without JavaScript or user interaction. The vulnerability bypasses middleware filters that gate only POST/DELETE verbs, and creates CDN cache poisoning scenarios where cached GET responses reflect executed DELETE operations. Patch available in version 3.18.1 introducing opt-in method override control (flight.allow_method_override setting). No active exploitation confirmed at time of analysis; publicly available exploit code exists in GitHub advisory.

Technical ContextAI

Flight PHP is a lightweight PHP micro-framework providing routing and HTTP request handling. The vulnerable code in Request::getMethod() (flight/net/Request.php lines 281-292) unconditionally processes HTTP method override mechanisms intended for REST API compatibility when browsers only support GET/POST. The implementation reads from PHP's $_REQUEST superglobal (aggregating $_GET, $_POST, and potentially $_COOKIE depending on request_order configuration) and the X-HTTP-Method-Override header without validation. This enables HTTP verb tampering attacks that violate RFC 9110 semantics by allowing safe methods (GET, HEAD) to be reinterpreted as unsafe methods (DELETE, PUT, PATCH) at the application layer. The root cause maps to CWE-436 (Interpretation Conflict) where the framework's method resolution logic conflicts with intended HTTP semantics and browser security model. The vulnerability affects all Flight PHP applications using versions prior to 3.18.1 (CPE pkg:composer/flightphp_core) that register routes for unsafe HTTP verbs, particularly REST-style resource endpoints.

RemediationAI

Upgrade to Flight PHP version 3.18.1 or later (released March 2025, confirmed by vendor at https://github.com/flightphp/core/releases/tag/v3.18.1 and commit b8dd23aaa828cb289fa3c84e75b2a3717cab50b0). For Composer-managed installations, run composer require flightphp/core:^3.18.1 and verify with composer show flightphp/core. Note that version 3.18.1 introduces the flight.allow_method_override configuration setting defaulting to true for backward compatibility - operators must explicitly set $app->set('flight.allow_method_override', false); during initialization to disable method override functionality if not required by legitimate API clients. For deployments unable to upgrade immediately, implement these compensating controls with noted trade-offs: (1) Add explicit method validation in route handlers or early middleware to reject requests where actual HTTP verb (from $_SERVER['REQUEST_METHOD']) differs from framework-resolved method, though this requires code changes in every protected endpoint. (2) Configure web server (Apache/nginx) rules to reject requests containing X-HTTP-Method-Override headers or _method parameters, though this breaks legitimate REST clients relying on method override for PATCH/PUT support. (3) Implement strict CSRF token validation in all DELETE/PUT/PATCH endpoint handlers independent of HTTP verb, though this only mitigates CSRF vectors and does not prevent middleware bypass or cache poisoning. (4) Review and refactor middleware authentication/rate-limiting to key on session/token state rather than HTTP verb assumptions, requiring potentially extensive code audit. Confirm patch application by testing that GET requests with ?_method=DELETE or X-HTTP-Method-Override: DELETE headers are dispatched as GET (when flight.allow_method_override is false) or testing that legitimate override requests still function (when true).