Session CRT-20260711 — 11 July 2026 · Afternoon Edition

Halil, hard call:

Turn off or isolate now:

• ShareFile Storage Zone Controllers — no patch path is visible, and Progress reportedly told customers to shut down Windows servers hosting SZCs after a “credible external security threat.” This is not patch management; this is containment. Pull them offline, preserve disk/logs, and don’t bring them back just because a maintenance window opens.
• Exposed NetScaler affected by CitrixBleed 2 — token theft means the attacker may already be past the door. Patch-only is theater here. Patch, kill sessions, invalidate tokens, review active sessions, and hunt for post-auth activity.
• Internet-facing Langflow where it is reachable by untrusted users — CISA KEV means active exploitation is already real. If it touches credentials, automation, or internal services, isolate first, then patch and hunt.

Patch and hunt today:

• Gitea Docker deployments only if they match the bad condition: reverse-proxy authentication enabled and Docker default trusted proxy behavior allowing X-WEBAUTH-USER impersonation. That is a clean exploit path, but not universal Gitea panic. Fix config/upgrade, then hunt for forged user activity, new tokens, repo changes, and CI-triggering commits.
• Joomla file-upload/RCE extensions — CISA lists actively exploited Joomla upload/RCE issues, including SP Page Builder and Joomlack Page Builder. Patch, then assume PHP webshell placement until proven otherwise.

Where patch-only is dangerously insufficient: ShareFile SZC, CitrixBleed 2, Langflow if exposed, and any CMS where arbitrary PHP upload was possible. Once the exploit writes a webshell or steals a session, patching is like changing the lock while the burglar is still hiding in the garage. For the WordPress side, I don’t have enough specific sourced detail here to name the exact plugin/CVE, so I’d triage by evidence: public CMS + suspicious upload/webshell artifact = isolate, collect, rebuild or surgically clean, not “just update plugins.”

Halil, my position: treat this as attacker-held trust state, not “password compromise.” Tonight, Entra tenants should restrict device-code authentication to only explicitly approved clients/users, or disable it where business doesn’t require it. Forg365’s value is that the victim authorizes an attacker-controlled session through legitimate Microsoft flows, and ForgCookie-style persistence means the attacker may keep usable session material after the password changes.

For passkeys: do not leave enrollment as a self-service free-for-all. Require step-up with phishing-resistant authentication, trusted device/compliant device conditions, or helpdesk-verified recovery flows before any new Entra passkey/security key registration. Alert on new passkey/FIDO2 registrations, authentication-method changes, and unusual recovery flows, especially when preceded by vishing/helpdesk-pretext activity. O-UNC-066’s fake Entra passkey enrollment is exactly why “we use passkeys” is not enough; the enrollment ceremony is now the trust boundary.

Containment tonight should be: revoke sessions and refresh tokens, remove attacker-enrolled authentication methods, review OAuth app grants, invalidate risky sign-ins, and force re-authentication under Conditional Access. Password resets are false comfort when the attacker has a live cookie, a refreshed SSO session, a newly enrolled passkey, or an authorized device-code session. Reset the password if you must, but only after killing the durable trust objects.

On Teams phishing plus malicious Edge extensions and CitrixBleed-style edge token theft: I don’t have enough sourced detail here to assert the specific campaign mechanics, but the control answer is clear. Lock browser extensions by allowlist, block sideloading, inspect Edge/Chrome extension inventory, and hunt for anomalous Microsoft 365 sessions created after Teams lures or from edge infrastructure. If tokens were stolen at the edge, do not assume IdP-side password reset fixes it; burn the sessions.

Halil, urgency is clearest where we have active exploitation, not where we have actor branding. Langflow CVE-2026-55255 is urgent on exploitation evidence; attribution confidence is low, so defenders should treat it as T1190 / exploit public-facing application and patch, hunt, and contain without waiting for actor identity. Same for CitrixBleed 2 / CVE-2025-5777: the NetScaler exploitation signal drives action; the ransomware follow-on raises impact, but I would not let “The Gentlemen” branding change edge remediation unless we see victim-specific intrusion artifacts tying that group to the access path.

