🔥 CyberForge CVE of the Day #069 🚨 CVE-2026-105209 — ZITADEL: cross-organisation account takeover through passkey enrolment-code issuance ZITADEL's advisory describes a missing target-organisation permission check. A caller with relevant management rights in one organisation could obtain an enrolment code for another organisation's user within the same instance, add an authenticator and take over that account. The victim need not interact; existing victim credentials are not disclosed by this flaw. ⚠️ Identify affected identity infrastructure, repair every serving node and examine the earlier enrolment trail alongside the upgrade. 🗓️ Evidence: 5 October 2026, 08:11 UTC. The CVE was published yesterday; the vendor advisory and fixes date to 14 August. Field exploitation was not verified in the reviewed evidence. FIRST returned no EPSS row; the CVE is absent from the retrieved KEV catalogue. 🎯 THE QUICK HIT What happened? The code-creation check trusted the request's organisation context instead of checking permissions against the target user's actual organisation. A valid enrolment code then enabled the intended registration flow for an account outside the caller's authorised scope. Who needs to check? Owners of ZITADEL 3.0.0–3.4.14 and 4.0.0–4.17.0, including release candidates in the vendor's stated ranges. Establish running builds, the organisations sharing the instance and principals with effective enrolment/credential-management rights. The published prerequisite is stronger than simply being logged in. What fixes it? First fixed releases: 3.4.15 and 4.17.1, each in its own train. Use a suitable supported patched release; these are repair floors, not a claim about the latest version. The vendor says configuration alone cannot fully close the gap on an unpatched build. What should the SOC follow? Preserve audit/access evidence and historical grants. Join the code issuer's authority to the target resource-owning organisation; follow unexplained issuance into authenticator verification, authentication and relevant application activity. An organisation mismatch or registration event alone does not establish compromise. What does a quiet hunt mean? No matches in the examined sources and interval. Missing request scope, expired retention, incomplete pagination or a restricted export can leave the central comparison unavailable. 🔑 KEY DETAILS: • Product: ZITADEL identity management; organisation separation inside one instance. • Weakness: CWE-862, Missing Authorization — vendor and VulnCheck CNA. • Vendor/CNA CVSS v3.1: 9.6 Critical — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N. • VulnCheck CNA CVSS v4.0: 9.3 Critical — CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N. • Prerequisites: reachable relevant management operation, authenticated caller with existing organisational rights; low complexity, no victim interaction. • Impact: an additional authenticator and takeover of the target account. Its actual grants determine downstream application access; host execution or instance-wide administration is not established. • Vendor advisory: GHSA-pq2q-2c6r-75c4, 14 August. VulnCheck CVE publication: 4 October, 13:10:03 UTC. • NVD: Deferred; its displayed scores originate from VulnCheck. The v3.1 metric's “Primary” label is not a separate NIST assessment. • KEV: no exact match in catalogue 2026.10.04, released 4 October at 18:52:56 UTC, after CVE publication. Catalogue absence does not establish no exploitation. • EPSS: successful FIRST response, total 0, empty data array. Probability, percentile and score date are unavailable; none is zero by inference. Published severity, public exploitation reporting and compromise of a specific deployment are separate questions. 🧩 WHERE THE TRUST BOUNDARY FAILED The vulnerable path checked code-creation permissions in the organisation supplied through x-zitadel-orgid, while the target user's owning organisation could be different. A caller authorised in one scope could therefore receive a passwordless/passkey enrolment code for a target outside it. Code redemption is intended possession-based behaviour. The missing authority check when issuing the code causes the flaw; this disclosure does not establish broken FIDO cryptography or theft of an existing authenticator's private key. The patches resolve target ownership before authorising creation. Static review identifies user.passkey.write in the v2 path and user.credential.write or user.write in older credential/send-code paths. Have the identity owner confirm the effective role grants for the operation and build involved. The published regression-test source covers foreign-organisation denials and permitted global management; it was reviewed, not executed. Legitimate global administrators must not be treated as attackers solely from an organisation difference. 📦 APPLICABILITY, VERSIONS AND THE EXPOSURE WINDOW Vendor matrix: • 3.x: affected 3.0.0–3.4.14; first fixed 3.4.15. • 4.x: affected 4.0.0–4.17.0; first fixed 4.17.1. • Release candidates: included within the vendor's stated affected ranges. The CNA's structured entries start at 0 and use separate “less than 3.4.15” and “less than 4.17.1” bounds. Flattening them into one scanner rule can misclassify patched 3.x systems; those entries do not establish a 2.x affected range. Resolve results against the explicit vendor trains and supported backport evidence. Build the exposure window from first affected deployment until all serving nodes were repaired. Account for rolling upgrades, recovery replicas, restored snapshots and mutable image tags. Desired configuration alone does not prove which binary served requests. For a hosted service, request operator evidence of the relevant instance's builds and remediation dates. Public release history does not verify a specific customer's deployment. Record eligible human/workload identities and historical grants; an actor's home organisation or current role is not a substitute for effective authority at the event time. 🔎 THE SOC TRAIL — SIX INVESTIGATIVE CHECKS C01 — Establish the affected identity boundary. Action/location: inventory the instance, organisations, serving builds and enrolment-capable principals through approved deployment/admin views and historical role records. Signal: an affected build with applicable management access. Correlate build, effective grants and request reachability across the exposure window. Benign/limits: flattened scanner ranges, stale tags and legitimate instance-wide authority. Escalate confirmed exposure to the identity owner; missing build evidence leaves applicability unresolved. This check does not establish exploitation. C02 — Preserve the available trail. Action/location: export the agreed UTC window and organisations from supported ZITADEL audit facilities; retain existing access, role-history and relevant application records. Signal: code issuance or credential change during exposure, or a source gap that prevents assessment. Correlate instance, issuer, target, resource owner, event sequence, time and existing request IDs. The Admin v1 ListEvents search uses POST but reads events. Its filters include eventTypes, aggregateId, resourceOwner and time range. Check all required pages and export permissions. Protobuf JSON may omit an empty events field; confirm an actual empty result before normalising it. Benign/limits: retention expiry, delayed ingestion and restricted exports. Escalate material gaps with their interval and scope. Protect raw evidence; never add logging of bearer tokens, cookies, enrolment codes or authenticator responses just to improve visibility. C03 — Check the issuer against the target organisation. Action/location: compare code-creation metadata, historical effective grants and existing request records. Signal: issuing a code for a target outside the caller's authority. Correlate actor, target user, target resourceOwner, recorded request organisation, operation, serving build and UTC window. A source-verified pivot is user.human.passwordless.initialization.code.added. Native v4.17.1 JSON fields are .editor.userId, .aggregate.id, .aggregate.resourceOwner and .type.type. The event does not automatically contain the request's organisation header; do not invent that missing comparison. Benign/limits: approved helpdesk work, self-enrolment, global administration and historical user/organisation changes. Review authority at the time. Escalate an unexplained permission failure with preserved references. A header/owner mismatch is a candidate; effective target permission determines its meaning. C04 — Establish whether an authenticator was completed. Action/location: follow suspect issuance through passwordless events and supported credential inventory. Signal: an unrecognised authenticator linked to suspicious issuance. Correlate target, organisation, time and sequence; credential/code identifiers retained privately can strengthen the join. Source pivots: user.human.passwordless.token.added and user.human.passwordless.token.verified. “Added” can represent a registration stage; verification plus supported credential state helps establish completion. Sequence orders events, but nearby events alone do not prove they share an enrolment. Benign/limits: replacement devices, onboarding and approved recovery. Confirm ownership through a trusted channel independent of the potentially affected account. Escalate an unrecognised credential linked to an unauthorised issuer, even without a visible later login. C05 — Follow account use and actual consequences. Action/location: examine later authentication and applications granted to the target user. Signal: successful use linked to the unexplained authenticator or corroborated unauthorised application actions. Correlate account, organisation, credential ID where available, session/request references, UTC time and application identity mapping. Source pivot: user.human.passwordless.token.check.succeeded. This is normal passwordless authentication telemetry. It is not a CVE-specific IOC. Verify trusted proxy/source-address semantics; familiar and unfamiliar IPs both need context. Benign/limits: VPNs, ordinary passkey logins, device changes and approved work. Escalate supported unauthorised use with actual account privileges and applications stated. Do not infer exfiltration, global administration or host persistence from capability. Missing credential-to-session linkage leaves attribution uncertain. C06 — Verify remediation and account investigation separately. Action/location: compare every serving build with its repair floor, then reconcile suspicious credentials/sessions against the private incident timeline and owner decisions. Signal: all serving nodes repaired, with account changes reviewed in the agreed scope. Correlate build evidence, rollout times, exposure window and account-state decisions. Benign/limits: rolling upgrades and cached inventory can disagree. Escalate a vulnerable node still serving, unexplained credential state or closure without the required sources. A software patch does not establish revocation of earlier codes, authenticators or sessions; review those through supported controls with the owner. 📍 IOC STATUS AND COVERAGE LIMITS No CVE-specific malicious domains, IPs, hashes or campaign infrastructure were verified in the reviewed primary evidence. The event names above are behavioural pivots present in legitimate workflows, not standalone compromise indicators. Record instance, organisations, UTC window, sources, permissions, pagination and historical-grant coverage in any negative finding. Distinguish examined/no matches from expired, not collected, not exported and field unavailable. A patch check or zero-row hunt cannot certify a clean account. 🧰 TOOLS AND BOUNDED CHECKS Collect through supported ZITADEL administration facilities and the client's approved audit/SIEM interfaces. The examples read runtime metadata or existing local JSON; they do not test enrolment. Confirm case scope and schema first, and bound the export's UTC window before parsing. Large files still consume local resources. 1. Docker inventory, one known container. Illustrative name: cf-zitadel. Requires authorised Docker management access, which is powerful; analysts can instead use an owner-provided inventory export. Prints no environment variables. ~~~sh docker container inspect cf-zitadel | jq -e ' if type != "array" or length != 1 then error("expected one container") else .[0] | {name:.Name, image_ref:.Config.Image, image_id:.Image, state:.State.Status} end' ~~~ Output: name, configured image reference, immutable image ID and state. Reconcile build provenance and every replica with the owner. A tag alone does not establish patch state. Only the JSON projection was tested locally; no Docker daemon was queried. 2. Native event metadata. Input zitadel-events.json: authorised, bounded, fully paginated Admin v1 ListEvents JSON, using the v4.17.1 Event schema. Protect the original; payloads may contain enrolment secrets and are excluded here. ~~~sh jq -e ' if type != "object" or (.events | type) != "array" then error("confirm export schema or an omitted empty events field") else .events as $all | [$all[] | select(.type.type == "user.human.passwordless.initialization.code.added" or .type.type == "user.human.passwordless.token.added" or .type.type == "user.human.passwordless.token.verified" or .type.type == "user.human.passwordless.token.check.succeeded") | {sequence, utc:.creationDate, event:.type.type, actor:.editor.userId, target:.aggregate.id, target_org:.aggregate.resourceOwner}] as $rows | {exported_events:($all|length), matched_events:($rows|length), rows:$rows} end' zitadel-events.json ~~~ Output: this input's event count, matching count and metadata rows. Confirm omitted empty protobuf fields before normalising to an explicit empty array. An error needs schema/collection review. Counts do not establish complete instance coverage. 3. Request-scope comparison. Input zitadel-scope-join.json is a Forge-normalised array, NOT a native export. Populate the six named fields from verified case records. requested_org_id is recorded request context; target_org_id is actual target ownership. Never substitute the actor's home organisation or guessed values. ~~~sh jq -e ' def present: type == "string" and length > 0; if type != "array" or any(.[]; type != "object") then error("expected an array of normalised request records") else . as $all | [$all[] | select((.requested_org_id|present) and (.target_org_id|present))] as $known | [$known[] | select(.requested_org_id != .target_org_id) | {time_utc, actor_user_id, requested_org_id, target_user_id, target_org_id, request_id}] as $rows | {records:($all|length), missing_org_fields:(($all|length)-($known|length)), scope_mismatch_candidates:($rows|length), rows:$rows} end' zitadel-scope-join.json ~~~ Output: input count, missing-organisation coverage and mismatch candidates. Legitimate global administrators can appear; check effective target rights and operation. Same-organisation rows do not establish that all other authorisation checks passed. Validation: jq 1.8.2; 16 synthetic scenarios passed: foreign/same-org comparisons, an authorised global actor, missing fields, empty inputs, wrong shapes, malformed JSON and secret-canary exclusion. No production ZITADEL, Docker or SIEM calls were run. Vendor event names/schema were source-checked; client mappings and export coverage still require confirmation. 🛠️ REMEDIATE, CONTAIN AND VERIFY Upgrade through the supported process to an appropriate patched release, using 3.4.15 or 4.17.1 as the correct train's minimum repair floor. Plan authentication availability and recovery; verify actual running binaries/image digests across serving and recovery nodes after rollout. The vendor offers no complete configuration workaround. Reviewing unnecessary credential-management privileges and limiting management-interface reachability can reduce risk temporarily. Those are Forge recommendations, not a vendor-certified repair. A WAF or blanket header restriction does not prove the target-user authorisation defect is closed. If evidence supports suspicious account changes, preserve it and use supported controls to remove unauthorised authenticators, address relevant sessions and outstanding enrolment material, and review downstream activity with the incident owner. The disclosure does not specify automatic revocation of all earlier artefacts after upgrade. Existing victim credentials are not disclosed by this flaw. Broader password/MFA recovery decisions should follow observed activity and the client's incident process. Keep legitimate strong authentication available where possible. Accept software remediation with fixed-build evidence for every serving node. Accept incident closure separately with account decisions, examined history, application review and remaining telemetry gaps recorded and owned. 📂 EVIDENCE, ANALYSIS AND UNKNOWNS Vendor/CNA facts: missing target-scope authorisation, authenticated management prerequisite, cross-organisation account takeover capability, affected trains, fix floors and scores. Static source review: target-owner checks, event/schema fields and published regression-test coverage. Forge analysis: the issuer-to-target permission join, collection priorities, false-positive review, temporary access reduction and escalation trail. These are investigation recommendations, not evidence of an attacker campaign. Deployment unknowns: historical builds/grants, retained-record completeness, whether a code was issued or redeemed without authority, and actual account/application consequences. Field exploitation or a standalone public PoC was not verified in this review; public patches and regression-test source are available. 🔥 CYBERFORGE VERDICT Strong authentication begins with authority to enrol it. For an affected ZITADEL instance, make the target organisation's permission boundary the centre of the case: identify the eligible issuers, repair every serving node, and follow any unexplained new authenticator into its actual use. Keep three decisions separate and evidenced: exposure, software remediation and account/incident closure. 🧾 ANALYST HANDOVER Keep the private record of scope/window, builds, issuer rights, event/request references, target account/credential state, relevant application activity, benign explanations, source gaps, remediation evidence and next owner. Link each conclusion to the records that support it; exclude enrolment material and sensitive client identifiers from public copy. 🔗 PRIMARY SOURCES AND SUPPORTING DOCUMENTATION Vendor advisory: https://github.com/zitadel/zitadel/security/advisories/GHSA-pq2q-2c6r-75c4 CVE / CNA record: https://www.cve.org/CVERecord?id=CVE-2026-105209 NVD record: https://nvd.nist.gov/vuln/detail/CVE-2026-105209 Fixed-release notes: https://github.com/zitadel/zitadel/releases/tag/v3.4.15 https://github.com/zitadel/zitadel/releases/tag/v4.17.1 CVE-specific permission-check patches: https://github.com/zitadel/zitadel/commit/67f9d29919135cbeb13a078fcf61b84e17aa0a3c https://github.com/zitadel/zitadel/commit/76dd58ecdf3b6fcb9fb321c9ba7d009fcfa345e5 Vendor audit API and versioned event schema: https://zitadel.com/docs/reference/api/admin/zitadel.admin.v1.AdminService.ListEvents https://github.com/zitadel/zitadel/blob/v4.17.1/proto/zitadel/event.proto https://github.com/zitadel/zitadel/blob/v4.17.1/internal/repository/user/human_mfa_passwordless.go CISA KEV / FIRST EPSS: https://www.cisa.gov/known-exploited-vulnerabilities-catalog https://api.first.org/data/v1/epss?cve=CVE-2026-105209 Tool documentation: https://docs.docker.com/reference/cli/docker/inspect/ https://jqlang.org/manual/ #CyberForge #CVE #ZITADEL #BlueTeam #SOC #IdentitySecurity #Passkeys
