ThingsBoard v4.3.0.1 is vulnerable to an authentication bypass during the OAuth authorization code exchange.

CVE-2026-36537 is an authentication bypass in the ThingsBoard OAuth authorization-code exchange path. On a vulnerable ThingsBoard instance running v4.3.0.1, an unauthenticated attacker can target the login flow used for external identity providers and end up with a valid ThingsBoard session without possessing a legitimate user password. The vulnerable surface only exists where the web UI is reachable and OAuth 2.0 / SSO is actually configured for the tenant or deployment.

The vendor's 9.8 CRITICAL score overstates the fleet-wide reality. Yes, this is remote and pre-auth on the app layer, but the real population is much smaller than 'all ThingsBoard installs': the attacker needs an OAuth-enabled deployment, has to interact with a specific auth flow, and the resulting blast radius is bounded by the mapped ThingsBoard role unless the platform sits in a high-value IoT/SCADA role. That still leaves this as HIGH, not a casual downgrade, because successful compromise can hand an attacker operational control of devices, telemetry, and tenant administration.

Why this verdict

• Friction adjustment: the chain starts as unauthenticated remote, but it only exists on deployments where the ThingsBoard web UI is reachable and OAuth is enabled. That meaningfully trims the reachable population versus a blanket network-service bug.
• Friction adjustment: exploiting an OAuth authorization-code exchange flaw implies protocol-aware abuse of a specific login path, not commodity internet spraying against every exposed endpoint. Modern reverse proxies, provider-side redirect checks, and sane OAuth settings add real breakage in the field.
• Friction adjustment: if the target is only internally reachable, the prerequisite shifts from *unauthenticated remote internet* to *internal network / post-initial-access*, which is compounding downward pressure on severity for many enterprise deployments.
• Role multiplier: on a low-value role like a dev sandbox or lab dashboard, the documented chain still succeeds, but the blast radius is usually host or single tenant. That is not where the score should live.
• Role multiplier: on a typical role like a line-of-business IoT app tier, the chain can succeed and the blast radius becomes tenant-wide control of devices, dashboards, API keys, and telemetry.
• Role multiplier: on a high-value operational role where ThingsBoard is the control plane for production devices or SCADA-like workflows, the chain can succeed and the blast radius becomes fleet-scale operational manipulation or safety-impacting misuse. That worst plausible role keeps the verdict floored at HIGH even after friction is applied.
• Threat-signal adjustment: no KEV listing, no public exploitation evidence, and a very low EPSS 0.0023 argue against calling this CRITICAL today.

Why not higher?

I am not taking this to CRITICAL because the real attack surface is narrower than the vendor's CVSS assumes: the target must expose the web app and actually use the vulnerable OAuth flow. I also found no public exploitation, no KEV listing, and no public PoC that would justify an 'assume weaponized everywhere' stance.

Why not lower?

I am not dropping this to MEDIUM because the exploit path is still remote and pre-auth at the application layer. On operational ThingsBoard deployments, a successful bypass is not a nuisance login bug; it can become tenant takeover with direct impact on managed devices and workflows.

1. Disable unused OAuth providers — If a tenant or environment does not actively need external SSO, turn off OAuth login there and remove dormant provider configs. This directly removes the vulnerable path and should be done within 30 days for a HIGH verdict.
2. Restrict web access — Put ThingsBoard behind VPN, private access proxy, or IP allowlisting where business reality permits. This converts an unauthenticated internet bug into an internal-only problem and should be enforced within 30 days.
3. Harden reverse-proxy auth paths — Apply tight allowlists and logging around OAuth callback, login, and token-exchange routes at NGINX/Apache/API-gateway layers. This will not fix the bug, but it cuts exposure and improves detection within 30 days.
4. Correlate IdP and ThingsBoard logins — Alert on ThingsBoard session creation that lacks the expected matching IdP authentication event, especially for admin roles. This is the best detective control when you cannot patch immediately, and it should be in place within 30 days.
5. Enforce least privilege in ThingsBoard roles — Review tenant-admin, customer-admin, API key issuance, and device-management permissions so a single bypassed session cannot immediately administer every device. This limits blast radius and should be completed within 30 days.

