This is a master key left in the guard shack, not a citywide skeleton key
CVE-2024-2420 is a hardcoded-credentials flaw in LenelS2 NetBox that affects versions through 5.6.1 and is fixed in 5.6.2. In plain English: if an attacker can reach the NetBox management surface, they may be able to bypass normal authentication by using credentials embedded in the product itself. Because NetBox is a browser-based physical access control and event monitoring appliance, compromise can spill into badgeholder data, door-control policy, alarm workflows, and audit visibility.
The raw 9.8 score overstates the average enterprise risk because it treats every vulnerable instance like a directly reachable internet service. In reality, NetBox is a specialized physical-security platform that is typically segmented, VPN-gated, or restricted to admin workstations; that reachability assumption is the main downward pressure. Still, if your deployment is exposed to untrusted networks, this is a bad HIGH rather than a MEDIUM because the credentials are universal, exploitation is low-friction once reachable, and the business impact crosses into physical security.
4 steps from start to impact.
Find a reachable NetBox management interface
nmap or httpx and fingerprinting a browser-based admin appliance. Vendor material explicitly describes NetBox as browser-accessible and supports remote web-browser use, which means the reachable surface exists wherever segmentation was done poorly.- The attacker has direct internet reachability, VPN access, or an internal foothold into the security/OT segment
- A vulnerable NetBox instance at version 5.6.1 or earlier is online
- Many enterprises keep physical-security platforms off the public internet
- VPN, jump hosts, NAC, internal firewalls, or dedicated security VLANs often block this first step
Use the embedded credentials to bypass normal login
- The attacker knows or can recover the hardcoded credential path
- The target is still running a vulnerable build
- I did not find a public weaponized exploit repo in the sourced material
- Some deployments may add compensating IP restrictions in front of the interface
Operate inside the physical-security plane
- The compromised account path lands with sufficient privileges in NetBox
- The target deployment actually controls doors, alarms, or integrated video/event workflows
- Privilege separation or role scoping can limit what the session can change
- Some dangerous changes may create obvious operational noise for guards or facilities staff
Translate cyber access into business and physical impact
- The compromised NetBox instance is a central or enterprise deployment
- The attacker maintains enough access to make or stage changes
- Many organizations operationally notice door anomalies faster than they notice server anomalies
- Blast radius depends heavily on whether the appliance is a small local controller or a large enterprise deployment
- Changing normal operator passwords alone does not fix a hardcoded credential flaw; the backdoor path is embedded in the product.
- EDR on user laptops does not reliably cover appliance-side abuse after successful login to NetBox.
- MFA on adjacent identity systems is not a guaranteed control here if the vulnerable path authenticates through product-embedded credentials rather than your normal IdP flow.
The supporting signals.
| In-the-wild status | No public active-exploitation evidence surfaced in the source set, and CISA KEV search did not return this CVE. |
|---|---|
| Proof-of-concept availability | I found Claroty Team82 disclosure and vendor/CISA advisories, but no public weaponized exploit repo in the sources reviewed. |
| EPSS | 0.00081 (~0.081%) from your intel, which is very low and argues against broad opportunistic exploitation. |
| KEV status | Not KEV-listed in the research set; that removes the strongest 'drop everything now' amplifier. |
| CVSS mismatch | NVD CVSS v3.1 = 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), while the Honeywell advisory publishes CVSS v4 = 8.8 HIGH. That gap is a clue that pure base scoring is inflating real-world urgency. |
| Affected versions | LenelS2 NetBox 5.6.1 and earlier are affected. |
| Fixed version | Vendor remediation is NetBox 5.6.2. I found no distro-style backport guidance because this is an appliance product, not a mainstream package ecosystem. |
| Exposure and scanning reality | Vendor docs describe NetBox as browser-based, accessible from any web browser, and show remote web browser / Internet-VPN use in enterprise diagrams. That means exposure is plausible, but I found no trustworthy public Shodan/Censys/FOFA count to support mass-internet assumptions. |
| Disclosure date | 2024-05-30 in NVD/CVE publication records. |
| Researcher / reporting org | Claroty Team82 is credited in the disclosure material. |
Sources.
Why this verdict
- Downgrade from raw CVSS for reachability friction: NVD assumes unauthenticated network reachability, but NetBox is usually on a security network, behind VPN, or limited to admin stations.
- Still HIGH because compromise crosses into physical security: this is an auth bypass on an access-control platform that can influence doors, alarms, event monitoring, and audit visibility.
- Low EPSS and no KEV listing reduce urgency pressure: there is no sourced sign of broad opportunistic exploitation, so this is not a universal fire drill across every asset class.
Why not higher?
I did not find KEV status, active exploitation evidence, or a public mass-exploitation ecosystem around this CVE. The biggest reason not to call it CRITICAL is that many enterprises do not expose physical-security appliances directly to hostile networks, so the vulnerable population that is actually reachable is narrower than the base score implies.
Why not lower?
This is still pre-authentication abuse if the attacker can talk to the appliance, and the weakness is a hardcoded credential rather than a fragile edge-case bug. The consequence space also includes operational and physical-security impact, which is materially worse than a routine internal admin-panel issue.
Crowdsourced verification payload.
Run this on the NetBox appliance itself over SSH as a user that can read common application directories; root is best but not always required. Save as check-cve-2024-2420.sh and run sudo bash check-cve-2024-2420.sh — it will try local package/filesystem heuristics to find the installed NetBox version and return VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# check-cve-2024-2420.sh
# Heuristic local version check for LenelS2 NetBox CVE-2024-2420.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
TARGET_FIXED="5.6.2"
FOUND_VERSION=""
log() {
echo "[INFO] $*" >&2
}
norm_ver() {
# Convert dotted version to zero-padded comparable integer-ish string.
# Example: 5.6.2 -> 0005 0006 0002
local IFS='.'
local parts=($1)
printf "%04d%04d%04d%04d" "${parts[0]:-0}" "${parts[1]:-0}" "${parts[2]:-0}" "${parts[3]:-0}"
}
version_lt() {
[[ "$(norm_ver "$1")" < "$(norm_ver "$2")" ]]
}
extract_version() {
local candidate
for candidate in \
/etc/lenels2-release \
/etc/netbox-release \
/opt/lenels2/version \
/opt/netbox/version \
/usr/local/lenels2/version \
/var/lib/lenels2/version \
/var/www/html/version.txt; do
if [[ -r "$candidate" ]]; then
local v
v=$(grep -Eo '[0-9]+\.[0-9]+\.[0-9]+([.-][0-9A-Za-z]+)?' "$candidate" 2>/dev/null | head -n1 || true)
if [[ -n "$v" ]]; then
echo "$v"
return 0
fi
fi
done
# Try package managers
if command -v dpkg-query >/dev/null 2>&1; then
local v
v=$(dpkg-query -W -f='${Package} ${Version}\n' 2>/dev/null | grep -Ei 'lenels2|netbox' | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)
if [[ -n "$v" ]]; then
echo "$v"
return 0
fi
fi
if command -v rpm >/dev/null 2>&1; then
local v
v=$(rpm -qa 2>/dev/null | grep -Ei 'lenels2|netbox' | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)
if [[ -n "$v" ]]; then
echo "$v"
return 0
fi
fi
# Try local web content/config trees for embedded version strings
local search_roots=(/opt /usr/local /var/www /etc)
for root in "${search_roots[@]}"; do
if [[ -d "$root" ]]; then
local v
v=$(grep -RIEo 'NetBox[^0-9]{0,20}[0-9]+\.[0-9]+\.[0-9]+|[0-9]+\.[0-9]+\.[0-9]+' "$root" 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1 || true)
if [[ -n "$v" ]]; then
echo "$v"
return 0
fi
fi
done
return 1
}
FOUND_VERSION=$(extract_version || true)
if [[ -z "$FOUND_VERSION" ]]; then
echo "UNKNOWN - could not determine installed NetBox version from common local artifacts"
exit 2
fi
log "Detected NetBox version: $FOUND_VERSION"
# Strip any suffix after the numeric semver core
FOUND_VERSION=$(echo "$FOUND_VERSION" | grep -Eo '^[0-9]+\.[0-9]+\.[0-9]+' || true)
if [[ -z "$FOUND_VERSION" ]]; then
echo "UNKNOWN - version string found but could not normalize it"
exit 2
fi
if version_lt "$FOUND_VERSION" "$TARGET_FIXED"; then
echo "VULNERABLE - detected version $FOUND_VERSION is earlier than fixed version $TARGET_FIXED"
exit 1
fi
if [[ "$FOUND_VERSION" == "$TARGET_FIXED" ]] || ! version_lt "$FOUND_VERSION" "$TARGET_FIXED"; then
echo "PATCHED - detected version $FOUND_VERSION is at or above fixed version $TARGET_FIXED"
exit 0
fi
echo "UNKNOWN - unable to compare version reliably"
exit 2