CVE-2026-87690 in Metasploit Framework
Summary
by MITRE • 10/12/2026
The Metasploit Framework post module post/apple_ios/gather/ios_image_gather is affected by a relative path traversal vulnerability (CWE-22). The module interpolates file names taken from a Meterpreter directory listing — data fully controlled by a hostile or tampered iOS device — directly into the local destination path passed to client.fs.file.download_file(), with no sanitization. The underlying stdapi sink (lib/rex/post/meterpreter/extensions/stdapi/fs/file.rb) writes to whatever path is supplied, so a listing entry such as ../../msfconsole.rc escapes the intended ~/.msf4/loot/<random> directory and overwrites ~/.msf4/msfconsole.rc, a resource file that every msfconsole invocation automatically executes at startup (lib/msf/ui/console/driver.rb:196). An attacker-controlled device that lures an operator into running this gather module achieves an arbitrary file write as the operator; because the written msfconsole.rc can load a second written file (a Ruby plugin whose top-level code runs on require), this converts into persistent code execution and an interactive shell as the operator (frequently root) on the pentester's workstation at the next console launch. The same traversal was previously fixed upstream in the recursive downloader (stdapi/fs/dir.rb scrubs separators); this module omitted the equivalent scrub. The fix applies the same separator scrub (or File.basename) to listing entries before building the local path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The Metasploit Framework post module for iOS image gathering contains a critical relative path traversal vulnerability that allows an attacker to achieve arbitrary file write and subsequent persistent code execution on the operator's workstation. This flaw, classified under CWE-22 Improper Limitation of a Pathname to a Restricted Directory, stems from insufficient input validation when handling filenames retrieved from a compromised or tampered iOS device. The module retrieves directory listings via Meterpreter and directly interpolates these file names into local destination paths without any sanitization checks. Because the data originates from an external source controlled by a hostile actor, this represents a classic case of untrusted data being used to construct system-level operations, bypassing intended security boundaries.
The technical mechanism of exploitation relies on the behavior of the underlying stdapi sink within the Metasploit Framework. When the module calls client.fs.file.download_file(), it passes a path constructed from the unsanitized filename entries. An attacker can craft directory listing entries containing relative path traversal sequences, such as ../../msfconsole.rc. These sequences allow the file write operation to escape the intended loot directory and target arbitrary locations on the local filesystem. In this specific instance, the vulnerability targets ~/.msf4/msfconsole.rc, a configuration resource file that is automatically executed every time the msfconsole interface starts up. This design choice, while convenient for loading user-defined commands, creates a high-value attack surface when combined with path traversal flaws in modules that handle external data.
The operational impact of this vulnerability extends beyond simple arbitrary file write to persistent code execution and interactive shell access as the operator. By overwriting msfconsole.rc, an attacker can inject malicious Ruby code or load additional plugins stored on the filesystem. Since these files are executed during console initialization, any subsequent launch of Metasploit by the pentester will trigger the payload. This effectively converts a post-exploitation gathering module into a persistence mechanism, granting the attacker full control over the operator's environment. The severity is heightened because operators often run msfconsole with elevated privileges, potentially resulting in root-level access on the workstation.
This vulnerability mirrors issues previously addressed in other parts of the Framework, such as the recursive downloader which correctly scrubs path separators to prevent similar escapes. However, this specific post module omitted those protective measures during its implementation or maintenance cycle. The resolution involves applying consistent input sanitization practices across all modules that handle external filenames. Specifically, implementing a separator scrub or using File.basename on listing entries before constructing local paths ensures that only the final filename component is used, effectively neutralizing relative path traversal attempts. This fix aligns with industry best practices for secure coding and mitigates the risk of CWE-22 in contexts where user-controlled data influences file system operations.