CVE-2025-60787 affects MotionEye v0.43.1b4 and earlier. The vulnerability is an OS command injection issue in configuration parameters such as image_file_name. MotionEye writes user-supplied configuration values into Motion configuration files without sufficient sanitization. A remote authenticated attacker with ადმინისტ্রator access can inject command content via these parameters, and the injected commands are executed when the Motion service/process is restarted.
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.
7 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (4 hidden).
Small single-script Python exploit repository for CVE-2025-60787 targeting motionEye <= 0.43.1b4. Repository structure is minimal: one main exploit script (CVE-2025-60787.py), a README with usage and vulnerability explanation, requirements.txt listing requests/urllib3, and .gitignore. The exploit is a real authenticated RCE PoC, not merely a detector. Its core purpose is to reproduce command injection in motionEye by generating valid signed API requests, retrieving camera configuration, modifying the image_file_name setting with attacker-controlled shell syntax, enabling snapshot-related settings as needed, and then triggering a snapshot so the injected value is processed by Motion. The script appears operational rather than framework-based: it includes CLI parsing, target validation, request-signing helpers that mirror motionEye legacy signature behavior, configuration fetch/update logic, snapshot triggering, optional dry-run/debug modes, and optional restoration of original configuration. Main exploit capability is arbitrary command execution as the motionEye/Motion process user; reverse shell mode is supported through attacker-provided callback host/port. Fingerprintable target-facing endpoints documented in the repository include /config/list/ for configuration retrieval and /action/<camera_id>/snapshot/ for execution trigger, with the vulnerable sink being the image_file_name camera setting. The exploit requires authenticated access plus the stored password hash/value used as the signing key, making it an authenticated web/network attack against the motionEye API.
This repository is a small standalone exploit repo containing one Python proof-of-concept exploit (CVE-2025-60787.py) and a detailed README. It targets motionEye v0.43.1b4 and exploits an OS command injection in the image_file_name camera configuration field. The script reproduces motionEye's request-signing logic, derives the cookie hash from a known admin password hash, and attempts signed POST requests to /config/{cam}/set/ for camera IDs 0, 1, and 2. The malicious configuration embeds a command in image_file_name using $(command), then triggers snapshots through the motion control service on port 7999 so the injected command executes when motion evaluates the filename. The default payload is a Python reverse shell to a hardcoded LHOST/LPORT, and the README also documents alternative shell payloads. Structurally, the repo is straightforward: the Python file contains the exploit logic, payload builder, signature generation, HTTP request handling, and snapshot trigger flow; the README explains prerequisites, authentication/signature derivation, expected output, and troubleshooting. This is a real exploit, not a detector, and it is operational rather than framework-based.
This repository is a small standalone Python proof-of-concept exploit for CVE-2025-60787, an authenticated OS command injection / RCE vulnerability in motionEye <= 0.43.1b4. The repo contains four files: a MIT LICENSE, a README with vulnerability and usage documentation, a requirements.txt listing requests, and a single executable script, exploit.py, which is the main entry point. The exploit is not part of a larger framework. Its structure is straightforward: helper routines create a requests session, optionally disable TLS verification, support proxying, and compute motionEye’s request signature scheme using SHA-1 over canonicalized request components. Core logic then authenticates to the target via /login/, enumerates cameras via /config/list/, selects a camera (either specified or default), and submits a modified camera configuration through a config-setting endpoint to inject a malicious image_file_name value. The README indicates the injected value is written into /etc/motioneye/camera-*.conf and later executed by the Motion service when snapshot processing occurs. Capabilities: the script supports two operator-facing modes: command execution and reverse shell. In command mode, the user supplies an arbitrary command string with -e/--exec. In reverse-shell mode, the user supplies an attacker host and port, and the exploit builds a shell-based callback payload, with an option to use /bin/sh instead of /bin/bash. Additional operational features include target URL validation, camera selection, timeout handling, SIGINT handling, optional TLS certificate verification bypass, and HTTP/HTTPS proxy support. From the available code and documentation, this is a real exploit rather than a detector. It requires valid motionEye credentials and reachable network access to the web UI/API, so the attack vector is authenticated network exploitation against the motionEye HTTP interface. The exploit appears operational rather than merely demonstrative because it automates authentication, target enumeration, payload injection, and execution workflow, but it is still a simple standalone script with basic hardcoded payload behavior rather than a highly modular framework module.
Repository contains a single Python PoC exploit script (CVE-2025-60787.py) and a README. The exploit targets motionEye (<= 0.43.1b4 per README) and achieves authenticated remote code execution by abusing motionEye’s signed request mechanism and configuration endpoints. Core flow in the script: 1) Auth step: builds a signed GET request to /login/ with _username and a computed _signature (SHA1-based) derived from HTTP method, canonicalized path/query, request body, and SHA1(password). It checks for HTTP 200 vs 403. 2) Recon/selection: queries /config/list/ to enumerate cameras and select a camera ID (either user-specified --camera-id or the first discovered). 3) Exploitation: sends a signed POST to /config/0/set/ with a JSON body that modifies a camera configuration field to include a shell payload. Two operator modes are supported: - revshell: injects a reverse shell command that connects back to attacker-supplied host/port, using /bin/bash by default or /bin/sh with --sh. - command: injects an arbitrary command provided via -e/--exec. The exploit is network-based, requires valid credentials (authenticated), and is operational (provides working payload delivery for reverse shell/command execution) rather than a mere detector.
Repository contains a single Python exploit (exploit.py) and a short README describing CVE-2025-60787: an authenticated RCE in MotionEye <= 0.43.1b4. The exploit is network-based and interacts with MotionEye's HTTP API on the default port 8765. Core logic in exploit.py: - Implements MotionEye request signing by computing an _signature query parameter (SHA1 over a canonicalized string including method, path+query, JSON body, and SHA1(password)). This is used for both GET and POST requests. - Authenticates by calling GET /config/main/get/ with _username and computed _signature. - Auto-detects a camera ID via GET /config/list/ (falls back to ID 1). - Retrieves the camera configuration via GET /config/{id}/get/. - Updates the configuration to enable interval snapshots and sets image_file_name to a command-injection payload using shell substitution $(...) that runs python3 to execute a bash reverse shell to the attacker-supplied LHOST/LPORT. - Sends the modified configuration via POST /config/{id}/set/ with JSON body and signed query parameters. Outcome: if the target accepts the configuration and later uses image_file_name in a shell context (as implied by the vulnerability description: client-side validation bypass on image_file_name), the injected command executes and connects back to the attacker listener, yielding a reverse shell.
Repository contains a small Python proof-of-concept exploit for CVE-2025-60787 targeting MotionEye (<= 0.43.1b4). Structure: (1) README.md describing the bug as a client-side validation bypass leading to server-side command injection via a filename field written into camera config files; includes install and usage examples. (2) exploit.py implements a network-based attack using requests.Session against a MotionEye instance (default port 8765). The exploit performs a GET to /login as a basic connectivity check, then sends a POST to /config/1/set with `picture_filename` set to a payload of the form `$(<cmd>) %Y-%m-%d/%H-%M-%S`, leveraging shell substitution to execute arbitrary OS commands when MotionEye reloads configuration or restarts. Notable limitations/bugs: the script accepts username/password but does not use them to authenticate; and the entry-point guard is incorrect (`if name == "__main__":` instead of `if __name__ == "__main__":`), meaning the script as written will not run unless fixed. No additional modules, scanners, or framework integration are present.
This repository contains a single Metasploit module targeting a remote code execution (RCE) vulnerability (CVE-2025-60787) in the MotionEye Frontend (versions 0.43.1b4 and prior). The exploit leverages a template injection vulnerability in configuration parameters (such as image_file_name) that are written unsanitized to configuration files. The attacker must have valid admin credentials to the MotionEye web interface. The module authenticates to the web interface, adds a new camera configuration with a malicious payload, sets the exploit parameter, and triggers the code execution by requesting a snapshot. The exploit supports arbitrary command execution and can be used to obtain a reverse shell or Meterpreter session. The module also includes cleanup functionality to remove the malicious configuration after exploitation. The main attack vector is network-based, targeting the HTTP interface of MotionEye. The endpoints used in the exploit process are clearly defined and fingerprintable. The code is written in Ruby and is structured as a standard Metasploit exploit module.
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.
9 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
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.