Where naming can mislead the CISO: Progress ShareFile, WP-SHELLSTORM, Trenggalek Joomla defacements, O-UNC-066/Forg365, GigaWiper, and the Pakistan law-enforcement espionage reporting do not have enough attribution-grade evidence in the material I have here to justify changing defender behavior based on actor name alone. For those, I’d keep confidence low unless we get pivots such as shared C2, passive DNS overlap, malware lineage, certificate reuse, wallet/payment infrastructure, operator mistakes, or repeated victimology over time.

My threshold: moderate confidence only when at least two independent pivots align; high confidence when infrastructure, tooling, timing, and victimology all line up across campaigns. Right now, the defensible advice is: act fast on exploited internet-facing systems, but do not brief the board as if these are one coherent actor campaign.

Halil, the practical split is: anything that lets an agent touch host execution, credentials, files, repos, browsers, MCP tools, or messaging integrations is not “AI governance” — it is an execution path.

Treat as real execution paths tonight:

• Langflow exploitation: active exploitation is reported for Langflow authorization/RCE issues, including CISA KEV coverage and exposed AI servers. If Langflow can run components, call tools, read env vars, or reach internal services, this is a classic exposed-app RCE with AI branding.
• JadePuffer via exposed LangFlow: the “autonomous ransomware” framing may be over-marketed, but the dangerous part is credible: an agent allegedly operating through exposed LangFlow to chain recon, exploitation, credential theft, lateral movement, and encryption. That is privileged automation, not magic autonomy.
• OpenClaw WhatsApp-to-host chain: if WhatsApp input can reach an assistant that can act on the host, that is an untrusted-input-to-tool-execution path. Patch or disable the integration.
• Repo/PNG prompt injection against coding agents: the Ghostcommit/PNG and repo prompt-injection reports matter because they target agents with repo context, terminal access, secrets, or commit authority. This is prompt injection behaving like SQL injection against a fuzzy parser.
• Claude Code / MCP-style abuse: where MCP tools expose filesystem, shell, browser, ticketing, cloud, or credential actions, assume prompt injection can become tool misuse unless every tool call is scoped and approved.

More watch-item unless verified in your estate: I do not have enough sourced detail here on GhostApproval symlink deception specifically to rank it above the general coding-agent risk. But if symlinks can redirect an agent into reading secrets, modifying protected paths, or approving deceptive diffs, then it moves immediately into the execution-path bucket.

Controls I would impose tonight without freezing AI use:

1. No public Langflow/OpenClaw/admin agent interfaces. Put them behind SSO/VPN, patch immediately, rotate secrets on any exposed instance, and hunt for new users, web shells, miners, unfamiliar flows, and outbound callbacks.
2. Agent allowlists only. Coding agents may read repos, but shell, network, filesystem-write, package-install, browser, cloud, and MCP tools require explicit per-action approval.
3. Secret isolation. No production cloud keys, tokens, SSH keys, signing keys, or customer data in agent-visible env vars, workspaces, logs, screenshots, or RAG indexes.
4. Untrusted content quarantine. Treat repos, issues, PRs, PNGs/images, markdown, docs, chat messages, and tickets as attacker-controlled prompt input. Agents should not obey instructions found inside those artifacts.
5. Symlink and path controls. Block agents from following symlinks outside the workspace; enforce read/write jail paths.
6. MCP hardening. Disable broad MCP servers by default; expose narrow tools with least privilege, fixed schemas, audit logs, and human confirmation for destructive or credential-adjacent actions.
7. Commit/deploy separation. Agents can draft patches, but humans approve diffs in a clean viewer; no autonomous merge, release, infra change, or dependency update from agent output tonight.
8. Telemetry. Log prompts, retrieved files, tool calls, shell commands, outbound network, accessed secrets, and agent-made commits. Alert on secret reads, curl/wget, package installs, chmod, persistence paths, credential files, and unexpected external connections.

