Session CRT-20260703 — 3 July 2026 · Morning Edition

Put these in the likely-compromised today bucket if internet-facing or recently exposed: Langflow CVE-2025-3248 / CVE-2026-33017, Citrix NetScaler CVE-2025-5777 with Anubis, FortiBleed/FortiGate, and on-prem SharePoint CVE-2026-45659. Patch-only is not enough there. For Langflow, the pack ties JADEPUFFER to active exploitation, credential theft, cloud/API/database pivoting, and destructive database activity; SCWorld also reports CVE-2026-33017 being exploited to deploy a Monero miner. That is a closed kill chain, not theoretical risk. Treat exposed Langflow like a burglar found inside the house: rotate secrets, hunt database access, inspect cloud keys, and rebuild if compromise signs appear.

SharePoint CVE-2026-45659 is also ugly: the visible sources say CISA added it to KEV, active exploitation is confirmed, and exploitation can be triggered over the network by a low-privileged authenticated user on on-prem SharePoint. Internet-facing SharePoint farms go into likely-compromised plus forensic triage; internal-only farms with tight auth can be patch-immediately plus hunt. FortiBleed/FortiGate and NetScaler CVE-2025-5777/Anubis sit in the same “edge device may already be owned” class because the pack marks active in-the-wild exploitation and ransomware linkage. For edge boxes, assume stolen sessions, harvested creds, and persistence until proven otherwise.

For Oracle EBS CVE-2026-46817, Citrix NetScaler CVE-2026-8451, and Cisco Unified CM CVE-2026-20230, I don’t have enough visible detail here to honestly call them likely-compromised. So my CISO action is: patch immediately, restrict exposure now, and promote to likely-compromised if you confirm internet exposure, active exploitation telemetry, reliable public exploit code, KEV listing, webshells, suspicious admin activity, or credential/session theft. If Cisco Unified CM turns out to be unauthenticated RCE on exposed management or API surfaces, it jumps fast — UC systems are a control-plane prize.

Halil, I’d separate this cleanly: the JADEPUFFER headline is “agentic ransomware,” but the control failure is much more ordinary and more actionable — exposed AI workflow infrastructure with code/tool execution paths and credentials attached. CyberBrief has JADEPUFFER as a critical Langflow ransomware breach, and the Langflow cryptomining item as active exploitation of a critical Langflow issue to deploy a Monero miner. That does not require the model to “go rogue.” It means natural-language workflow systems are now sitting on privileged execution rails.

What to do tonight: inventory every Langflow, Dify, MCP server, AI browser, coding agent, and internal agent runner; remove public exposure; patch Langflow and Dify, especially Dify CVE-2026-41948; rotate tokens reachable from those systems; disable shell/database/admin tools unless explicitly allowlisted; require human approval for destructive or exfiltration-capable actions; and hunt for Base64 Python execution, unexpected Python child processes, miner behavior, unusual outbound database reads, and agent tool calls that do not match user intent. For MCP specifically, pin and review tool descriptions like code: Microsoft and OWASP both describe tool-description poisoning as a trust-boundary issue where metadata read by the model can redirect tool behavior.

Where the pack may be overhyping: “first agentic ransomware” risks implying novel autonomous intelligence. The evidence points more strongly to traditional exploitation plus unsafe agent/workflow authority. Where it may be undercalling risk: MCP tool descriptions, coding-agent command guards, and AI browsers turn text into a control plane. If those systems can read secrets or invoke commands, prompt injection becomes closer to SSRF/RCE-by-proxy than a chatbot nuisance. I’d treat Chain-of-Thought Forgery as lower immediate operational priority unless it is tied to audit, eval, or approval workflows; I don’t have enough evidence here to characterize BioShocking or the coding-agent guard bypasses beyond saying they fit the same pattern: model-mediated decisions crossing into privileged action.

The immediate move is not “reset passwords”; it is collapse attacker trust state.

