Snowflake forced the hand that identity teams have been avoiding: service-account passwords are dead, and the migration has begun. The technical protocol swap is the easy part. The hard part — inventorying which service account does what, who owns it, and what it can actually access — is the NHI governance problem that most enterprises have deferred for years. Meanwhile, a critical Keycloak flaw lets unauthenticated attackers take over any account via password reset, and NVIDIA’s NemoClaw gave us the first production proof that AI agent model poisoning works from a web page.

In the News

Snowflake Ends Service-Account Passwords — The NHI Ownership Crisis Begins

Snowflake has deprecated password-based authentication for service accounts, requiring customers to migrate to key-pair or OAuth-based mechanisms. The announcement marks one of the first major SaaS providers to force this transition at platform scale — and it exposes the inventory gap that NHI security practitioners have been warning about.

The technical migration path is well-documented. The operational crisis is not. Most organizations cannot enumerate their Snowflake service accounts, let alone identify which application depends on each one, who provisioned it, and whether the associated permissions follow least privilege. Dormant accounts — the ones provisioned by a contractor two years ago for an integration that may or may not still run — become migration blockers with no clear owner.

This is the NHI governance problem stated plainly: you cannot rotate what you cannot inventory, and you cannot decommission what no one will claim ownership of. Snowflake’s move will pressure other SaaS providers to follow, which means every identity team needs an NHI discovery and lifecycle management capability — not someday, now.

What defenders should do: Before touching the auth migration, run a full service-account discovery sweep across your Snowflake tenant. Identify dormant accounts (no activity in 90+ days), map active accounts to their owning teams, and enforce least-privilege access scoping. Use secrets management platforms to centralize key-pair distribution and rotation. Treat any service account without an identified owner as a candidate for immediate suspension.

Keycloak Password-Reset RCE — CVE-2026-18963, CVSS 9.1

A critical vulnerability in Red Hat Keycloak’s password-reset flow allows an unauthenticated attacker to force a password reset on any account — including administrative accounts — and complete the takeover. CVE-2026-18963 carries a CVSS score of 9.1.

Keycloak is the open-source identity and access management engine behind thousands of enterprise SSO deployments. It handles SAML, OIDC, and user federation for organizations that build identity infrastructure on open-source stacks rather than commercial IdPs. A compromise of Keycloak is a compromise of the entire identity provider — every application federated through it is exposed.

The patch landed August 24. Any unpatched instance is a direct path to full IdP compromise. This is the category of IAM zero-day that surfaces in post-breach timelines: the identity provider itself becomes the initial access vector.

What defenders should do: Patch Keycloak immediately to the version released August 24. Monitor Keycloak audit logs for anomalous password-reset volumes. If patching requires downtime, implement a WAF rule blocking unauthenticated requests to the password-reset endpoint as a compensating control. Long-term, enforce FIDO2/passkey-based authentication — password-reset attacks become irrelevant when there is no password to reset.

NVIDIA NemoClaw — First Production AI Agent Model Poisoning via Web Page

Researchers disclosed what appears to be the first documented instance of model poisoning via web page targeting a production AI agent framework. An attacker-controlled webpage takes unauthenticated control of a local Ollama instance serving NVIDIA NemoClaw and plants hidden instructions directly in the model.

This attack converts the “prompt injection is a nuisance” narrative into something materially worse: persistent model manipulation. The injected instructions survive the browsing session. Whatever the NemoClaw agent can access — databases, internal APIs, code repositories — becomes reachable through the poisoned model’s altered behavior. GitGuardian’s concurrent analysis of 2026 agentic AI incidents reaches the same conclusion: prompt injection is the entry technique, but the agent’s credentials and permissions are the blast radius.

This is the convergence of NHI security and AI security. The agent’s service account is the identity. Its OAuth scopes, API keys, and network access define the damage ceiling. Without workload identity controls and microsegmentation around AI agent infrastructure, a single poisoned web page becomes a lateral movement vector.

What defenders should do: Restrict Ollama instances to listen only on localhost or authenticated internal endpoints — never expose them to untrusted network segments. Apply least-privilege scoping to every AI agent service account: limit API scopes, restrict network reachability via microsegmentation, and rotate credentials on short intervals. Treat AI agent workloads as high-privilege non-human identities subject to the same governance as database service accounts.

Mirage2FA Phishing Surge Abuses Microsoft 365 Auth Flows — 4,500 Companies Hit

The Mirage2FA phishing-as-a-service toolkit has expanded to 4,500 confirmed targets across US and EU organizations by proxying legitimate Microsoft 365 authentication flows. The attacker presents a perfect replica of the real Microsoft login page, captures the authenticated session token in real time, and replays it — bypassing SMS, push, and TOTP-based MFA entirely.

ANY.RUN analysis reports a 48% potential compromise rate on targeted emails. This is not credential stuffing. The adversary-in-the-middle proxy defeats every second factor that is not cryptographically bound to the legitimate origin. SMS codes, push approvals, and authenticator TOTPs all fail because the user is authenticating against the real Microsoft endpoint — they just don’t know the attacker is sitting between them and Microsoft, capturing the session.

What defenders should do: Deploy phishing-resistant MFA — FIDO2 security keys or platform passkeys — which bind authentication to the legitimate origin URL and cannot be proxied. Implement ITDR session-anomaly detection to flag when a valid session token appears from an unexpected device, location, or ASN. Enforce conditional access policies that require device compliance and managed device attestation.

Defender Action Items

  • Snowflake service accounts: Run a full NHI discovery sweep. Identify dormant accounts (90+ days inactive). Map active accounts to owning teams. Begin key-pair/OAuth migration with secrets management centralization.
  • Keycloak CVE-2026-18963: Patch to August 24 release immediately. Monitor audit logs for password-reset anomalies. Compensate with WAF rules if patching requires downtime.
  • AI agent workloads (NemoClaw/Ollama): Restrict Ollama to authenticated internal endpoints. Apply least-privilege to all AI agent service accounts. Microsegment agent infrastructure.
  • Mirage2FA / AitM phishing: Enforce FIDO2/passkey MFA. Deploy session-anomaly detection. Require device compliance in conditional access policies.
  • miniOrange SAML plugin (CVE-2026-61979): Update or disable immediately on all WordPress instances. Audit admin accounts for unauthorized additions.
  • Oracle WebLogic (CVE-2026-21962): Patch immediately — CISA KEV-listed, actively exploited, CVSS 10. Audit WebLogic instances for unauthorized access to federated identity stores.

Detection Queries

Anomalous password-reset volume detection for Keycloak deployments — this Splunk SPL query identifies spikes in password-reset events that could indicate exploitation of CVE-2026-18963. Tune the threshold (> 10) based on your environment’s baseline reset volume.

index=keycloak sourcetype="keycloak:audit"
  eventType="RESET_PASSWORD" OR eventType="SEND_RESET_PASSWORD"
| bin _time span=5m
| stats count AS reset_count dc(userId) AS unique_users BY _time clientId
| where reset_count > 10 OR unique_users > 5
| sort -reset_count

For Microsoft 365 session-token theft detection (Mirage2FA), this KQL query in Microsoft Sentinel flags sign-ins where the authenticated session immediately appears from a different IP or user agent — a hallmark of adversary-in-the-middle token replay:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize IPs = dcount(IPAddress), UAs = dcount(UserAgent) by UserPrincipalName, bin(TimeGenerated, 5m)
| where IPs > 1 or UAs > 1
| sort by IPs desc

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.