Session CRT-20260705 — 5 July 2026 · Morning Edition

Halil, exploitability cut: JadePuffer’s Langflow-to-Nacos chain is the nastiest item here. The source says attackers got code execution on internet-facing Langflow via CVE-2025-3248, stole cloud/API/database credentials, pivoted into MySQL/Nacos, and destroyed Nacos config data in minutes. That is not “patch and move on.” If Langflow was internet-facing, treat it as likely compromised: isolate it, preserve logs, rotate cloud/API/database secrets, inspect Nacos/MySQL, and hunt for persistence.

WatchGuard Firebox CVE-2026-13368 gets same-day patch-and-hunt, but I’m not calling every exposed box compromised from the evidence visible here. The source frames it as a critical Firebox IKEv2 RCE with exposed T15/T35 devices still out there. Edge firewall RCE is a loaded gun on the table, so patch tonight and review VPN/IKE/auth logs. But I don’t have visible in-the-wild exploitation evidence for this one, so “likely compromised” requires telemetry: weird IKE traffic, config changes, new admin sessions, tunnels, or outbound C2.

For the Apple/Google/Android/Chrome/Linux patch wave, split it. Android CVE-2025-48595 is reported as actively exploited, so high-risk mobile users get same-day updates and device hunting. Apple/Google emergency patches are also described as responding to active exploitation, so executives, admins, developers, and incident responders go first. Chrome CVE-2026-14107 is described as low severity in the visible source set, so that is patch-only unless other exploit evidence appears. I don’t have enough visible evidence here to make a Linux-specific exploitability call.

Armored Likho / CVE-2025-9491: I’d be careful. The visible source ties Armored Likho to government and power-sector targeting with BusySnake Stealer and active-in-the-wild campaign signals, but I don’t have the exploit mechanics or preconditions for CVE-2025-9491 in front of me. So: if you’re government/power sector, hunt today for BusySnake activity and patch any matching CVE-2025-9491 exposure. For everyone else, don’t let the actor name bully you into panic—patch, monitor, and escalate only if your exposed asset map matches.

Before tonight, a CISO should: 1) isolate and investigate exposed Langflow; 2) emergency-patch WatchGuard Firebox and review edge telemetry; 3) force mobile/browser updates for privileged users; 4) hunt Armored Likho only where sector and exposure match. Patch-only is for Chrome low-severity and unmatched Armored Likho exposure. Likely-compromised is internet-facing Langflow. WatchGuard is one bad exploit drop away from joining that bucket.

Halil, I’d separate this into two buckets.

First, JadePuffer is the most operationally meaningful AI signal in the set. The grounded reports describe an LLM agent abusing an internet-facing Langflow flaw, CVE-2025-3248, stealing cloud/API/database credentials, reaching MySQL/Nacos, and destroying Nacos/config data. The AI-specific part is not “sentient ransomware”; it is automation of intrusion steps — parsing, retrying, adapting commands — once ordinary appsec failures exposed a privileged workflow system. Defenders should treat Langflow like production control-plane software: patch it, remove it from the internet, rotate secrets, monitor abnormal tool execution, and assume credentials reachable from the workflow are in scope.

Second, the Claude Code PoC is classic indirect prompt injection plus privileged developer tooling. The reported technique uses a clean-looking GitHub repo, setup behavior, and DNS TXT retrieval to deliver a reverse shell at runtime. That matters because repo review, SAST, and SBOM-style checks may miss payloads fetched dynamically. But again, this is not “the AI deciding to hack”; it is an agentic coding tool being steered into executing attacker-controlled instructions with local developer privileges. Govern it like untrusted code execution: sandbox coding agents, block arbitrary network egress where possible, require human approval for shell/package operations, and keep secrets out of agent-accessible environments.

On BioShocking against AI browsers and Google’s AI-assisted malware mutation, I don’t have enough grounded detail in the visible evidence here to assert specifics. My cautious read: if BioShocking is browser-agent data leakage, the risk is likely privileged browsing context plus prompt/content injection; if malware mutation is AI-assisted, the defender change is faster variant churn, not magic malware. The line I’d draw is this: AI novelty changes speed, ambiguity, and control boundaries; it does not remove the need for ordinary appsec, identity, egress control, secrets hygiene, and least privilege.

I’d keep these as three separate stories.