FACT: The Microsoft 365 evidence here points to OAuth consent phishing, device-code authorization abuse, and token theft against M365 accounts. That means you must revoke: user sessions, refresh tokens, OAuth app grants, device-code-authorized sessions, and any risky enterprise app consent tied to mailbox, SharePoint, OneDrive, Teams, Graph, or offline access scopes. Disable or tightly restrict user consent, require admin consent workflow, review all newly consented apps, and block device-code flow where the business does not explicitly need it. For ARToken-style attacks, assume the attacker may have usable bearer tokens even if the password was never captured.

FACT: The ToddyCat-linked Umbrij item is specifically described as Gmail OAuth token access. For Google Workspace, revoke OAuth app grants, invalidate refresh tokens, reset active browser sessions, review domain-wide delegation, service accounts, third-party Marketplace apps, Gmail API access, and mail-forwarding rules. If the actor has OAuth access, changing the user’s Google password alone does not reliably remove the delegated application’s access.

For FortiBleed, KDDI email passwords, and Langflow cloud/API-key exposure, I’m going to separate what I can say confidently from what I won’t invent. ASSESSMENT: if Fortinet edge credentials were stolen, treat every VPN, admin, API, and SSO-linked session through that appliance as suspect: revoke VPN sessions, rotate local admin accounts, API keys, RADIUS/LDAP bind credentials, SAML/OIDC secrets, and any saved FortiGate-to-IdP integration credentials. For KDDI-style email password exposure, revoke mail sessions, reset passwords, invalidate app passwords, kill legacy IMAP/POP/SMTP AUTH where possible, and review mailbox rules. For Langflow/API-key exposure, rotate cloud keys, model-provider API keys, Git tokens, CI/CD secrets, service account keys, and any OAuth client secrets loaded into flows. UNKNOWN: I do not have enough sourced detail here to name the exact KDDI or Langflow affected credential classes beyond the scenario you gave.

Priority order: kill refresh tokens and OAuth grants first, then active sessions, then delegated admin/application relationships, then long-lived service credentials. And where humans are authorizing access, move the high-risk population to phishing-resistant authentication — FIDO2/passkeys for workforce accounts — because push/SMS MFA does not fix consent phishing or device-code abuse.

Halil, from the malware lens, I’d split this set into two escalation buckets: destructive intent and credential-theft / follow-on access. The clearest destructive signal is Anubis with /WIPEMODE, but I don’t have enough sourced binary detail in front of me to validate the exact implementation path, so I would not over-name it beyond “wiper-mode behavior reported.” If hunters see RMM tooling paired with a wipe flag or wipe-like command argument, treat that as an emergency breakpoint — not normal ransomware staging. RMM plus destructive switches means the attacker may already have interactive control and is moving from monetization to denial-of-recovery.

On credential theft, ChocoPoC is the sharpest signal. The sourced reporting says fake GitHub PoCs pull malicious Python dependencies such as frint and skytext; skytext carries the payload, and execution leads to theft of browser passwords, cookies, shell history, network settings, local files, plus arbitrary shell/Python command execution. That is not “just a fake exploit repo” — that is developer-workstation compromise with source-control and session-token blast radius. The Mapbox/domain-fronting C2 detail is also important: hunters should not only search for obvious unknown C2 domains, but for unusual Mapbox-looking API traffic from Python processes launched after pip install or PoC execution.

For JADEPUFFER and Langflow, I’d hunt the interpreter layer first. JADEPUFFER is reported as using Base64/Python payloads in a ransomware breach context; Langflow exploitation is reported as deploying a Monero miner. In both cases, the pattern I care about is encoded script material spawning from an application runtime, then persistence or cleanup behavior. For Langflow specifically, if log removal is present in your telemetry, that is a post-exploitation maturity marker: the miner is noisy, but deleting logs means the actor cares about dwell time and re-entry, not just CPU theft.

First hunts:

1. Python processes launched by Langflow, PoC folders, shell scripts, or package install hooks.
2. Base64 decode/execution chains: python -c, exec(base64.b64decode(...)), suspicious temp-file writes.
3. New persistence around cron, systemd, LaunchAgents, login items, or RMM service creation.
4. Browser credential/cookie access from non-browser processes, especially Python payloads.
5. RMM sessions followed by wipe-like flags, shadow-copy deletion, log deletion, or recovery obstruction.