LenelS2 NetBox access control and event monitoring system was discovered to contain Hardcoded Credentials…

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.

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.

1. Restrict reachability — Put NetBox management behind allowlisted admin subnets, VPN, or a jump host and block all other paths at internal and perimeter firewalls. For a HIGH verdict, deploy this compensating control within 30 days if you cannot patch immediately.
2. Review authentication and admin logs — Pull NetBox audit data into your SIEM and hunt for successful logins from unusual IP space, shared service-like identities, after-hours admin activity, and unexpected config changes. Do this immediately and keep enhanced monitoring in place until the estate is fully remediated.
3. Segment the physical-security plane — Treat access-control infrastructure like OT: isolate controller/appliance networks from user LANs and server tiers, and permit only required management flows. This shrinks the set of attackers who can even attempt exploitation and should be in place within 30 days under the HIGH bucket.
4. Constrain admin origins — Force administration through hardened workstations or jump servers with strong logging so you can distinguish legitimate operator activity from suspicious use of built-in access paths. This is especially useful because appliance-native abuse may bypass normal endpoint controls.

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

Sources

1. NVD CVE-2024-2420
2. Honeywell security notice for NetBox CVEs
3. Claroty Team82 disclosure dashboard entry
4. LenelS2 NetBox product page
5. NetBox Enterprise datasheet
6. CISA vulnerability bulletin SB24-155
7. SentinelOne CVE entry with EPSS summary