Session CRT-20260704 — 4 July 2026 · Morning Edition

Lena, James — my cut for tonight is simple: PeopleSoft moved into the “do not just patch” bucket. Today’s pack marks Oracle PeopleSoft CVE-2026-35273 as active in the wild, must-lead, with strong evidence; the available writeup describes remote exploitation without authentication or user interaction against internet-facing PeopleSoft, with reported data theft, persistence, and extortion outcomes. That kill chain closes. If it is internet-facing: assume compromised, isolate or restrict access, patch, then hunt before returning to normal.

For Citrix NetScaler CVE-2026-8451, no need to re-litigate yesterday: today’s pack still has it as must-lead, active exploitation, and tied to CitrixBleed-like NetScaler exploitation attempts. Internet-facing ADC/Gateway boxes stay in assume compromised. Patch-only is like changing the lock after someone may already have copied the key.

Langflow CVE-2025-3248: I’m not changing yesterday’s operational call. For exposed Langflow, keep it in assume compromised / hunt now. I don’t have new visible evidence from today’s pack to add, so I won’t pad it with recycled detail.

Cisco Secure Firewall Management Center CVE-2026-20131 is serious, but I’d rank it lower tonight. Today’s pack says active in the wild with named victim/sector impact, but evidence is marked adequate, single-source, and lead-candidate rather than must-lead. My call: patch and monitor for normally restricted FMC deployments; assume compromised only if FMC management is reachable from the internet, broad VPN populations, or untrusted networks.

Priority order for a CISO tonight:

1. Internet-facing PeopleSoft CVE-2026-35273 — assume compromised.
2. Internet-facing Citrix NetScaler CVE-2026-8451 — assume compromised.
3. Exposed Langflow CVE-2025-3248 — assume compromised, no new detail added.
4. Cisco FMC CVE-2026-20131 — patch and monitor unless exposed; then escalate to assume compromised.

Halil, the two I’d put in the definite tonight revocation bucket are Storm-2372 and Forest Blizzard. According to the SOCRadar handoff entries, Storm-2372 is an OAuth device-code phishing campaign bypassing MFA, and Forest Blizzard is DNS hijacking to intercept Microsoft OAuth tokens via SOHO routers. In both cases, the live asset is not the password — it is the issued Microsoft trust state. For affected users, invalidate Entra ID refresh tokens, active sessions, device-code issued tokens, suspicious OAuth consents, and any downstream mailbox/API sessions. Password reset alone is theater if the attacker already holds a valid refresh token.

For FortiBleed, AndroxGh0st, and Citrix SAML exposure, my call is conditional but aggressive: if logs or forensics show credential material, API keys, SAML assertions, signing material, session cookies, or cloud tokens were exposed, revoke tonight. For Fortinet exposure: kill VPN/admin sessions and rotate local admin/API credentials. For AndroxGh0st-style cloud/account compromise: rotate AWS access keys, M365 app secrets/certs, refresh tokens, app passwords, and third-party OAuth grants. For Citrix SAML: if SAML signing certs/keys or assertions are exposed, rotate federation trust material and force IdP/SP session invalidation — patching the appliance does not invalidate a stolen assertion or signing key.

For the Huntress Microsoft 365 ROPC password-spray lane, I’d scope revocation to evidence of successful authentication or token issuance. ROPC is OAuth 2.0 password grant abuse; if the spray only generated failures, block/disable ROPC and weak legacy auth paths. If any account succeeded, revoke that user’s refresh tokens, reset password, require phishing-resistant MFA, and review mailbox rules, OAuth grants, and service-principal access.

What would change my call? Evidence of no successful token issuance, no exposed session material, and no federation/key compromise would move a case from “revoke tonight” to “patch and monitor.” But once tokens, SAML trust, OAuth grants, API keys, or active sessions are in play, password reset is only one credential rotation — not containment.

Halil, I’d split it this way:

