Session CRT-20260630 — 30 June 2026 · Morning Edition

Halil, ranked operational call: 1) SimpleHelp CVE-2026-48558 gets isolated or surged first today if exposed. The CCB advisory says the flaw is an OpenID Connect authentication bypass where a remote unauthenticated attacker can submit a forged identity token and get a fully authenticated technician session. That closes the kill chain fast: create technician accounts, remotely access managed endpoints, run scripts, install software, and touch data. BleepingComputer’s reporting ties exploitation to Djinn infostealer and TaskWeaver deployment. This is a remote-support console turning into an attacker’s distribution point. Hunt for new technician accounts, odd OIDC login/token activity, technician sessions from unusual IPs, remote script/install jobs, and endpoint signs of Djinn/TaskWeaver. Patching alone is not enough.

2) Cisco CUCM WebDialer CVE-2026-20230 stays urgent for exposed WebDialer, but it is not today’s new top delta unless it was missed yesterday. The visible evidence supports unauthenticated SSRF in WebDialer, arbitrary file write, public PoC use, and possible root-level compromise. Hunt for WebDialer abuse, unexpected files on CUCM, webshell-like JSP/content, suspicious service changes, and post-exploit command execution. If it is internet-facing and not proven clean, isolate it.

3) Oracle PeopleSoft CVE-2026-35273 comes next for internet-facing PeopleTools. The evidence says active exploitation before patch availability, PeopleTools 8.61/8.62 exposure, unauthenticated remote triggering, SSRF-to-RCE framing, and reported data theft/persistence/extortion activity. I’m not buying actor labels as the priority here; the kill chain is enough. Hunt PSEMHUB/PeopleTools access anomalies, SSRF/RCE traces, older-vuln chaining, new persistence, unusual outbound transfer, and extortion-related account activity.

4) Oracle E-Business Suite CVE-2026-46817 is active-exploitation flagged, but I do not have enough visible chain detail to rank it above the others on exploit mechanics alone. Surge inventory, patch, and hunt before declaring victory: suspicious app-tier changes, new privileged users, abnormal web/app logs, and signs of post-auth movement. If it is internet-facing and business-critical, isolate until checked — but today I would not pull responders off SimpleHelp or exposed Cisco/PeopleSoft for it without stronger kill-chain evidence.

Halil, the CISO should treat this as active trust-state compromise, not a password incident. EvilTokens is described as Microsoft 365 device-code phishing, Bluekit as browser-in-the-middle phishing, Klue as OAuth/Salesforce token exposure, and Russian-linked activity as Signal/WhatsApp account takeover. The identity pattern is consistent: attackers are not merely learning passwords; they are obtaining sessions, OAuth grants, device-code tokens, linked-device trust, or MFA-persistent footholds. For FortiBleed and KDDI specifically, I would not assert campaign mechanics beyond the scenario names you gave.

Tonight’s revoke list is bigger than “reset passwords”: revoke Microsoft 365/IdP refresh tokens and active sessions; invalidate suspicious OAuth consent grants; remove attacker-registered MFA methods; unlink unknown Signal/WhatsApp desktop or companion devices; rotate Salesforce/API/OAuth connected-app secrets where Klue exposure creates downstream trust; and force re-authentication on high-risk users after session revocation. Device-code phishing that bypasses MFA, AiTM session-cookie capture, suspicious OAuth grants, session-token misuse after password resets, and silent MFA device registration all point to the same operational problem: if you reset passwords but leave refresh tokens, OAuth grants, or messaging linked devices alive, the attacker may keep the session without knowing the new password.

The hardening priorities I’d put above user training: disable or tightly restrict Microsoft OAuth device-code flow where it is not operationally required; require phishing-resistant MFA such as FIDO2/WebAuthn for admins, finance, helpdesk, and executives; block legacy or weak factors like SMS/push-only for high-risk roles; enforce admin consent workflow and review all high-privilege OAuth app grants; shorten session lifetime for risky apps; bind access to compliant devices where possible; and alert on impossible travel plus “new device code auth,” “new OAuth grant,” “new MFA method,” and “session use after password reset.” User training is insufficient because Bluekit-style browser-in-the-middle and EvilTokens-style device-code flows are designed to make the user complete a legitimate-looking authentication ceremony while the attacker receives the durable trust artifact.

