• Severity: CVSS 9.8 (Critical) - CWE-290, Authentication Bypass by Spoofing
  • Affected: ThingsBoard 4.3.0.1; earlier releases may also be affected when Apple OAuth 2.0 login is enabled
  • Patched: 4.2.2.1 and 4.3.1.1 · Exploitation: Public PoC available; no confirmed in-the-wild exploitation

Introduction

CVE-2026-36537 is a critical authentication bypass in ThingsBoard, an open-source IoT platform used to manage devices, telemetry, dashboards, alarms, and users. The CVE record was published on June 15, 2026, after a public proof of concept demonstrated account takeover through the platform’s Apple OAuth 2.0 login flow.

The flaw is classified as CWE-290, Authentication Bypass by Spoofing. During the OAuth authorization code exchange, a vulnerable ThingsBoard server can trust identity data supplied in the request instead of treating the verified Apple ID token claims as the source of truth. An attacker can alter the email value in a forged user object and cause ThingsBoard to issue a session for an existing account.

Exploitation requires Apple OAuth 2.0 login to be configured and reachable. Deployments that do not use Apple as an OAuth provider are not exposed to this specific attack path. ThingsBoard Cloud exposure has not been confirmed publicly, so cloud customers should seek confirmation from ThingsBoard rather than assume either affected or unaffected status.

The result is full account takeover without the victim’s password. If the target is a tenant administrator or system administrator, an authentication bug becomes an IoT control-plane compromise. This is bad, and affected deployments should patch now.

Attribution note: The public technical evidence and proof of concept were published by security researcher KKC73. ThingsBoard’s corrective pull request provides the vendor-side explanation of the trust failure.

What Happened

OAuth login normally works by sending a user to an identity provider, receiving an authorization response, validating that response, and mapping verified identity claims to a local account. The important word is verified. Identity attributes used to select the local user must come from cryptographically validated provider data.

In the vulnerable Apple OAuth flow, ThingsBoard accepted identity information from a request-controlled user parameter at /login/oauth2/code/. The public PoC shows that an attacker could intercept a legitimate Apple sign-in exchange, add a crafted user object containing a victim’s email address, and submit the altered request. ThingsBoard then associated the login with the victim account and returned a redirect containing a ThingsBoard access token for that user.

ThingsBoard’s fix changed the Apple mapper to use claims from the validated ID token as the authoritative source for OAuth attributes. That closes the trust boundary: the browser may carry identity data, but it no longer gets to declare who authenticated.

The browser telling the server “trust me, I am this administrator” is not identity verification. It is improv theatre with production credentials.

Attack Sequence

The attacker first needs access to a ThingsBoard deployment where Apple OAuth login is enabled. They begin a valid Sign in with Apple flow using an Apple account they control, allowing the identity provider to produce a legitimate authorization response.

Before the OAuth callback reaches ThingsBoard, the attacker intercepts the request to /login/oauth2/code/. They add or modify the request’s user JSON object so its email field matches an existing ThingsBoard user they want to impersonate.

The vulnerable server processes the valid OAuth response but trusts the attacker-controlled email during local account mapping. Instead of binding the session to the identity confirmed by Apple’s signed token, ThingsBoard selects the victim’s account.

ThingsBoard then redirects the browser with an access token representing the victim. Loading that redirect establishes an authenticated session with the victim’s ThingsBoard permissions. No victim password, session cookie, or approval is required.

Why This Is Especially Dangerous

  • Account takeover can cross tenant boundaries. ThingsBoard is multi-tenant. A stolen privileged account may expose devices, customers, dashboards, telemetry, alarms, and configuration belonging to an entire tenant.
  • Administrator compromise has platform-wide impact. Targeting a tenant administrator or system administrator can let an attacker create users, change permissions, alter device configuration, and interfere with monitoring workflows.
  • IoT data is operational data. Telemetry can reveal facility activity, equipment state, usage patterns, and security-relevant events. Its confidentiality and integrity both matter.
  • The attack is remote and low complexity. CISA’s CVSS assessment uses AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. No prior ThingsBoard privileges or victim interaction are required.
  • A public PoC removes guesswork. The disclosure documents the affected endpoint, manipulated identity field, and resulting token issuance.
  • OAuth may create false confidence. Teams often treat SSO as a security upgrade. Here, the identity provider correctly authenticates someone, but the application maps that login to the wrong local user.

