The password was admin:admin. The blast radius was every connected car on two automakers’ platforms.

That is the finding from security researchers who discovered two major automakers running ForgeRock (now Ping Identity) SSO servers with factory-default administrative credentials. With admin console access, the researchers could take over any customer account and issue commands to the vehicle API - unlock doors, start engines, track GPS location. No exploit chain, no zero-day, no social engineering. Just a credential that was never changed on the identity platform that controlled everything downstream.

This edition covers three identity failures with the same structural root: the identity provider was the single point of failure, and nobody was watching it.

In the News

Default admin:admin on ForgeRock SSO Unlocked Any Connected Car

Security researchers discovered that two automakers’ ForgeRock SSO servers - the identity platform that authenticates every customer interaction with connected-vehicle mobile apps - were running default admin:admin credentials on their administrative consoles. ForgeRock, now part of Ping Identity, is a widely deployed enterprise SSO and access management platform.

With administrative access to the ForgeRock console, the researchers could modify any customer account, issue valid session tokens, and interact with the downstream vehicle command API as any authenticated user. The demonstrated impact included remote door unlock, engine start, and real-time GPS tracking - for any vehicle in either automaker’s connected fleet.

The failure is not a software vulnerability in ForgeRock. It is a configuration governance failure: the most privileged credential on the identity platform was never changed from the factory default. There was no additional authorization layer between the SSO platform and the vehicle API - once you held a valid token, the car obeyed. This is the “identity is the perimeter” premise tested to destruction: when the identity provider is the only gate, and that gate has a default password, the entire downstream asset inventory is exposed.

What defenders should do: Audit administrative credentials on every identity provider in production - ForgeRock, Okta, Entra, Ping, SailPoint. Enforce phishing-resistant passwordless authentication (FIDO2) for all admin consoles. Implement privileged access management controls that prevent static credentials from persisting on identity infrastructure. Deploy ITDR to detect anomalous admin-console access and bulk token issuance. CISA’s Identity Security guidance provides a baseline framework.

Web3Auth OAuth Flaw Exploited to Drain Keplr Crypto Wallets

An attacker exploited a vulnerability in Web3Auth, the OAuth/SSO provider that secures Keplr cryptocurrency wallets through Google and Apple sign-in. The flaw in the federated identity layer gave the attacker access to wallet private keys downstream of the authentication chain, enabling direct fund theft.

Web3Auth’s incident response was extraordinary: upon discovering the exploitation, their team preemptively drained other at-risk wallets before the attacker could reach them - effectively racing the threat actor to empty accounts and hold funds in escrow. The measure underscores the total blast radius of a single identity provider compromise in a federated trust model.

This is the federated identity supply-chain risk in its purest form. Every application that delegates authentication to a third-party OAuth provider inherits that provider’s entire attack surface. When the provider fails, every downstream relying party fails simultaneously. The only structural mitigation is defense-in-depth at the token layer: monitoring for anomalous token redemption patterns, enforcing token binding, and ensuring that authentication does not rely on a single federated factor.

What defenders should do: Inventory all OAuth/OIDC trust relationships. Monitor for anomalous token redemption - geographic impossibility, new device-token pairings, bulk redemptions. Implement token binding where supported. For high-value applications, do not rely solely on third-party OAuth providers for authentication - layer phishing-resistant local authentication (FIDO2) as a second factor independent of the federated chain.

SonicWall SSL-VPN MFA Bypass Exploited in the Wild

CVE-2026-19868 is a CVSS 7.5 MFA bypass in SonicWall SonicOS SSL-VPN, now actively exploited and added to CISA’s Known Exploited Vulnerabilities catalog. Attackers can circumvent the multi-factor authentication enforcement layer entirely, reducing VPN access to a single-factor credential check.

This is the third SonicWall SSL-VPN authentication flaw to reach KEV status in the past 18 months. The pattern is structural: bolting MFA onto a network appliance’s authentication stack creates a brittle enforcement point. When the appliance software has a flaw, the MFA enforcement disappears - and the attacker is on the network with nothing but a stolen password.