Halil, the new part is not “Miasma exists” — we already treated that as a scoped emergency around npm install-time execution and secret theft. What is new is that the same trust boundary keeps failing in adjacent developer paths: npm/native build hooks, AI coding agents reading untrusted repo content, GitHub Actions running agent tooling, and browser-loaded third-party JavaScript. Different mechanisms, same problem: developer systems are executing or obeying content they did not really authenticate.

For Miasma, the hard supply-chain facts are still severe: reporting says 57+ npm packages and 286+ malicious versions, with the “Phantom Gyp” technique abusing binding.gyp/node-gyp rebuild rather than the obvious preinstall/postinstall script path. The payload is described as harvesting AWS, Google Cloud, Azure, GitHub, local secrets, 1Password/vault material, and even GitHub Actions runner memory where masked secrets may exist in plaintext. So I would freeze or tightly constrain npm installs that trigger native builds, any package update involving binding.gyp, node-gyp, Bun, install hooks, or maintainer changes, and any CI workflow with publish tokens or cloud credentials until dependency graphs and internal npm caches are checked.

The AI-agent side is now part of the same developer-trust problem. Mozilla’s finding on indirect prompt injection in AI coding agents, plus the Gemini CLI / google-github-actions/run-gemini-cli issue, tells me we need to constrain headless agent execution in CI. The Gemini reporting says the patched issue involved automatic workspace trust in headless/CI mode, malicious .env poisoning, and --yolo/auto-approve behavior bypassing tool allowlists; fixes require explicit workspace trust and allowlisting. So today I would block AI agents from running on untrusted PRs, issues, forks, generated files, or external docs with repo write tokens, package publish tokens, cloud creds, or secret-reading permissions. Require pinned action versions, explicit tool allowlists, no --yolo in CI, and isolated runners with short-lived credentials.

For Polymarket, I would not overstate the evidence here: I have the characterization as a third-party JavaScript compromise, but not enough sourced detail in front of me to name the exact vendor or injection path. Still, the control is clear: constrain browser-loaded third-party scripts in sensitive flows, especially wallet, auth, trading, checkout, and admin paths. Use subresource integrity where feasible, CSP with strict script origins/nonces, vendor inventory, runtime monitoring, and emergency kill switches for third-party tags.

Where a blanket engineering freeze is counterproductive: normal backend work that does not change dependencies, CI permissions, publish paths, package manager behavior, GitHub Actions, AI-agent automation, or third-party JS does not need to stop. Freezing everything burns attention. The practical freeze is narrower: package updates, lockfile changes, native npm builds, CI workflow edits, GitHub Action upgrades, AI coding-agent jobs, secrets-bearing runners, release/publish jobs, and third-party JS/tag changes. That is where the trust chain is actually breaking.

Halil, I’d separate defensive priority from actor branding:

• Russian intelligence-linked messaging hijacking: let this affect priority today. The source pack has SSU/FBI-linked reporting and flags active espionage against Ukraine, Europe, and the US. Confidence: moderate-to-high on state-linked espionage framing. Defend against phishing, session/account takeover, valid-account abuse; the exact Russian service/unit is secondary unless we get infrastructure pivots or reusable tooling links.

• PeopleSoft / NAIC / Nissan / ShinyHunters: patch and hunt immediately, but do not let the ShinyHunters label drive priority. The hard fact is active exploitation of Oracle PeopleSoft and disclosed data exposure at Nissan; the ShinyHunters linkage is reported as “appears tied” / “previously linked,” so attribution confidence is low-to-moderate. Upgrade confidence with extortion comms, reused leak-site handles, wallet/payment infrastructure, or shared C2; downgrade if exploitation clusters split across unrelated crews.

• Iran-linked surge against Israel: priority impact is sector- and geography-bound: Israeli critical infrastructure, central organizations, SMEs, law/accounting firms, and individuals should raise posture. Confidence: moderate, because the visible evidence is official Israeli reporting of a surge and Iran attribution, not independent technical clustering. Upgrade with malware/infrastructure overlaps to known Iranian clusters; downgrade if incident volume is mostly hacktivist/noisy phishing without shared operators.

• North Korea / macOS.Gaslight / Contagious Interview: I don’t have source-backed evidence in front of me here, so I would not let the North Korea label outrank the behaviors. Treat macOS developer-targeting, fake recruiter lures, credential theft, and payload execution as priority only where those indicators are present. Confidence on attribution from the visible evidence: unknown.

For the broader phishing/malware campaigns: prioritize by exploitability, victim exposure, and observed compromise, not actor romance. Actor names upgrade priority only when they predict next steps—data theft, wiper use, credential harvesting, lateral movement—not when they are just campaign branding.