Most at risk are internet-reachable ThingsBoard installations using Apple OAuth 2.0, especially deployments with high-privilege accounts whose email addresses are known or easy to discover.

Affected Versions

BranchVulnerable VersionsFix Available
ThingsBoard 4.34.3.0.1 is explicitly confirmed; earlier versions may be affected4.3.1.1 or later
ThingsBoard 4.2 LTSEarlier 4.2 releases may be affected4.2.2.1 or later
ThingsBoard releases without Apple OAuth enabledNot exposed through this attack pathDisable Apple OAuth or upgrade
Other OAuth providersNot confirmed affected by the published Apple-specific PoCReview configuration and upgrade
ThingsBoard CloudPublic exposure status not confirmedContact ThingsBoard support

The CVE record explicitly identifies ThingsBoard 4.3.0.1. The researcher reports that 4.2.2.1 and 4.3.1.1 are no longer vulnerable and links the fix to ThingsBoard pull request #15120. Because no public vendor advisory currently defines a complete lower version boundary, do not treat older releases as safe merely because they are absent from the CVE record.

Mitigations

1. Upgrade to a fixed release. Install ThingsBoard 4.3.1.1 or later on the 4.3 branch, or 4.2.2.1 or later on the 4.2 LTS branch. Follow the official upgrade instructions for your deployment method and test custom UI changes before production rollout.

2. Disable Apple OAuth until patching is complete. In ThingsBoard, review Security > OAuth 2.0 > OAuth 2.0 clients and disable or remove the Apple client. Confirm that the Apple sign-in option no longer appears and that the callback endpoint cannot complete an Apple OAuth login.

3. Restrict access to the OAuth callback as a temporary control. If Apple OAuth cannot be disabled immediately, use a reverse proxy or web application firewall to restrict access to /login/oauth2/code/. This can disrupt legitimate SSO and should be treated as a short-lived workaround, not a replacement for patching.

4. Revoke active sessions after upgrading. Invalidate existing user sessions and authentication tokens, especially for system administrators and tenant administrators. The public attack returns a valid victim token, so patching does not remove sessions obtained before the fix.

5. Review privileged account activity. Inspect audit logs for unexpected logins, user creation, role or group changes, OAuth configuration changes, device updates, dashboard modifications, and API activity associated with privileged users.

6. Reduce administrator exposure. Use dedicated administrator accounts, limit their routine use, enforce the strongest authentication controls available, and avoid publishing privileged account email addresses.

Indicators of Compromise

No official network indicators, malicious IP addresses, domains, or file hashes have been published for CVE-2026-36537. No active exploitation has been confirmed as of June 18, 2026. Hunt for behaviour tied to the authentication flow instead.

On the ThingsBoard server:

  • Successful OAuth callbacks to /login/oauth2/code/ followed by sessions for a different user identity than the identity provider authenticated
  • New access tokens or sessions for privileged accounts at unusual times or from unfamiliar source addresses
  • Unexpected user, role, group, tenant, customer, device, rule chain, dashboard, or OAuth client changes
  • Administrative actions without a matching normal login history

In proxy and traffic logs:

  • Requests to /login/oauth2/code/ containing an unexpected user parameter or JSON object
  • Apple OAuth callback requests whose identity fields do not match validated token claims
  • Repeated OAuth callback attempts targeting different email addresses
  • Redirects that issue ThingsBoard tokens immediately after suspicious callback requests
  • Source addresses that authenticate as multiple unrelated ThingsBoard users

Configuration integrity:

  • Apple OAuth clients enabled unexpectedly
  • Changes to OAuth mapper settings, redirect URIs, client IDs, or allowed domains
  • New privileged users or altered permissions after an OAuth login
  • Unapproved changes to reverse-proxy rules protecting authentication endpoints

Preserve reverse-proxy logs, ThingsBoard audit events, authentication logs, and active token records before rotating or revoking credentials. Monitor the CVE record, ThingsBoard release notes, and upstream repository for new guidance or confirmed exploitation.

References