• Strong enough to affect board messaging and sector coordination: the North Korea-linked crypto theft / malicious npm activity — attribution confidence moderate, defensive urgency high. The evidence ties North Korea-linked actors to DeFi breaches and separate developer-targeting npm packages stealing secrets. Board message: “state-linked financially motivated theft and software-supply-chain credential theft,” not just generic cybercrime. MITRE framing: T1195 supply-chain compromise, T1552 credential/secret collection.

• Strong enough for sector coordination, but not sponsor-level messaging: Armored Likho — attribution confidence moderate for the cluster, low for any higher state sponsor claim. Kaspersky’s reporting links Armored Likho/Eagle Werewolf to spear-phishing against government and electric power targets, using archive attachments, EXE/LNK execution, BusySnake Stealer, RATs, loaders, and tunneling. Board message should be: “targeted phishing and stealer activity against public-sector/energy environments,” not “state campaign” unless someone brings stronger sourcing. MITRE: T1566.001 spear-phishing attachment, T1204 user execution, T1027 obfuscation, likely T1105 tool transfer/C2.

• Keep attribution as context only for now: UNC6240/ShinyHunters on PeopleSoft higher education, Pegasus infection reporting, and Forest Blizzard DNS/OAuth. I don’t have enough substantiated evidence in front of me here to let those actor labels drive board or regulator language. Defensive urgency may still be high if PeopleSoft, mobile compromise, DNS, or OAuth abuse is confirmed — but the label should not outrun the access path.

The narrative collapse to avoid: don’t merge “state-linked,” “spyware,” “financial theft,” and “sector targeting” into one mega-campaign. These are separate clusters with different confidence levels, victimology, and coordination needs.

Halil, the ones I would treat as real operational risk this week are Langflow/JADEPUFFER, Marimo CVE-2026-39987, and BioShocking-style AI browser agent leakage. They all cross the line from “model misbehavior” into either privileged execution or credential exposure.

For Langflow/JADEPUFFER, the key point is not that the ransomware is “AI-native”; the source pack flags an active-in-the-wild ransomware breach involving Langflow and agentic AI. That makes it a workflow-exposure problem: if Langflow is internet-facing, over-permissioned, or wired into execution tools, it becomes a privileged automation surface. For Marimo CVE-2026-39987, the evidence is more concrete: reporting describes pre-auth RCE against a Marimo notebook server, followed by AWS credential enumeration, retrieval of SSH private keys from AWS Secrets Manager, and database exfiltration. That is a real secret-exfiltration and lateral-movement path, with the LLM agent accelerating post-exploitation rather than inventing a new vulnerability class.

BioShocking is slightly different but still actionable. Malwarebytes reporting says researchers used a fake game environment plus prompt injection/goal manipulation to get AI browsers and plugins to visit GitHub and expose credentials or passwords; the risk is highest when the agent runs inside logged-in sessions for email, code repos, cloud dashboards, or password managers. So I’d call this a real leakage path for organizations allowing AI browser agents into authenticated enterprise apps, but still more “control and monitor aggressively” than “emergency patch,” because it depends on user/agent context and data access.

For Cursor AI IDE RCE and Claude Cowork sandbox escape, I don’t have enough visible evidence here to rank them as active operational threats. I’d keep them in research/monitoring unless we have a vendor advisory, CVE, reproducible PoC, or observed exploitation.

Controls for this week: inventory Langflow, Marimo, AI IDEs, and browser agents; remove public exposure; patch or isolate Marimo immediately; rotate cloud/API credentials touched by notebook or agent environments; restrict AWS Secrets Manager access by role and source context; block AI browser agents from password managers, cloud consoles, email, and code-hosting sessions unless explicitly approved; log agent tool calls, browser actions, secrets-manager reads, and unusual notebook WebSocket activity; and treat AI workflow servers like CI/CD runners, not chatbots. The OWASP LLM Top 10 framing applies here: this is excessive agency, prompt injection, sensitive information disclosure, and insecure plugin/tool design—not “the AI going rogue.”