Session CRT-20261010 — 10 October 2026 · Morning Edition

My position is that repository cleanup is containment, not recovery. For GhostAction, GitGuardian reports compromised identities committing malicious workflows into 772 repositories, with workflows exfiltrating explicitly referenced CI/CD secrets to 193.32.204[.]199; reported indicators include github_actions_security.yml, security-check.yml, and the associated commit messages. Other reporting says variants searched current files and Git history for secrets. Defenders therefore need to trace four linked planes: the compromised maintainer identity, every workflow execution, every credential available to those runs, and every package, image, deployment, or release produced afterward. Deleting the YAML addresses only one plane.

The incidents need different recovery boundaries. MALFEX packages used npm installation scripts to infect Windows systems, including delivery chains involving signed AutoIt, the Overlord RAT, the movinlike stealer, and process hollowing; installations of the named packages—such as function-flag, cdn-img-fetch, native-runner, and mxdriver—justify endpoint isolation and rebuild where execution is confirmed. Tensorlake 0.5.144 is reported as compromised by Shai-Hulud, while Semgrep describes a related maintainer compromise cascading across hundreds of packages. I would quarantine that version and descendants built with credentials exposed to it, but the available evidence does not establish whether Tensorlake’s npm publishing token enabled secondary publication. The connected npm/RubyGems reporting also does not give enough evidence here to assign package-specific persistence, so defenders should not merge its indicators with MALFEX or Shai-Hulud without corroboration.

What can be hunted: workflow filenames and commits, execution logs, outbound connections, npm lifecycle-script execution, named MALFEX packages, suspicious maintainer changes, package-publish events, release hashes, container digests, and cloud/OIDC audit records. What must be revoked and rotated: every token, key, session, deploy credential, package-registry token, signing key, cloud credential, and GitHub App secret accessible to confirmed malicious execution—not merely credentials observed in exfiltration logs. What must be rebuilt: Windows developer or runner hosts where MALFEX executed, and artifacts produced after the earliest verified identity or runner compromise unless independent reproduction proves equivalence. Valid provenance is not proof of safety: it can accurately attest that a compromised workflow built malicious source, or that a compromised publisher signed and uploaded the artifact.

Six-hour CISO plan:

• 0–30 minutes: Freeze affected GitHub Actions, npm/RubyGems publishing, releases, and deployments; preserve workflow, registry, identity, cloud, endpoint, and network evidence.
• 30–90 minutes: Build the blast-radius ledger: affected identities, repositories, workflow runs, runners, secret scopes, package versions, artifacts, and downstream consumers. Pull SBOMs and lockfiles to identify transitive use.
• 90–180 minutes: Revoke before rotating, prioritizing GitHub, package-publishing, signing, cloud, and OIDC authority. Remove unauthorized maintainers, deploy keys, apps, webhooks, and sessions.
• 180–270 minutes: Isolate confirmed MALFEX execution hosts; invalidate packages, images, and releases created during the exposure window; notify internal consumers not to restore from caches.
• 270–360 minutes: Rebuild only confirmed execution systems and untrusted artifacts on fresh runners from a reviewed commit. Pin dependencies by hash, issue new signing material, require Sigstore/provenance verification, and run SCA plus lifecycle-script controls in CI. Keep publication frozen until identity, build, registry, and consumer evidence reconcile.

Halil, the trust chain is compromised maintainer account → malicious workflow on repositories that account could modify → runner-accessible credentials or repository history → downstream cloud, registry, and SaaS identities. Fact: reporting says security-audit.yml collected GitHub tokens, package-publishing tokens, cloud and AI-service credentials, and searched current source plus Git history for deleted secrets; results were sent to 193.32.204[.]199. Assessment: any SaaS/API key available to the runner belongs inside that same blast radius. OIDC is different: the attacker may not steal a durable cloud key, but if the workflow could request an OIDC token and satisfy a cloud trust policy, it could obtain temporary role sessions. Whether that happened remains unknown until workflow permissions and cloud token-exchange logs are examined.

The defensible order is: (1) remove attacker write access, disable the injected workflow, preserve workflow/audit logs, and suspend affected automation; (2) revoke compromised GitHub sessions, personal access tokens, app tokens, deploy keys, OAuth grants, and other repository identities; (3) close OIDC issuance paths or narrow cloud trust policies before invalidating cloud access keys and terminating temporary role sessions; (4) revoke package-registry publishing tokens and inspect packages, releases, images, and ownership changes; (5) rotate SaaS/API and AI-service credentials, revoking associated sessions and refresh tokens; (6) rotate every still-valid secret found in repository history. Rotation without first closing the workflow and federation paths merely lets the attacker mint or steal replacements.

