# GHSA-qxvg-h7q2-hcxh: motionEye: LFI → pass‑the‑hash admin → unsafe restore → unauth action exec (RCE)

> Attackers can achieve remote code execution via a chain of path traversal, hash leakage, and unsafe file extraction in motionEye.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 23 Jun 2026

## What is GHSA-qxvg-h7q2-hcxh?

GHSA-qxvg-h7q2-hcxh is a path traversal vulnerability in motioneye, published on 23 Jun 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## Summary
A multi‑stage chain in motionEye leads to remote code execution. The chain combines:

1. **Arbitrary file read (LFI)** via the picture download endpoint for **local motion cameras** using absolute paths.
2. **Pass‑the‑hash admin auth** due to accepting request signatures computed with password hashes.
3. **Unsafe config restore** that extracts attacker‑controlled tarballs into `CONF_PATH`.
4. **Unauthenticated action execution** via `/action/<id>/<action>`.

If the **normal user password is unset**, the chain becomes **unauthenticated RCE**. If a normal password exists, a **normal user** can still achieve **admin escalation and RCE**.

---

## Affected Code (motionEye repo)

### 1) LFI (absolute path) — `picture/<id>/download`
**Files:**
- `motioneye/motioneye/handlers/picture.py` → `download()` (local motion camera branch)
- `motioneye/motioneye/mediafiles.py` → `get_media_content()`

**Issue:** `get_media_content()` only blocks `..` and then joins `target_dir` with `path`. Absolute paths (e.g. `/etc/hosts`) bypass the join and are read directly.

### 2) Pass‑the‑hash admin auth
**File:** `motioneye/motioneye/handlers/base.py` → `get_current_user()`

**Issue:** The signature check allows signatures computed using the **admin password hash** (SHA1) as the key. If the hash is leaked (via LFI), admin access can be obtained without the plaintext password.

### 3) Unsafe restore (tar extraction)
**File:** `motioneye/motioneye/config.py` → `restore()`

**Issue:** `tar zxC CONF_PATH` is used on user‑supplied data without sanitizing entries. A crafted tar can drop executable files into `CONF_PATH`.

### 4) Unauthenticated action execution
**File:** `motioneye/motioneye/handlers/action.py` → `post()`

**Issue:** No authentication decorator is present. It executes `<action>_<camera_id>` found in `CONF_PATH` with `subprocess.Popen`.

---

## Exploit Chain (Detailed)

1. **Create or find a local motion camera id** (local motion cameras are required for the vulnerable LFI path).
2. **LFI via picture download**:
   - Request: `/picture/<id>/download/<absolute_path>`
   - Example: `/picture/1/download/%2Fetc%2Fhosts`
   - Result: Arbitrary file read.
3. **Read admin hash** from `/etc/motioneye/motion.conf`:
   - Contains `@admin_password <SHA1_HASH>`.
4. **Pass‑the‑hash admin**:
   - Compute signature for `/config/restore?_username=admin` using the **hash** as key.
   - Admin access is accepted with hash‑based signatures.
5. **Restore malicious tar**:
   - Upload a tar containing `lock_<id>` (or any action) as an executable.
   - File is written into `CONF_PATH` by restore.
6. **Trigger unauth action**:
   - POST `/action/<id>/lock`
   - The server executes the injected file.

---

## Proof of Execution (Observed Output)
In local testing, the injected action created a marker file:

```
/tmp/meye_rce_ok
```

Verification command:
```
docker exec -it motioneye ls -la /tmp | grep meye_rce_ok
```
Example output:
```
-rw-r--r-- 1 root root 0 ... /tmp/meye_rce_ok
```

---

## Preconditions / Requirements

- At least **one local motion camera** exists (e.g., `netcam_url`, `videodevice`).
- `picture/<id>/download` is reachable:
  - **Unauth** if `@normal_password` is empty (default in some installs).
  - **Auth required** if normal password is set (attacker needs normal creds).

---

## Impact
- **Unauth RCE** (normal password unset).
- **Authenticated RCE** (normal user → admin → RCE).
- Arbitrary file read on server filesystem.
- Full compromise of motionEye process account.

---

## Suggested Fixes
1. **Block absolute paths** in `get_media_content()` and `get_media_path()`.
2. **Remove hash‑based signature acceptance**; only accept signatures computed with plaintext passwords.
3. **Harden restore**: reject absolute paths, `..`, symlinks, non‑regular files.
4. **Require authentication** on `ActionHandler` (admin‑only).

## Which versions are affected by GHSA-qxvg-h7q2-hcxh?

2 open source packages ship an affected version, including motioneye.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `motioneye` | PyPI | All versions | 0.44.0 |
| `motioneye` | PyPI | All versions | 0.44.0 |

## How do I fix GHSA-qxvg-h7q2-hcxh?

Upgrade motioneye to 0.44.0 or later.

## Is GHSA-qxvg-h7q2-hcxh being exploited?

There is no known exploitation of GHSA-qxvg-h7q2-hcxh in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-qxvg-h7q2-hcxh and fix it if it is affected.

What it is: GHSA-qxvg-h7q2-hcxh is a path traversal vulnerability in motioneye, published on 23 Jun 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-qxvg-h7q2-hcxh in the wild and no public exploit code.

Affected packages and fixed versions:
- motioneye (PyPI): affected all versions; fixed in 0.44.0
- motioneye (PyPI): affected all versions; fixed in 0.44.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-qxvg-h7q2-hcxh/ (Markdown: https://insights.sbomify.com/GHSA-qxvg-h7q2-hcxh/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-qxvg-h7q2-hcxh

---
From sbomify Insights: https://insights.sbomify.com/GHSA-qxvg-h7q2-hcxh/
Summaries are generated and may contain mistakes; the official description above is the record.