A certificate authority’s private keys so weak they could be recovered in seconds. An OAuth token that gave attackers persistent access to 173 M365 tenants. A 94-minute window where a trusted CLI tool was silently stealing every secret on the developer’s machine. Today’s brief covers three stories that share a common thread: identity trust assumptions that turned out to be wrong.

In the News

eMudhra CA Keys So Weak Anyone Could Forge Trusted Certificates

Eight intermediate certificate authority keys issued by eMudhra were cryptographically weak enough to be recovered almost instantly. The weakness was not a misconfiguration or a side-channel - the key material itself was insufficient. Anyone who recovered the private keys could forge browser-trusted certificates for arbitrary domains, enabling man-in-the-middle attacks, credential interception, and fraudulent SAML assertion signing.

Mozilla, Google, and Apple have already moved to distrust the affected intermediates. The practical impact is immediate: any organization using eMudhra-issued certificates in SSO flows, SAML assertion signing, mutual TLS client authentication, or code signing now has broken trust chains. Browser warnings are already being reported. Authentication flows that depend on these certificate chains will fail.

The deeper identity lesson is about crypto agility - the ability to rotate certificates and CA trust anchors quickly when a CA is compromised or distrusted. Organizations that cannot inventory which certificates they rely on, and rotate them within hours, are exposed to cascading authentication failures every time a CA falls out of trust. This is also a strong argument for reducing dependence on certificate-based authentication in favor of phishing-resistant passwordless authentication (FIDO2), which does not depend on third-party CA trust chains for user authentication.

What defenders should do: Inventory all certificates chained to eMudhra intermediates across SSO, SAML, mTLS, and code signing. Replace immediately with certificates from a trusted CA. Evaluate certificate lifecycle automation to reduce future rotation time. Consider phishing-resistant passwordless (FIDO2) for user authentication flows to remove CA dependency from the critical authentication path.

Source: The Hacker News

ConnectWise Resets All Cloud Backup Credentials After OAuth Compromise Hit 173 Tenants

ConnectWise completed its remediation of the OAuth identity compromise that affected 173 Microsoft 365 tenants through its Cloud Backup service. The company hardened admin access controls and force-reset all accounts and application credentials. Cloud Backup remains offline as of October 21.

The original vector was a compromised OAuth application identity - a non-human identity with excessive permissions that granted persistent access to customer M365 environments. The attack bypassed user-facing MFA entirely because the compromised identity was a token, not a user session. This is the core NHI governance failure: OAuth applications with broad scopes that persist beyond any individual user session, with no behavioral monitoring to detect anomalous usage patterns.

The remediation response - full credential reset and service shutdown - is appropriate but disruptive. The question for any organization using cloud backup services with OAuth integration is whether they have visibility into which OAuth apps have consent to their tenant, what scopes those apps hold, and whether continuous access evaluation is enforced to detect token abuse in near-real-time.

What defenders should do: Audit all OAuth app registrations and consent grants in your M365 and Entra ID tenants. Enforce least-privilege scopes for third-party backup and SaaS integrations. Implement continuous access evaluation and token lifetime policies. Deploy identity threat detection (ITDR) to surface anomalous OAuth token usage.

Source: The Hacker News

OVHcloud CLI Hijacked on GitHub for 94 Minutes - Backdoored Releases Stole Developer Secrets

An attacker compromised a contributor’s GitHub account and replaced five OVHcloud CLI release archives with backdoored builds containing credential-harvesting code. The malicious releases were live for up to 94 minutes on October 19 before OVHcloud detected the tampering and pulled the artifacts.

Any developer who downloaded the CLI during that window had their local credentials, API keys, environment variables, and tokens exfiltrated. The attack chain is clean: compromise a human identity (the maintainer’s GitHub account), use that access to inject malicious code into a trusted distribution channel, and harvest non-human identities (secrets, API keys, tokens) from every downstream consumer.

This is the NHI supply-chain problem in its purest form. A single maintainer account without phishing-resistant authentication became the initial access vector. The blast radius was entirely non-human - every API key, every service account credential, every token stored in a developer’s environment was exfiltrated in under two hours. The 94-minute detection window is actually fast by supply-chain standards, but the damage from secret exposure is already done the moment the secrets leave the endpoint.

What defenders should do: If your teams use OVHcloud CLI, check download timestamps against the October 19 window. Rotate all API keys and tokens that were present on affected machines. Enforce phishing-resistant authentication (FIDO2/passkeys) on all maintainer and contributor accounts. Implement release artifact signing verification in CI/CD pipelines. Deploy secrets scanning to detect leaked credentials before they are replayed.

Source: The Hacker News

AI Agents Leak Developer API Keys at Double the Baseline Rate