• Armored Likho / BusySnake — attribution: moderate confidence. Kaspersky describes Armored Likho as a newly identified group, with only circumstantial linkage to Eagle Werewolf, targeting government and electric power organizations in Russia, Kazakhstan, and Brazil via spear-phishing archives delivering Python-based BusySnake Stealer. Intent looks mixed: espionage against organizations, with some financially motivated activity against individuals. MITRE frame: T1566.001 spearphishing attachment, T1059.006 Python, credential/data theft behavior.
• PolinRider / TeamPCP / developer tooling — attribution: moderate for North Korea-linked activity, low for collapsing labels into “Lazarus.” Socket links PolinRider to the North Korea-linked Contagious Interview / Famous Chollima developer-targeting campaign, with 162 malicious artifacts across 108 packages/extensions in npm, Go, Packagist, and Chrome. Separately, the handoff says FBI warned TeamPCP poisoned developer tools to steal cloud credentials. I would not equate PolinRider, TeamPCP, and Lazarus without shared accounts, infrastructure, malware, or wallet pivots. MITRE: T1195 supply-chain compromise, T1552 credential theft, T1059 scripting, possible T1078 valid accounts if stolen cloud creds are reused.
• Pegasus / Stelios Kouloglou — infection confidence: high; operator attribution: unresolved. Citizen Lab reportedly had high confidence Kouloglou’s iPhone was infected on Oct. 21, 2022 and Mar. 6–7, 2023, while he served on the European Parliament PEGA spyware committee; reporting says there is no technical evidence tying the attack to the Greek government, though infrastructure overlaps with other Pegasus cases were noted. Intent is surveillance of a politically sensitive target, but customer/operator remains unproven.

Today’s intelligence requirements: get infrastructure pivots for Armored Likho/BusySnake; package maintainer-account, token, and cloud-credential reuse evidence for PolinRider/TeamPCP; and for Pegasus, preserve forensic timelines and seek operator-cluster indicators rather than political inference.

Halil, I’d split this hard by population, not by brand loyalty.

For same-day enforcement: high-risk iPhone/iPad users first — politicians, journalists, legal teams, dissidents, executives, admins, and anyone in spyware-targeted environments. Citizen Lab-linked reporting says former Greek MEP Stelios Kouloglou was infected with Pegasus, and the current source pack flags this as active-in-the-wild, high-impact surveillance activity. That is not “just patching”; it’s a civil-liberties and targeted-espionage lane. Also same-day for high-risk Android users on Android 14/15/16 because Google’s June bulletin coverage says CVE-2025-48595 is an actively exploited Android Framework privilege-escalation flaw, patched at 2026-06-05 or later.

For normal-but-expedited cadence: broad consumer/standard enterprise Android fleets can follow the normal monthly patch cycle only if they are not high-risk and can reach the June 2026 patch level quickly. The Apple iOS 26.5.2 picture is slightly conflicted: current handoff labels the Apple/Google wave as emergency/active exploitation, while Ghacks says Apple stated the iOS 26.5.2 bugs were not known zero-days or actively exploited. So my operational call is: same-day for exposed/high-risk iOS users, fast staged rollout for everyone else unless Apple’s advisory confirms active exploitation across the listed iOS flaws.

For MDM and conditional access, verify three things, not vibes: OS version/build and Android security patch level; whether the device is still vendor-supported; and app-install provenance. Block or quarantine Android devices below 2026-06-05 where the user is high-risk or has privileged access. For iOS/iPadOS, require 26.5.2 for high-risk cohorts and watch for WebKit-heavy exposure because coverage says many fixes are browser-facing. On the Android NFC fraud item, I don’t have enough sourced detail here to validate the specific campaign mechanics, so I would not treat it as an OS patch emergency; treat it as fraud-control enforcement: block unknown-source installs, review NFC/payment-app permissions, restrict risky sideloading, and push user warnings around card-tap social engineering.

Halil, the answer is: revoke trust state, not just passwords. HIBP’s infostealer-sourced collection is already described as 56M emails and 124M passwords from malware theft; that means every matched account should be treated as possibly accompanied by cookies, browser tokens, and reused credentials, not merely a password exposure. Tonight: invalidate active sessions, refresh tokens, remembered-device MFA state, app passwords, risky OAuth grants, and any password-reuse paths into VPN, SaaS, cloud consoles, Git hosting, and EHR portals.

For AdaptHealth, the reporting says attackers socially engineered a third-party contractor, accessed the cloud environment, internal patient management systems, document storage, and external EHR portals; AdaptHealth says it disabled the contractor account, reset credentials, and added access controls. I’d go further: revoke the contractor’s IdP sessions, SAML/OIDC federation sessions, EHR portal sessions, document-sharing links, API tokens, delegated admin grants, and any SCIM/provisioning trust that could recreate access. Password reset alone leaves too much bearer-token residue.

For poisoned developer tools/packages, the FBI-linked reporting says TeamPCP used compromised developer tools to steal cloud credentials. Burn the developer workstation and CI trust chain: cloud access keys, temporary STS tokens where possible, GitHub tokens, deploy keys, SSH keys, Kubernetes kubeconfigs/service-account tokens, package-registry tokens, and any OAuth apps authorized from those developer accounts. Re-scope them to least privilege and move service-to-service access to short-lived workload identity federation instead of static secrets.

