CVE-2026-33183: Path Traversal in Saloon PHP Fixture Management

The Saloon PHP library provides a robust framework for building API integrations and SDKs. Within this ecosystem, the MockResponse fixture system enables developers to record and replay API responses for testing and development purposes. This system relies on the filesystem to store and retrieve recorded responses, using a designated base directory for organizational boundaries.

Versions of Saloon prior to 4.0.0 suffer from an Improper Limitation of a Pathname to a Restricted Directory vulnerability (CWE-22). The vulnerability manifests within the fixture management implementation, specifically in how the library processes fixture names to generate file paths. The system fails to sanitize input for directory traversal sequences before initiating filesystem operations.

Exploitation requires that an application utilizing Saloon permits external or untrusted input to define or influence the name of a requested fixture. When an application passes dynamic input to the MockResponse::fixture() method without preceding validation, an attacker can manipulate the resolution path. The severity of the impact depends on whether the application is configured to read existing fixtures or record new ones.

The fundamental flaw exists in the interaction between the Saloon\Http\Faking\Fixture and Saloon\Helpers\Storage classes. The Fixture class accepts a string parameter representing the name of the desired mock response. This string acts as the primary identifier for the corresponding JSON file on the disk.

Prior to the 4.0.0 patch, the Fixture::getFixturePath() method assumed the provided name was structurally safe. It directly concatenated the input string with a .json file extension. The method lacked any mechanism to detect or strip directory traversal sequences, such as ../ or ..\, allowing these characters to persist into the subsequent storage resolution phase.

The Storage class is responsible for managing the physical filesystem interactions. Its buildPath() method utilized simple string concatenation to join the configured base fixture directory with the relative path supplied by the Fixture class. The implementation did not employ path canonicalization techniques, nor did it verify that the final absolute path resolved to a location within the designated base directory.

Consequently, the operating system natively resolved the traversal sequences embedded in the concatenated string. If an attacker supplied a payload containing multiple parent directory sequences, the resolution process escaped the intended storage root, allowing direct read or write access to arbitrary locations on the host filesystem subject to the permissions of the PHP process.

In vulnerable versions, the application accepted fixture names directly into the path construction logic. The absence of a robust validation layer meant that input strings like ../../../../etc/passwd were blindly processed as valid file identifiers. This directly violated secure coding principles regarding filesystem boundary enforcement.

The 4.0.0 release resolves this vulnerability by implementing a multi-layered defense strategy. The primary mitigation introduces strict input validation within the src/Http/Faking/Fixture.php file. The developers implemented a regular expression whitelist and specific character checks to reject traversal sequences outright.

if (str_contains($name, "\0") || str_contains($name, '..') || str_contains($name, '~')
    || ! preg_match('/^[a-zA-Z0-9\/_\-\\]+$/', $name)) {
    throw new FixtureException('The fixture name must not contain directory traversal components or invalid characters.');
}

As a defense-in-depth measure, the maintainers modified the src/Helpers/Storage.php file to establish a filesystem jail. They introduced the normalizePath method to manually resolve structural segments without accessing the filesystem, and the ensurePathUnderBase method. This latter method uses the realpath() function on the base directory and strictly compares it against the requested target, throwing an exception if the target resides outside the designated boundary. This combination completely neutralizes the traversal vector.

Exploiting this vulnerability in a read context (Local File Disclosure) requires identifying an application endpoint that incorporates user input into the mock fixture selection process. For example, a developer might expose a debug parameter via an HTTP GET request to dynamically load specific mock states during staging.

The attacker crafts an HTTP request containing a traversal payload in the vulnerable parameter. By supplying a string such as ../../../../etc/passwd, the application passes the payload to Saloon's fixture handler. Saloon attempts to load [BASE]/../../../../etc/passwd.json. If the application host possesses a file matching the exact string with the .json extension appended, or if the system ignores the extension under specific conditions, the contents are returned as the mocked API response.

The vulnerability also presents a write-based attack vector if the application operates in "record" mode. In this state, Saloon captures live API responses and saves them to the disk for future use. If the attacker can influence the fixture name during a recording event, they gain the ability to dictate the destination file path.

By supplying a payload like ../public/payload.php, the attacker forces Saloon to write the recorded JSON response outside the temporary fixture directory. If the attacker can predict or manipulate the contents of the recorded API response to include executable code (e.g., PHP tags), and if the application's web server executes .json files or the attacker bypasses the extension appending, this flaw escalates to remote code execution.

The definitive remediation for this vulnerability is to upgrade the saloonphp/saloon dependency to version 4.0.0 or later. This version contains the comprehensive structural fixes, including the regex whitelisting and the realpath-based filesystem jail, which eliminate the root cause of the path traversal.

Developers must audit their application codebases to identify any instances where user-supplied data interacts with the MockResponse::fixture() method or the Fixture class constructor. Applications should never pass unvalidated external input directly into file path construction mechanisms. Implement strict allowlisting for any dynamic fixture selection logic.

Administrators should enforce the principle of least privilege at the operating system level. The PHP process executing the application must operate with the minimum filesystem permissions necessary. Restricting write access to only designated temporary or upload directories prevents attackers from overwriting critical application code or configuration files, mitigating the impact of the write-based exploitation scenario.

Organizations should deploy Web Application Firewall (WAF) rules to detect and block incoming HTTP requests containing common directory traversal patterns. Signatures targeting ../, ..\, and URL-encoded variants (%2e%2e%2f) provide a secondary layer of defense against exploitation attempts while systems undergo the patching process.