GitGuardian researchers found that AI coding agents expose real API keys from developer environments at a 3.2% rate - more than double the 1.5% baseline for non-assisted commits. The researchers confirmed recovery of live DeepSeek and Google API keys from LLM outputs during testing.

The mechanism is not sophisticated. AI agents operate with the credentials available in the developer’s local environment - environment variables, config files, credential stores. When generating code, commit messages, or log output, the agents include these secrets without any filtering or governance layer. The agent inherits the developer’s access but not the developer’s judgment about what constitutes sensitive material.

This is an emerging NHI governance gap. As AI-assisted development becomes standard, the volume of unintentionally exposed secrets will scale with adoption. The 3.2% leak rate across a large engineering organization means dozens of live credentials appearing in repositories, logs, and AI tool outputs every week. Secrets scanning in CI/CD pipelines is no longer optional for any organization using AI coding tools. Equally important is moving to ephemeral credentials - short-lived tokens that expire before they can be meaningfully exploited - rather than long-lived API keys that persist indefinitely.

What defenders should do: Deploy secrets scanning across all CI/CD pipelines, commit hooks, and AI tool output channels. Migrate from long-lived API keys to short-lived, automatically rotated tokens wherever possible. Inventory which AI agents and coding assistants have access to developer credentials. Enforce least-privilege scoping for AI tool integrations.

Source: GitGuardian Blog

Today’s Deep Dive - Non-Human Identity Risk Is Converging from Three Directions

Today’s stories are not isolated incidents. They represent three converging vectors of non-human identity risk that defenders need to address simultaneously.

Vector 1: Certificate trust collapse. The eMudhra compromise demonstrates that the CA trust model - the foundation of certificate-based authentication - has single points of failure that can be exploited without any action by the relying party. When a CA’s keys are compromised, every organization in its trust chain is immediately affected. This is why crypto agility (the ability to rapidly rotate CAs and certificates) and reducing dependence on certificate-based auth (via FIDO2/passkeys) are both critical. MITRE ATT&CK: T1588.004 - Obtain Capabilities: Digital Certificates.

Vector 2: OAuth and token abuse. The ConnectWise breach shows that OAuth tokens - non-human identities with their own lifecycle, permissions, and persistence - are the new credential theft target. Attackers do not need to phish a user if they can compromise an application identity with broad scope. Traditional MFA does not protect this layer. Continuous access evaluation, token lifetime policies, and ITDR are the controls that matter. MITRE ATT&CK: T1550.001 - Use Alternate Authentication Material: Application Access Token.

Vector 3: Supply-chain secret exfiltration. Both the OVHcloud CLI hijack and the GitGuardian AI agent research show that secrets - API keys, tokens, service account credentials - are being exposed through trusted channels. Whether the channel is a compromised release artifact or an AI coding assistant, the result is the same: non-human identities leak without the human operator’s knowledge or consent. MITRE ATT&CK: T1195.002 - Supply Chain Compromise: Compromise Software Supply Chain.

The common control across all three vectors is NHI inventory and governance - knowing which non-human identities exist, what permissions they hold, how long they persist, and where they are being used. Organizations that treat NHI governance as a future problem are already behind the curve.

Detection Spotlight

This Splunk SPL query detects OAuth application consent grants with high-privilege scopes in Microsoft 365/Entra ID audit logs - the exact pattern that preceded the ConnectWise breach. Look for Add OAuth2PermissionGrant events where the scope includes broad permissions like Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All.

index=o365 sourcetype="o365:management:activity"
  Operation="Add OAuth2PermissionGrant"
| spath output=scope path=ModifiedProperties{}.NewValue
| where match(scope, "(?i)(Mail\.ReadWrite|Files\.ReadWrite\.All|Directory\.ReadWrite\.All|full_access_as_app)")
| eval grant_time=strftime(_time, "%Y-%m-%d %H:%M:%S")
| table grant_time, UserId, ObjectId, scope, ClientIP
| sort - grant_time

This query surfaces high-privilege OAuth consent grants as they happen. False positive rate is low in mature environments where OAuth governance policies restrict broad-scope consent - if you see hits, investigate whether the consent was expected and whether the application identity is legitimate. In environments without consent policies, expect noise from legitimate SaaS integrations; tune by baselining known-good ObjectId values.

Defender Action Items

  • Inventory all certificates chained to eMudhra intermediates; replace with certificates from a trusted CA immediately
  • Audit all OAuth app registrations and consent grants in M365/Entra ID - enforce least-privilege scopes and token lifetime policies
  • Check OVHcloud CLI download timestamps against the October 19 compromise window; rotate all secrets on affected machines
  • Deploy secrets scanning across CI/CD pipelines and AI tool output channels
  • Patch PAN-OS CVE-2026-0257 (May 2026 patch) if not already applied - Qilin and INC ransomware groups are actively exploiting it

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.