What defenders should do: Patch SonicOS immediately. If patching is delayed, disable SSL-VPN access. The structural fix for organizations with recurring VPN auth bypass exposure is moving to ZTNA with identity-aware access where authentication is phishing-resistant, device-bound, and enforced at the identity layer - not at the VPN concentrator. MITRE ATT&CK: T1133 External Remote Services, T1556 Modify Authentication Process.

31,000 Secrets Leaked in Claude Code Config Files on GitHub

GitGuardian found 31,088 secrets - API keys, tokens, credentials - committed to GitHub inside Claude Code settings.local.json files across 23,276 repositories. An additional 613 were found in Docker Hub images. At detection, 5,343 secrets were still valid.

The mechanism is specific: Claude Code’s “yes, and don’t ask again” approval mode writes full commands - including embedded secrets - into a project-level configuration file. Developers then push these files to version control without realizing the secrets are persisted. Peak leakage hit 12,535 secrets per month in April 2026. Awareness campaigns have brought the rate down to 959 per month, but the cumulative exposure across 17 months is significant.

This is AI-accelerated non-human identity sprawl. Developers are generating and embedding secrets faster than security teams can inventory or rotate them. The settings.local.json file is not in default .gitignore templates, and Claude Code does not warn users that secrets will be persisted.

What defenders should do: Add settings.local.json to .gitignore templates across all repositories immediately. Deploy automated secrets detection in CI/CD pipelines (GitGuardian, TruffleHog, or equivalent). Implement NHI lifecycle governance: every API key and service account token should have an owner, an expiration, and automated rotation. Audit existing repositories for committed secrets and rotate any that are found.

Defender Action Items

  • Audit identity provider admin credentials - check ForgeRock, Okta, Entra, Ping, and SailPoint admin consoles for default or shared credentials. Enforce FIDO2 passwordless auth on all admin access.
  • Patch SonicWall SonicOS for CVE-2026-19868 immediately, or disable SSL-VPN. Evaluate ZTNA migration to eliminate recurring VPN auth-bypass exposure.
  • Patch OpenSSH on musl-based systems (Alpine Linux, Docker alpine images) for CVE-2026-123158. Audit SSH configurations for accounts with password authentication supposedly disabled.
  • Add settings.local.json to .gitignore across all repos. Scan existing repos for committed secrets and rotate any valid credentials found.
  • Inventory OAuth/OIDC trust relationships - document every third-party identity provider your applications rely on. Monitor for anomalous token activity patterns.

Detection Queries

SonicWall SSL-VPN MFA bypass detection - monitor for VPN sessions that authenticate successfully without a corresponding MFA challenge event. This Splunk SPL query identifies VPN logins where MFA was expected but no MFA event appears within the correlation window:

index=firewall sourcetype="sonicwall:syslog" event_type="VPN Login Success"
| eval vpn_user=user
| join vpn_user type=left
    [search index=mfa sourcetype="mfa:events" action="challenge_sent"
     | rename user AS vpn_user
     | stats latest(_time) AS mfa_time by vpn_user]
| where isnull(mfa_time) OR (mfa_time < (_time - 300))
| table _time, vpn_user, src_ip, dest_ip, session_id
| sort -_time

This query correlates VPN login success events against MFA challenge events. Sessions where no MFA challenge was sent (or the challenge predates the login by more than 5 minutes) are flagged. False positive rate is low in environments where MFA is enforced on all VPN sessions - any hit warrants immediate investigation as a potential bypass exploitation.

For Claude Code secret detection in repositories, a basic grep across your GitHub org:

1# Find Claude Code config files that may contain secrets
2find . -name "settings.local.json" -exec grep -l -E "(api_key|token|secret|password|AKIA)" {} \;

References

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) - Human, machine, and AI identity security — NHI, ITDR, and the IAM market.