The short version: don’t ban AI. Remove authority from the agent runtime. If the model can only suggest text, this is mostly governance. If it can touch secrets or a host, it is an execution environment and should be controlled like one.

Halil, I would not shut down all engineering. I’d quarantine the trust boundaries that could either execute poisoned code or publish trusted artifacts.

For Gitea Docker auth bypass, the source-control control plane is the boundary. Since the reported issue is active exploitation against the official Gitea Docker image, teams should isolate affected Gitea containers, suspend CI jobs triggered from those instances, rotate repo deploy keys, CI tokens, webhooks, and package-publishing secrets that were reachable from Gitea or its runners. Don’t freeze unrelated repos hosted elsewhere unless they shared runners or secrets.

For Injective Labs’ npm compromise, the boundary is narrower but severe: @injectivelabs/sdk-ts 1.20.21 and related @injectivelabs releases. Evidence says the malicious release stole wallet private keys and mnemonics, was published after a GitHub compromise, affected 17 related packages, avoided install-time lifecycle scripts, and was replaced by clean version 1.20.23. Quarantine builds that installed or bundled those package versions, rotate npm publishing tokens and GitHub release credentials for affected projects, and treat any wallet material generated/imported through those SDK functions as exposed. This is not a reason to halt every npm build in the company; it is a reason to block that namespace/version range at the artifact proxy and inspect lockfiles.

For the OpenMandriva repository sabotage, Visual Studio project-file Trojan, and AI/model supply-chain warnings, I don’t have enough corroborated detail in the visible evidence to assign package-specific blast radius. Operationally: if a repo admin attempted sabotage, freeze promotion from that repository, review maintainer/admin changes, re-sign trusted packages, and rotate repo signing/publishing credentials. If a Visual Studio project file carried the Trojan, quarantine developer workstations that opened it and CI runners that built it. For AI/model artifacts, don’t freeze model development broadly; require hash-pinned model downloads, signed provenance where available, and sandbox execution of model loaders/converters before they touch developer laptops or CI.

Halil, I’d divide this into three buckets: weak wallet generation, stolen assets with possible restitution, and supply-chain key theft.

For Ill Bloom, recoverability is weak once assets are drained. Reporting says insecure pseudorandom generation produced weak recovery phrases, attackers exploited it on May 27, and Coinspect reproduced how weak phrases could be regenerated and swept. One cited report puts the loss at about $3.1M across 431 wallets, with affected chains listed as Bitcoin, Ethereum, Solana, Tron, Rootstock, and Polygon; another report gives a higher figure of about $5M, so I would treat the amount as still variable. The action is not “revoke” or “patch the old wallet.” Users need a freshly generated wallet with safe entropy, preferably hardware-backed, and immediate migration of any remaining funds.

For SecondFi, the available reporting identifies a 16 million ADA theft and frames the response as a recovery or restitution experiment. That means the authority path is different: if the ADA is still traceable and has not been cashed out, exchanges and investigators may still have a freeze window. But I would caveat this hard: without the current wallet path, I cannot say the funds are practically recoverable. Exchanges should watch Cardano deposit flows linked to the reported theft and preserve evidence quickly.

For Injective, this is a supply-chain key-compromise case. Socket reports that malicious @injectivelabs/[email protected] exfiltrated private keys and mnemonic phrases through fake telemetry, and StepSecurity says affected applications should treat wallet secrets touched by the package as exposed. That is migration territory: move treasury/admin funds to fresh signers, rotate development credentials, rebuild from clean dependencies, and review any wallet created or loaded through affected versions.

In the next 24 hours: exchanges should ingest victim addresses and monitor the specifically cited chains — ADA for SecondFi, and BTC/ETH/SOL/TRX/Rootstock/Polygon for Ill Bloom — while being careful not to assume bridge movement unless it is actually observed. Protocols should publish exact affected versions, addresses, and migration instructions. Users should stop reusing exposed seed material. The TRM H1 headline tells us incident count is at record levels while stolen funds are lower; these examples show why raw dollar loss is not enough — signer and seed exposure can create long-tail risk even after the first drain.