A vulnerability was found in Provision-ISR SH-4050A-2

CVE-2025-0224 is an unauthenticated remote information disclosure issue in multiple Provision-ISR CCTV recorders: SH-4050A-2, SH-4100A-2L(MM), SH-8100A-2L(MM), SH-16200A-2(1U), SH-16200A-5(1U), and NVR5-8200PX, affecting versions reported as up to 20241220. Public descriptions point at exposure through the /server.js path, with a public proof-of-concept noted by VulDB/NVD.

The vendor/CNA MEDIUM 5.3 score is technically defensible in a vacuum because the bug is remote, easy, and needs no auth. Operationally, though, this lands lower for most enterprises: it is confidentiality-only, requires the recorder to be reachable over its web path, and the affected population is a niche surveillance appliance class that is often segmented or NATed rather than broadly exposed like VPNs, email gateways, or identity services.

Why this verdict

• Downward pressure: confidentiality-only bug — the published impact is an unauthenticated info leak, not RCE, auth bypass, config tampering, or service kill.
• Downward pressure: attacker must reach the recorder UI — in practice that usually means direct internet exposure, permissive NAT/UPnP, or an already-internal foothold; each of those narrows the real victim pool materially.
• Downward pressure: weak threat signal — no KEV listing, no public campaign reporting in the checked sources, and EPSS remains near the floor even across differing snapshots.

Why not higher?

If this were tied to broad internet exposure, active exploitation telemetry, or a clean chain from leak to device takeover, it would climb fast. But today the public record shows a recon aid on a relatively narrow appliance set, not a high-volume enterprise intrusion primitive.

Why not lower?

I am not calling this IGNORE because it is still remote, unauthenticated, and publicly documented, with a named path and PoC signal. For organizations that do expose surveillance gear—or that protect sensitive physical spaces—the leaked device intelligence can absolutely support follow-on attacks.

1. Remove direct internet reachability — Block inbound access to recorder management interfaces from the public internet and force remote viewing/admin through VPN or a controlled jump path. For a LOW verdict there is no SLA (treat as backlog hygiene), but if any of these units are public-facing, do this in the next routine network change rather than waiting for firmware work.
2. Disable unnecessary remote features — Review and turn off UPnP, unused P2P, and any unnecessary DDNS or direct web publishing so the vulnerable path cannot be reached anonymously. For LOW, there is no SLA (treat as backlog hygiene); bundle it into the next surveillance-platform hardening cycle.
3. Inventory and segment the recorder fleet — Identify affected models, confirm firmware/build levels, and keep CCTV/NVR devices on a dedicated management or surveillance VLAN with tightly scoped ACLs. For LOW, there is no SLA (treat as backlog hygiene), but this is the control that most effectively reduces blast radius if another camera/NVR flaw appears later.

Run this from an auditor workstation or jump host that can reach the recorder's web UI. Invoke it as bash verify-cve-2025-0224.sh https://10.20.30.40 or bash verify-cve-2025-0224.sh http://nvr.example.local; it needs no credentials and no special privileges beyond network access to the target.

#!/usr/bin/env bash
# verify-cve-2025-0224.sh
# Basic remote exposure check for CVE-2025-0224 on Provision-ISR DVR/NVR devices.
# Exit codes:
#   0 = VULNERABLE
#   1 = PATCHED
#   2 = UNKNOWN / error / could not determine

set -u

if [ "$#" -ne 1 ]; then
  echo "UNKNOWN"
  exit 2
fi

TARGET="$1"
CURL_OPTS=(--silent --show-error --insecure --location --max-time 10)

# Normalize target URL.
if [[ ! "$TARGET" =~ ^https?:// ]]; then
  TARGET="http://$TARGET"
fi
TARGET="${TARGET%/}"

TMP_BODY="$(mktemp 2>/dev/null || echo /tmp/cve20250224_body.$$)"
TMP_HDR="$(mktemp 2>/dev/null || echo /tmp/cve20250224_hdr.$$)"
trap 'rm -f "$TMP_BODY" "$TMP_HDR"' EXIT

# Step 1: probe the published path anonymously.
HTTP_CODE=$(curl "${CURL_OPTS[@]}" -D "$TMP_HDR" -o "$TMP_BODY" -w "%{http_code}" "$TARGET/server.js" 2>/dev/null || true)
BODY_SIZE=$(wc -c < "$TMP_BODY" 2>/dev/null || echo 0)
CTYPE=$(grep -i '^content-type:' "$TMP_HDR" 2>/dev/null | tail -n1 | tr -d '\r' | cut -d' ' -f2-)

# Heuristic: anonymous 200/206 plus non-trivial JS/text body strongly suggests the exposed file is reachable.
if [[ "$HTTP_CODE" =~ ^(200|206)$ ]] && [ "$BODY_SIZE" -gt 128 ]; then
  if grep -Eqi '(javascript|text/plain|application/octet-stream)' <<< "$CTYPE" || grep -Eqi '(function|var |const |let |server|http|rtsp|ddns|p2p)' "$TMP_BODY"; then
    echo "VULNERABLE"
    exit 0
  fi
fi

# Step 2: try to find a newer firmware/build indicator on the landing page.
ROOT_BODY="$(mktemp 2>/dev/null || echo /tmp/cve20250224_root.$$)"
trap 'rm -f "$TMP_BODY" "$TMP_HDR" "$ROOT_BODY"' EXIT
ROOT_CODE=$(curl "${CURL_OPTS[@]}" -o "$ROOT_BODY" -w "%{http_code}" "$TARGET/" 2>/dev/null || true)

# Vendor pages currently show newer firmware strings such as RD251031 / v1.4.12_82272_RD251031.
# If the device UI leaks a clearly newer build marker, mark as PATCHED; otherwise stay conservative.
if [[ "$ROOT_CODE" =~ ^(200|401|403)$ ]] && grep -Eqi '(RD251031|v1\.4\.12_82272_RD251031)' "$ROOT_BODY"; then
  echo "PATCHED"
  exit 1
fi

# If /server.js is not reachable anonymously but we cannot confirm build level, do not overclaim.
echo "UNKNOWN"
exit 2

Sources

1. NVD entry
2. VulDB entry
3. CVEDetails entry
4. CISA KEV catalog
5. Provision-ISR NVR5-8200PX+(MM) product page
6. Provision-ISR Ossia NVR software page
7. Provision-ISR NVR5-8200PX manual/specifications