Run this on the ThingsBoard host or container shell with read access to the install directory and config files; root is helpful but not always required. Invoke it as bash tb-cve-2026-36537-check.sh /usr/share/thingsboard /etc/thingsboard/conf or just bash tb-cve-2026-36537-check.sh to use defaults. It checks for version 4.3.0.1 and simple signs that OAuth is configured; because the exact fixed build is not clearly published in the sources reviewed, non-4.3.0.1 versions are treated as PATCHED only for the specific version named in the advisory prompt.

#!/usr/bin/env bash
# tb-cve-2026-36537-check.sh
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TB_HOME="${1:-/usr/share/thingsboard}"
CONF_DIR="${2:-/etc/thingsboard/conf}"
VERSION=""
OAUTH_HINTS=0

find_version() {
  # Debian/RPM package names
  if command -v dpkg-query >/dev/null 2>&1; then
    VERSION=$(dpkg-query -W -f='${Version}\n' thingsboard 2>/dev/null | head -n1 | sed 's/-.*//')
    [ -n "$VERSION" ] && return 0
  fi

  if command -v rpm >/dev/null 2>&1; then
    VERSION=$(rpm -q --qf '%{VERSION}\n' thingsboard 2>/dev/null | head -n1)
    [ -n "$VERSION" ] && return 0
  fi

  # Directory / jar name heuristics
  if [ -d "$TB_HOME" ]; then
    VERSION=$(find "$TB_HOME" -maxdepth 3 -type f \( -name 'thingsboard-*.jar' -o -name 'tb-web-ui-*.jar' \) 2>/dev/null \
      | sed -n 's/.*thingsboard-\([0-9][0-9.]*\)\.jar/\1/p' | head -n1)
    [ -n "$VERSION" ] && return 0
  fi

  # Docker image label / env heuristics
  VERSION=$(env | awk -F= '/^(TB_VERSION|THINGSBOARD_VERSION)=/{print $2; exit}')
  [ -n "$VERSION" ] && return 0

  return 1
}

check_oauth_hints() {
  # Config-file heuristics only; true enablement may be stored in DB/admin UI.
  if [ -d "$CONF_DIR" ]; then
    if grep -RqiE 'oauth2|spring\.security\.oauth2|authorization-uri|access-token-uri|client-id|client-secret' "$CONF_DIR" 2>/dev/null; then
      OAUTH_HINTS=1
      return 0
    fi
  fi

  if [ -d "$TB_HOME" ]; then
    if grep -RqiE 'oauth2|login/oauth2|authorization-uri|access-token-uri' "$TB_HOME" 2>/dev/null; then
      OAUTH_HINTS=1
      return 0
    fi
  fi

  return 1
}

find_version || {
  echo "UNKNOWN - could not determine ThingsBoard version"
  exit 2
}

check_oauth_hints || true

case "$VERSION" in
  4.3.0.1)
    if [ "$OAUTH_HINTS" -eq 1 ]; then
      echo "VULNERABLE - ThingsBoard version $VERSION with OAuth-related configuration/artifacts present"
      exit 1
    else
      echo "UNKNOWN - ThingsBoard version $VERSION found, but OAuth enablement could not be confirmed from local files"
      exit 2
    fi
    ;;
  *)
    echo "PATCHED - specific vulnerable version 4.3.0.1 not detected (found: $VERSION)"
    exit 0
    ;;
esac

Sources

1. ThingsBoard OAuth 2.0 support documentation
2. ThingsBoard security overview
3. ThingsBoard release table
4. ThingsBoard v4.3.x release notes
5. ThingsBoard upgrade instructions
6. ThingsBoard GitHub releases
7. ThingsBoard PR #15120 OAuth2 validation refactor
8. CISA Known Exploited Vulnerabilities Catalog