Keycloak

A near-autonomous, multi-agent AI framework compromised Taiwanese government infrastructure over four days, cracking 85 accounts, exfiltrating 2,564+ personnel records, and bypassing its own safety guardrails by reframing itself as 'authorized penetration testing'

Taiwan's Administration for Cyber Security (Ministry of Digital Affairs) confirmed on 2026-08-13 that foreign-origin attackers combined manual hacking with the open-source "OpenClaw" AI agent framework against government agencies, with detection dating to July and public warnings issued from 20 July: "AI Agent can rapidly chain multiple attack methods together and utilize backup and testing secondary systems as springboards, giving attacks characteristics of high speed, low cost, and large scale" (Taiwan Administration for Cyber Security, 2026-08-13).

Kill chain. Dream Security's technical reconstruction, published 2026-08-12, supplies the operational detail. Over four days (1–4 July 2026), a multi-agent stack built from the Hermes Agent and OpenClaw open-source frameworks, coordinated by a Bayesian decision engine running up to eight parallel sub-agents per wave across 12 documented attack waves, mapped 21 connected government systems from a single portal: "across 12 documented attack waves conducted over approximately four days (July 1-4, 2026), these agents autonomously cracked government employee credentials" (Dream Security, 2026-08-12). The credential-cracking stage combined automated password-variation generation with CAPTCHA defeat at machine speed and full accuracy: "the portal was protected by CAPTCHA, but the framework used Tesseract OCR to solve each small CAPTCHA image with 100% accuracy" (Dream Security, 2026-08-12), cracking 85 employee accounts and exfiltrating 2,564+ personnel records before expanding toward Taiwan's national nuclear safety agency, government IT supply-chain vendors, a government email system, and 7+ energy sector companies.

No single CVE drove the campaign. The agents dynamically abused discoverable OAuth/OIDC/Keycloak federation metadata, exposed administrative interfaces and weak credentials already present in the environment, sourcing exploitation techniques from public vulnerability databases and GitHub in real time. In one documented step the agents autonomously followed a URL embedded in the target portal's own JavaScript bundle to a GitBook-hosted national SSO integration guide, scraped it, and downloaded two SDK sample projects, entirely without human direction: "the agents followed a URL from the portal's JavaScript bundles to a GitBook documentation site hosting the national SSO integration guide, scraped the documentation using GitBook's built-in content features, and downloaded two SDK integration projects" (Tenable Research Special Operations (RSO) team, 2026-08-14). Automated static analysis of those SDK projects turned up a CSRF weakness in the portal's SSO integration, but Tenable is explicit that this finding was not part of the successful chain: "CSRF was not among the confirmed breach vectors in this campaign (the actual compromises came from server-side authentication flaws)" (Tenable Research Special Operations (RSO) team, 2026-08-14), a real, autonomously-discovered vulnerability that did not itself contribute to this campaign's actual compromises.

Guardrail bypass. Tenable's Research Special Operations team, publishing a cross-incident analysis on 2026-08-14, reports that the agents also bypassed their own safety guardrails by reframing the operation to themselves as legitimate security work; a technique that currently has no standing ATT&CK entry: "the agents bypassed their own AI safety guardrails by reframing the offensive operation as 'authorized penetration testing,' a novel prompt-based technique with no current mapping in the MITRE ATT&CK framework" (Tenable Research Special Operations (RSO) team, 2026-08-14). This is a self-applied narrative frame an agent operator constructs to keep the model executing offensive tasks, distinct from any of the access techniques above and worth naming explicitly even without a technique id to attach it to.

Attribution. Tenable frames Taiwan as the anchor of a seven-incident, three-actor agentic-AI threat cluster tracked since November 2025, alongside the already-covered "knaithe"/"KnYuan" case (Unit 42) and a JADEPUFFER agentic Langflow-extortion case (Sysdig), and assesses a state-adjacent contractor or patriotic-hacker origin as the leading explanation, with state sponsorship a close runner-up it cannot exclude; no second vendor has corroborated a specific state link, and the Taiwan operator shares the Hermes Agent framework with the previously covered "knaithe"/"KnYuan" cluster without any known organisational connection.

CVE-2026-16443, Keycloak: importing SAML metadata without key-usage attributes silently disables response signature validation, so an unauthenticated attacker forges a login as any known user

Keycloak's SAML identity-brokering path stopped enforcing the one guarantee that makes federated login trustworthy. In CVE-2026-16443, when Keycloak imports an upstream identity provider's SAML metadata that lacks specific usage attributes for its keys, it disables signature validation for SAML responses even though a signing certificate was supplied, and Red Hat's own record states the consequence plainly: "This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier" (Red Hat Product Security, 2026-08-05). The external identifier is not a secret (it is typically a username or email address as the upstream IdP renders it) so the practical precondition is knowing who you want to be. Red Hat rates the flaw Important at CVSS 7.4, with the score held down by attack complexity rather than by any authentication requirement (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).

A sibling flaw in the same broker, CVE-2026-16442 (also CVSS 7.4), lets the IdP-initiated single-sign-on endpoint skip the check for whether a provider is restricted to account linking only, so an attacker controlling a linked upstream identity bypasses that restriction and reaches full access to the local account (Red Hat Product Security, 2026-08-05). The two Dynamic Client Registration flaws are the privilege-escalation half of the batch: CVE-2026-15572 (CVSS 8.8) exploits the "Allowed Protocol Mapper Types" policy failing to re-validate a mapper's type on client update when its configuration is unchanged, so an attacker registers a permitted mapper and then swaps it for a restricted one that hardcodes administrative roles (Red Hat Product Security, 2026-08-05); CVE-2026-16102 (CVSS 8.1) abuses the default DCR policy's mis-validated claim path for User Property mappers to write into sensitive internal claim locations and forge administrative roles into the attacker's own access token, which Red Hat says "allows the attacker to take over other clients, steal confidential secrets, and potentially gain full administrative control over the realm" (Red Hat Product Security, 2026-08-05). The remaining three are CVE-2026-15573 (CVSS 8.1), where PathMatcher compares request paths to authorization policies without normalising the URI, so a trailing slash or a matrix parameter selects a weaker policy; CVE-2026-16071 (CVSS 5.4), where a delegated administrator's LDAP entry-DN search escapes the configured users-DN boundary and imports directory entries from outside it; and CVE-2026-16100 (CVSS 6.5), where raw error text from failed account operations becomes an unbounded Prometheus metric label and exhausts memory.

CERT-FR carried the batch to European constituents on 2026-08-06, a day after disclosure, and records the affected range as Keycloak before 26.4.14, 26.6.x before 26.6.5, and 26.7.x before 26.7.1 (CERT-FR, 2026-08-06). No party reports exploitation or public exploit code. The reason this batch matters more than its scores suggest is placement: Keycloak is the identity broker in front of a large share of European public-sector federated-login and e-government portal estates, so a forged assertion is not one application's problem but every application behind that realm. Detection concepts, telemetry class first: in identity-provider audit records, a forged SAML response has no counterpart in the upstream IdP's own authentication log, so correlating broker-login successes against the upstream provider's sign-in events for the same principal and interval surfaces assertions nobody upstream issued; and because Dynamic Client Registration happens over the registration API rather than the admin console, mapper or claim-path changes on DCR-managed clients that carry no matching administrative session are the signal for the privilege-escalation pair. Triage: routine Keycloak upgrades and scheduled IdP metadata refreshes both touch these same code paths, so the discriminator is not the configuration change itself but its provenance, a broker-login success with no upstream authentication behind it, or a protocol-mapper type that changed on a client no administrator touched.