What is the CVSS score of CVE-2026-55863?

CVE-2026-55863 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N.

Is there a patch available for CVE-2026-55863?

Yes, a patch is available for CVE-2026-55863. Update the affected software to the latest version immediately.

motionEye CVE-2026-55863

EUVD-2026-78931 MEDIUM

Missing Authorization (CWE-862)

2026-06-23 https://github.com/motioneye-project/motioneye

GHSA-j67x-q29f-qcvv PYSEC-2026-2665

Authentication Bypass Python Docker SSRF

5.3

CVSS 3.1 · Vendor: https://github.com/motioneye-project/motioneye

Severity by source

Vendor (https://github.com/motioneye-project/motioneye) PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

vuln.today AI

5.3 MEDIUM

Fully network-accessible unauthenticated endpoint; integrity impact only since camera actions do not expose confidential data or directly deny service.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/motioneye-project/motioneye).

CVSS VectorVendor: https://github.com/motioneye-project/motioneye

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 23, 2026 - 19:03 vuln.today

Analysis Generated

Jun 23, 2026 - 19:03 vuln.today

DescriptionCVE.org

Summary

The ActionHandler.post() method in motionEye has no authentication decorator, allowing any unauthenticated attacker to trigger camera actions including snapshots, recording start/stop, and configured action scripts (PTZ controls, alarm triggers, etc.).

Vulnerability Details

File: motioneye/handlers/action.py - ActionHandler.post() line 36 CWE: CWE-862 - Missing Authorization CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3 Medium

Vulnerable Code

python

class ActionHandler(BaseHandler):
    async def post(self, camera_id, action):
# ← NO @BaseHandler.auth() decorator
        camera_id = int(camera_id)
        if camera_id not in config.get_camera_ids():
            raise HTTPError(404, 'no such camera')
        ...
        if action == 'snapshot':
            await self.snapshot(camera_id)
# executed without auth
            return
        elif action == 'record_start':
            return self.record_start(camera_id)
        elif action == 'record_stop':
            return self.record_stop(camera_id)

        action_commands = config.get_action_commands(local_config)
        command = action_commands.get(action)
        ...
        self.run_command_bg(command)
# executes predefined shell scripts

Compare with other handlers that correctly require authentication:

python

@BaseHandler.auth(admin=True)
# ← properly protected
async def delete(self, camera_id, filename):
    ...

Steps to Reproduce

Deploy motionEye with at least one camera configured
Send unauthenticated POST:

POST /action/1/snapshot HTTP/1.1
Host: motioneye-host:8765
Content-Length: 0

Observe {} (HTTP 200) response - snapshot triggered without any credentials

For action scripts (lock, unlock, alarm_on, alarm_off, light_on, etc.):

POST /action/1/alarm_on HTTP/1.1
Host: motioneye-host:8765

Impact

Unauthenticated attacker can trigger camera snapshots on demand
Unauthenticated attacker can start/stop video recording
If action scripts are configured by admin: attacker can trigger PTZ movement, alarm control, lighting changes - physical security bypass
Via remote cameras: SSRF by triggering action on a remote motionEye server

Verification

Dynamically confirmed on v0.43.1 in Docker lab - POST /action/2/snapshot with no credentials returns HTTP 200 {}. Server log shows the action was processed (failed only because motion daemon was not running for the test camera, not due to an auth rejection).

Recommended Fix

python

class ActionHandler(BaseHandler):
    @BaseHandler.auth()
# add authentication requirement
    async def post(self, camera_id, action):
        ...

AnalysisAI

Unauthenticated remote action execution in motionEye (pip/motioneye < 0.44.0) exposes every camera action endpoint - snapshots, recording start/stop, and administrator-configured shell scripts - to any attacker who can reach port 8765, due to a missing @BaseHandler.auth() decorator on ActionHandler.post(). Dynamically confirmed on v0.43.1 in a Docker lab environment; exploitation requires only a single HTTP POST with no credentials, headers, or user interaction. Beyond the CVSS 5.3 Medium rating, real-world impact extends to physical security bypass (PTZ, alarms, lighting controls) if action scripts are configured, and SSRF via remote camera triggering - no public exploit or CISA KEV listing is identified at time of analysis.

Technical ContextAI

motionEye is an open-source Python web frontend for the motion daemon, commonly deployed via Docker on port 8765 to manage IP cameras and USB webcams on Linux. The affected code is in motioneye/handlers/action.py, where ActionHandler inherits from BaseHandler but omits the @BaseHandler.auth() decorator that is correctly applied to other sensitive handlers (e.g., the admin-only delete endpoint). CWE-862 (Missing Authorization) is the root cause: the authorization mechanism exists and is used elsewhere in the codebase, but was never applied to the POST action handler. The /action/<camera_id>/<action> route accepts arbitrary action strings - built-in ones (snapshot, record_start, record_stop) and configured action scripts (lock, unlock, alarm_on, alarm_off, light_on) that invoke predefined shell commands via run_command_bg(). The affected package identifier is pkg:pip/motioneye, versions prior to 0.44.0.

RemediationAI

Upgrade to motionEye version 0.44.0 or later, which applies the @BaseHandler.auth() decorator to ActionHandler.post(), aligning it with the authorization pattern used by other protected handlers. The fix is referenced in GHSA-j67x-q29f-qcvv at https://github.com/motioneye-project/motioneye/security/advisories/GHSA-j67x-q29f-qcvv. For Docker deployments, pull the updated image tagged 0.44.0 or later. If immediate patching is not feasible, restrict network access to port 8765 via firewall rules so that only trusted hosts can reach the motionEye interface - this eliminates the network attack vector entirely and is the most effective compensating control. Alternatively, place motionEye behind an authenticating reverse proxy (e.g., nginx with HTTP basic auth or mTLS) to enforce credential checks at the network boundary before requests reach the vulnerable handler; note this adds operational overhead for legitimate integrations. Do not expose motionEye directly to the internet on unpatched versions.