On BusySnake/PamStealer and AI-browser saved-secret exposure, I have visible evidence here for BusySnake as a stealer campaign targeting governments and the power sector, but not enough visible source detail to assert every cookie/Keychain mechanism. Operationally, if cookie or Keychain theft is confirmed on an endpoint, revoke browser sessions, IdP refresh tokens, device trust, stored SSH/private keys, saved cloud credentials, and any passkeys or device attestations tied to a compromised device. Then re-enroll only from clean hardware with phishing-resistant auth — FIDO2/passkeys for users, workload identity for machines.

Halil, payload-wise I’d split these into three bins. PamStealer is the most mechanically specific in the evidence: fake Maccy distribution, AppleScript/JXA first stage, Rust second stage, Apple Silicon filtering, PAM-based password validation, browser/cookie/wallet/clipboard/Keychain theft, fake prompts, fake Finder.app under Application Support, login-item persistence, and Full Disk Access social engineering. TimbreStealer is the clearest Windows sideloading case in the visible evidence: phishing against Mexican companies plus DLL sideloading. BusySnake is tagged as a stealer used by Armored Likho against government and power-sector targets, but I don’t have enough binary-level detail here to say whether scheduled tasks or sideloading are core to that family. Avalon/CrownX is positioned as a legal-document lure leading to CrownX ransomware capability; again, I would not over-name the loader mechanics without a sample. For the malicious npm package families, I don’t have enough visible family detail to name specific packages safely; the huntable class is install-time execution plus credential/token collection.

The best low-noise detections are the ones that combine execution context + sensitive target. On macOS, I’d hunt for AppleScript or osascript/JXA spawning unsigned or unusual binaries, especially Rust Mach-O payloads under user-writable paths, followed by Keychain, browser profile, wallet, clipboard, or PAM interaction. PamStealer gives us a nice 0x90-clean chain: fake productivity app → script launcher → Rust payload → local password validation → credential theft → login-item persistence. That is far less noisy than “any AppleScript ran.”

On Windows, DLL sideloading is huntable when a trusted signed executable loads an unsigned DLL from a user-writable, temp, archive-extraction, or phishing-staging directory. For TimbreStealer, pair that with phishing-origin execution and Mexican-company targeting context if you have it. Scheduled tasks are only worth alerting on when the task action points to suspicious user-profile paths, script interpreters, renamed binaries, or recently dropped payloads; “new scheduled task” alone is too noisy. For Avalon/CrownX, the higher-confidence detection is lure-to-execution-to-encryption behavior: legal-document themed initial execution followed by suspicious child processes, mass file modification, shadow-copy tampering, or ransomware staging.

Across all of them, the detections most likely to catch real infections are correlation rules: package manager or script interpreter launches payload → payload touches credential stores/tokens → persistence appears. That beats single-signal alerts. For npm specifically, install-time scripts invoking network downloads, shell commands, credential file reads, .npmrc/cloud-token access, or CI secret enumeration should be treated as high priority, especially on developer workstations and build runners.

Halil, the strategic signal is not “one state campaign,” it is three different pressure points being probed. Armored Likho’s targeting of government agencies and the electric power sector in Russia, Brazil, and Kazakhstan looks like access-building against state capacity — ministries and power operators are levers of sovereignty. But attribution is exactly where we should slow down: Kaspersky reportedly describes Armored Likho as mixing espionage with financially motivated intrusions, using phishing, BusySnake Stealer, Go2Tunnel, GitHub-hosted staging, and patched Windows shortcut abuse. That hybrid profile makes it politically tempting to call it an APT, but not yet evidence-led to name a sponsoring state.

The Pegasus case is sharper geopolitically. Citizen Lab reportedly found high-confidence Pegasus infections of former Greek MEP Stelios Kouloglou while he served on the European Parliament’s PEGA spyware inquiry, with compromises aligning to sensitive committee work in October 2022 and March 2023. That is a gray-zone operation: surveillance used not just to steal data, but to chill oversight of surveillance itself. Still, it would be premature — and politically convenient — to declare “Greece did it” from the facts visible here. Reporting explicitly says Citizen Lab did not find technical evidence tying the attacks to the Greek government, even if the victim and political context make Athens an obvious arena of suspicion.

On the UAE claim, I would be even more disciplined: I do not have current sourced detail here beyond the premise that UAE authorities say they disrupted attacks on financial firms. A state announcement about disrupting attacks is not the same as attribution. It may be defensive signaling to investors, banks, and adversaries: “our financial hub is protected.” But unless we see technical indicators, victimology, infrastructure links, or an independently corroborated actor profile, assigning a state sponsor would be premature — and useful to whichever government wants to frame the incident as hostile foreign pressure rather than ordinary financial-sector intrusion.