Responsive Filemanager through 9.14.0 contains an arbitrary file upload vulnerability in ajax_calls.php via the save_img action. The 'name' parameter is not validated for file extension, allowing an attacker to upload files with a .php extension. If a JPEG image is crafted to contain PHP code in its EXIF data and uploaded with a .php extension, the server may execute the embedded PHP code, leading to remote code execution.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
3 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone exploit PoC for CVE-2020-10567 affecting Responsive Filemanager 9.14.0 (explicitly noted as a vulnerable non-main branch version). It contains two files: a Python exploit script and a README with usage examples and background. The Python script uses argparse for CLI input, requests for HTTP interaction, and base64 to encode a PHP payload. Its workflow is straightforward: optionally accept a user-provided PHPSESSID cookie, otherwise request /filemanager/dialog.php to obtain one; generate a PHP webshell that wraps an attacker-supplied command in shell_exec; base64-encode that PHP code and submit it as a data URI to /filemanager/ajax_calls.php?action=save_img with the filename shell.php; then request /source/shell.php to execute the uploaded payload and print the command output. The exploit’s main capability is unauthenticated or low-friction remote code execution through arbitrary file upload to a web-accessible path. It is not a scanner or detector; it is an actual exploitation script with a hardcoded but effective payload path and filename. The repository is minimal, operational, and purpose-built for direct exploitation rather than framework integration or post-exploitation automation.
This repository is a small, focused proof-of-concept exploit for CVE-2020-10567 affecting Responsive Filemanager v9.14.0. It contains two files: a single Python exploit script and a README with usage examples and vulnerability context. The Python script is the main entry point and uses the requests, argparse, and base64 libraries. The exploit workflow is straightforward: it accepts a target base URL and an arbitrary command, optionally takes a PHPSESSID cookie, and if no cookie is provided it first requests /filemanager/dialog.php to obtain one. It then generates a PHP payload that wraps the operator's command in shell_exec(), base64-encodes that PHP code, and submits it to /filemanager/ajax_calls.php?action=save_img using a crafted data URL value (data:image/jpeg;base64,...). The uploaded file is named shell.php. After upload, the script requests /source/shell.php to execute the payload and print the command output. The exploit's main capability is unauthenticated remote code execution via arbitrary file upload leading to a webshell. It is not a scanner or detector; it actively weaponizes the vulnerability by planting a PHP shell and invoking it immediately. The code is operational but simple: the payload is hardcoded to a single command execution model, with no advanced staging, persistence, or obfuscation. The README confirms the intended target, notes that the issue is unauthenticated, and provides example commands such as id and cat /etc/passwd. Overall, this is a compact operational RCE PoC demonstrating upload-to-webshell exploitation against a vulnerable Responsive Filemanager deployment.
This repository is a small standalone proof-of-concept exploit for CVE-2020-10567 affecting Responsive Filemanager v9.14.0. It contains two files: a Python exploit script and a README with usage examples. The Python script is the main entry point and uses the requests library to interact with the vulnerable web application. Exploit flow: the script accepts a target base URL, an arbitrary command to run, and optionally a PHPSESSID cookie. If no cookie is provided, it performs a GET request to /filemanager/dialog.php to collect a session cookie. It then builds a PHP payload containing shell_exec('<command>'), base64-encodes it, and submits it to /filemanager/ajax_calls.php?action=save_img using a data URI beginning with data:image/jpeg;base64,. The POST body sets the uploaded filename to shell.php. After upload, the script requests /source/shell.php, which executes the embedded command on the server and returns the output in the HTTP response body. The exploit’s main capability is unauthenticated remote code execution through arbitrary file upload and subsequent execution of the uploaded PHP file. It is not merely a detector; it actively weaponizes the vulnerability by planting a webshell-like PHP script. The payload is basic and hardcoded to a single command per run, so the maturity is best classified as OPERATIONAL rather than framework-grade weaponized. Repository structure is minimal: README.md documents the vulnerability, states that no authentication is required, and provides example invocations showing command execution such as id and cat /etc/passwd. There is no framework integration, no persistence logic beyond leaving shell.php on the server, and no cleanup routine. The code is concise and purpose-built to demonstrate exploitation of the vulnerable save_img handler and retrieval of command output.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
No public activity tracked yet. Mallory keeps watching.
No public activity observed for this vulnerability.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.