Use three evidence levels. Exposed means the credential was present in reachable secrets, environment data, source, or history while the malicious workflow ran, especially where logs show collection or attempted exfiltration. Used requires provider-side evidence: GitHub audit events, cloud role assumptions or API calls, registry publication, or SaaS/AI API activity attributable to that identity after exposure. Persistent means the attacker established a surviving trust path—an unauthorized maintainer, deploy key, OAuth/GitHub App grant, cloud principal or altered role trust, new registry owner/token, webhook, refresh token, or still-valid session. Those are investigation targets, not yet confirmed GhostAction artifacts.

Deleting security-audit.yml and rotating one repository secret therefore does not end the incident. The reporting describes compromised maintainers modifying multiple repositories and workflows harvesting both active and historically committed credentials. The incident ends only when every credential issuer, active session, delegated grant, federation relationship, and downstream identity reachable from the workflow has been accounted for—not when the visible YAML disappears.

For internet-reachable affected systems, my compromise-response queue is:

1. PaperCut CVE-2026-82077/82078/81578. Active exploitation, a pre-auth RCE chain, and reported patch bypasses close the initial-access chain. CVE-2026-81578 bypasses authentication; CVE-2026-82078 enables unsafe dynamic class loading through a database connector. Treat exposure as suspected compromise, not a maintenance ticket. Preserve application and access logs, configuration and database-connector settings, process listings, memory, network telemetry, and filesystem changes before restarting. Patching alone is insufficient because bypasses have already been demonstrated.
2. Zimbra CVE-2024-45519. Active exploitation has produced backdoors and web shells—the persistence question is already answered. Preserve web roots, process trees, mail and authentication logs, shell history, scheduled tasks, outbound connections, and volatile memory. Merely patching after a web shell lands is like changing the lock while the burglar is sleeping upstairs.
3. Flax Typhoon’s five KEVs. This moves above Zimbra for any organization actually exposing the affected ProFTPD, ONLYOFFICE Docs, Strapi, Apache Struts, or ISC BIND systems—especially critical infrastructure. Reported operations combined vulnerability exploitation with VPN persistence, Exchange password spraying, and email or credential theft. Preserve affected-product logs, VPN and identity logs, Exchange authentication records, scripts, outbound transfers, and OT boundary telemetry. Patch, then revoke sessions and rotate exposed credentials.
4. SonicWall SMA1000 SSRF. Exploitation attempts are reported, but the available evidence does not establish the same complete RCE-to-persistence chain shown for PaperCut or Zimbra. Preserve appliance logs and configuration, reverse-proxy requests, DNS and outbound connections, administrative changes, and memory where feasible. Patch and investigate; do not claim confirmed compromise from scanning alone.

Next six hours: First, identify exposed instances and remove them from direct internet access; isolate PaperCut and Zimbra immediately where vulnerable or recently patched. Second, capture volatile and off-box evidence before rebooting or upgrading. Third, patch to the latest fixed releases, but simultaneously hunt for persistence and rotate administrative, database, VPN, service-account, API, and active-session credentials reachable from those systems. Any confirmed shell, unexplained administrator change, tunnel, or evidence deletion should trigger containment and clean rebuild—not “patch and watch.”

For Flax Typhoon/Integrity Technology Group, confidence is high on exploited vulnerabilities and enabling infrastructure, moderate on the broader organizational linkage, and low on direct state tasking for every intrusion. This supports ATT&CK T1190—Exploit Public-Facing Application, but not blanket attribution across all infrastructure users.

For P7 DarkSword, iVerify states that it investigated a DarkSword infection in August 2026. The available evidence supports iOS data theft and remote-command capability, but does not independently establish the COLDRIVER link through infrastructure, operator, or forensic pivots; confidence is low. For UAT-11587/Antino, targeted espionage activity is supported, while direct state sponsorship remains low confidence.

The domain seizures constitute tactical disruption, but durable capability loss remains unproven. Operators of vulnerable internet-facing systems—especially critical infrastructure—and high-risk iPhone users handling cryptocurrency or sensitive communications should change posture now.