CareCam Pro ANJIA AJL33PC0801 Hard-Coded Bootloader Credential

CVE-2026-85083 is a hard-coded credential in the U-Boot bootloader of the ANJIA AJL33PC0801 IP camera, sold under the CareCam Pro brand. The affected firmware is linux_linux_202008261138_svn13796 with U-Boot 2010.06 compiled 2020-08-26. An attacker who has physical access to the device can authenticate to the bootloader console (typically via UART serial pins on the PCB) and from there modify firmware, inject implants, or brick the device. The attack vector is AV:P — physical — and no network-based exploitation path exists.

CISA assigned CVSS v3.1 6.8 MEDIUM and CVSS v4.0 7.0 HIGH, which is mechanically correct for full-CIA impact at the device level with no privileges or interaction required. But for an enterprise patch queue those scores overstate real-world urgency. Physical access to an IoT camera's debug port is a red-team curiosity, not an operational threat to your fleet. The vendor (CareCam, Shenzhen-based) has gone silent on CISA coordination and there is no patch available, which paradoxically makes this easier to triage: you can't patch it anyway, so compensating controls are the only play.

Why this verdict

• Physical access gate is absolute. AV:P means the attacker must be on-site, open the housing, and connect serial hardware. This is not scalable and cannot be weaponized remotely. This alone warrants a substantial downward adjustment from the mechanical CVSS 6.8.
• Blast radius is single-device. Even full compromise of the camera yields control of one IoT endpoint. The CVSS v4.0 vector explicitly scores SC:N/SI:N/SA:N — no subsequent-system impact. There is no pivot to AD, no credential relay, no supply-chain lever.
• Role multiplier: IP cameras occupy no high-value role. They are not identity infrastructure, hypervisors, CI/CD, backup servers, or network edge appliances. In the deployment-role spectrum they sit squarely in category (a) — low-value IoT peripheral. Even if compromised, the worst realistic outcome is camera-level persistence or Wi-Fi PSK leakage (which only matters if network segmentation is already broken). The high-value role floor does not apply.
• No remote exploitation path, no PoC, no KEV, no in-the-wild activity. Every threat-intelligence signal is cold. EPSS is not yet scored but would predictably land in the bottom decile given physical-only access.

Why not higher?

To warrant MEDIUM or above, a vulnerability needs either a remote attack vector, a blast radius beyond a single low-value device, or active exploitation evidence. CVE-2026-85083 has none of these. The physical access requirement alone caps practical severity — you cannot scan for it, you cannot spray it, you cannot chain it into a remote kill-chain. Enterprise defenders have zero reason to prioritize this over any remotely exploitable issue in their queue.

Why not lower?

IGNORE would be appropriate if the product were not present in the environment at all or if a patch existed that had already been deployed. Since CareCam Pro cameras do ship into commercial facilities and there is no vendor patch (and may never be one given vendor silence), the vulnerability represents a residual physical-security risk worth documenting. Dropping to IGNORE could leave a compliance gap for organizations subject to ICS/IoT audit frameworks (e.g., NIST 800-82).

1. Segment cameras onto a dedicated IoT VLAN with no route to production subnets — This is the single highest-value control. Even if an attacker physically tampers with the camera and extracts Wi-Fi credentials, segmentation prevents lateral movement to anything that matters. Should already be in place; verify it. As a LOW-severity item there is no noisgate mitigation SLA — treat as backlog hygiene.
2. Restrict physical access to camera mounting locations — Tamper-resistant mounting brackets, locked enclosures, and facility access controls raise the bar for the only attack vector that matters. Review physical security during next scheduled site audit.
3. Monitor camera network behavior for anomalies — After physical tamper, a backdoored camera may beacon to C2 or scan the local subnet. A simple NetFlow or IDS rule on the IoT VLAN for unexpected outbound connections provides post-compromise detection.
4. Plan for device replacement — With no vendor patch and an unresponsive manufacturer, the long-term fix is replacing CareCam Pro units with a supported product. Add to your next hardware refresh cycle.

Run this on any Linux/macOS workstation where you manage your asset inventory. It checks whether any ANJIA AJL33PC0801 or CareCam Pro devices are present in your network inventory CSV (exported from your CMDB or network scanner). Invoke as: bash check_carecam.sh /path/to/asset_inventory.csv. No special privileges needed.

#!/usr/bin/env bash
# check_carecam.sh — Detect CareCam Pro / ANJIA AJL33PC0801 in asset inventory
# Usage: bash check_carecam.sh <inventory.csv>
# Exit codes: 0 = VULNERABLE (devices found), 1 = PATCHED/NOT_AFFECTED, 2 = UNKNOWN

set -euo pipefail

INVENTORY="${1:-}"

if [ -z "$INVENTORY" ] || [ ! -f "$INVENTORY" ]; then
  echo "UNKNOWN — provide a valid asset inventory CSV as argument"
  echo "Usage: bash check_carecam.sh /path/to/inventory.csv"
  exit 2
fi

# Case-insensitive search for known identifiers
MATCHES=$(grep -ciE 'AJL33PC0801|CareCam|ANJIA|carecam.pro' "$INVENTORY" 2>/dev/null || true)

if [ "$MATCHES" -gt 0 ]; then
  echo "VULNERABLE — found $MATCHES asset(s) matching CareCam Pro / ANJIA AJL33PC0801"
  echo "Review these entries and verify network segmentation:"
  grep -niE 'AJL33PC0801|CareCam|ANJIA|carecam.pro' "$INVENTORY" | head -20
  exit 0
else
  echo "PATCHED — no CareCam Pro / ANJIA devices found in inventory"
  exit 1
fi

Sources

1. CISA ICS Advisory ICSA-26-251-01
2. ISSSource — No Fix for CareCam Pro IP Cameras
3. Technobezz — CISA Warns of Hard-Coded Credential in CareCam Pro
4. Elastic camera-hacks repository (AJCloud family research)
5. ANJIA PTZ IP Camera Teardown (innerfirez)
6. CISA Known Exploited Vulnerabilities Catalog