Session CRT-20261029 — 29 October 2026 · Morning Edition

Halil, the 30-minute decision is: patch or isolate these three now, and hunt exposed instances in parallel. Patching closes the door; it does not tell you whether someone already walked through it.

1. F5 BIG-IP APM CVE-2026-94127. The pack identifies active exploitation and RCE, so this is the cleanest kill-chain closure. Prerequisite: an affected APM deployment must be reachable through the vulnerable path; the material does not clearly identify whether that means the public service, management interface, or a particular configuration. Evidence quality: labeled strong, but it rests on a single generic Sploitus source—too thin for confident exploit-mechanics claims. Patch/isolate affected systems immediately; hunt only those reachable while vulnerable, preserving logs and checking for execution or persistence rather than treating scanning as compromise.

2. BeyondTrust Remote Support CVE-2026-102764. Prerequisite: a reachable Remote Support appliance whose internal component accepts messages without adequately validating their origin. Reported effects include unauthorized file operations, manipulation, and control bypass. Evidence quality: adequate: HKCERT reports in-the-wild exploitation and an NVD entry is present, but HKCERT provides no affected versions, IoCs, or precise exploitation conditions. Patch or restrict access now. For exposed appliances, hunt for unexplained file operations and configuration changes; the evidence does not justify declaring every vulnerable appliance compromised.

3. Oracle E-Business Suite CVE-2026-101767 / PeopleSoft chain. Prerequisite: an affected Oracle application path must be reachable; the current pack does not cleanly separate the EBS flaw’s prerequisites from the PeopleSoft chain. Evidence quality: adequate but weaker than the urgency language suggests—the handoff itself describes the sources as multiple but weak or same-family reporting. Patch affected internet-facing systems and start a scoped hunt, but do not merge separate Oracle products and CVEs into one universal exploit chain.

I would not elevate PHP2Shell, Brotli, Magento, or Apple CoreGraphics into today’s top three from the evidence available here: there is insufficient current detail on exposure prerequisites, reproducible PoC quality, and verified exploitation for this ranking. The pack most clearly overstates certainty around F5’s “strong” evidence despite single-source lineage, and around Oracle by blending EBS and PeopleSoft reporting. High severity is not a fire alarm by itself; reachable exploit paths plus execution evidence are.

The “600 critical-infrastructure organizations” framing is too broad. FACT: CISA reports at least 600 victims since August 2024 across multiple critical-infrastructure sectors; that does not establish that every victim was critical infrastructure. A third-party snapshot counted 594 leak-site claims, but claims are not independently confirmed incidents. I found no substantiated aggregate count of individual records exposed. Campaign attribution to SafePay is high confidence; operator identity or state nexus remains unknown.

The repeatable pattern is valid-account abuse—stolen or brute-forced credentials—against exposed VPN or remote-access services, sometimes alongside exploitation of known public-facing flaws: T1078, T1110, T1133 and T1190. Exposure or failed authentication alone is not compromise. Elevate to compromised only with successful anomalous authentication plus internal activity, SafePay malware execution, campaign-linked C2/exfiltration traffic, encryption artifacts, or victim-specific stolen data independently validated.

My firm position: SafePay is supporting evidence for a broader perimeter and identity-control failure, not today’s strategic lead. Its scale makes it operationally urgent, but the access pattern is repeatable precisely because organizations continue exposing remote access without resilient credentials, MFA and patch discipline.

Halil, the genuinely new element is testmetest’s delivery path. The reporting identifies 42 hijacked GitHub repositories, with the scenario extending from repository compromise into developer workstations through IDE startup behavior. That creates a source-to-endpoint problem, unlike the two bounded malicious LiteLLM PyPI releases, and unlike TanStack, where reporting points to abuse of npm trusted publishing. The trust failures are therefore different: repository/distribution channel plus IDE execution for testmetest; malicious PyPI artifacts for LiteLLM; and the authorized publishing workflow for TanStack.

The containment boundary should be:

• Treat as suspect: developer endpoints that cloned or opened an affected testmetest repository during the compromise window and triggered its IDE or project automation; CI workers that checked out and executed affected commits; environments that installed or executed either malicious LiteLLM release; and TanStack publishing identities, workflows, and consumers tied to the malicious npm versions.
• Treat credentials as exposed: tokens, PATs, cloud credentials, registry credentials, signing material, and CI secrets accessible to those processes during the relevant execution window. Downstream packages, containers, binaries, and releases built or signed in those environments remain suspect until their provenance is reconstructed.
• Do not automatically classify as compromised: someone who only viewed a repository; endpoints with no affected checkout or execution; unaffected LiteLLM or TanStack versions; unrelated repositories in the same organization; or releases provably built before compromise or rebuilt in an isolated environment from a verified clean commit.
• Unknown: the evidence available here does not provide the complete 42-repository list, exact malicious version numbers and hashes, precise compromise windows, or endpoint execution telemetry. Repository count is not victim count.

The highest-value evidence is not the news coverage but GitHub audit and Actions logs, commit and workflow history, IDE/process telemetry, PyPI/npm immutable publication metadata and digests, OIDC or trusted-publisher records, token-use logs, lockfiles/SBOMs, container-layer inventories, and build attestations. Use those in one containment sequence: (1) freeze affected repositories and publication workflows while preserving logs; (2) block the identified package versions and commit hashes across registries, proxies, caches, and CI; (3) isolate endpoints and runners with execution evidence; (4) revoke and rotate credentials reachable from those environments, including release and signing identities; (5) trace affected hashes through lockfiles, SBOMs, containers, and downstream releases; (6) rebuild from the last verified clean commit in sterile CI with dependencies pinned by digest and fresh provenance; (7) resume publication only after validating the publishing identity and reviewing all post-compromise releases. Do not broaden this into an organization-wide compromise unless shared credentials or common runner infrastructure provide that bridge.

Halil, the $2.35 billion across 230 protocols is an accounting aggregate, not evidence of one systemic exploit. Fact: the cited 2026 tally reports $2.35 billion in net losses. Assessment: it demonstrates the scale of realized harm under that report’s methodology, but not 230 independent control failures, a common root cause, current exposure, or even gross value stolen before recoveries. The systemic lesson is narrower: signing authority, privileged settlement paths, dependency integrity, and custody isolation repeatedly fail. Those are control themes—not proof that every named protocol requires emergency action tonight.

Bloom is actionable. Reporting says 9,408 SOL—about $953,000—left 48 Solana wallets belonging to nine traders in 94 seconds. Bitquery reportedly observed transfers signed by the affected wallets’ own keys, without malicious approvals, additional signers, or contract interactions. Bloom attributed the event to remote code execution in a third-party module and denied private-key exposure. Those positions are not mutually exclusive: valid signatures prove that signing authority was exercised, not necessarily that raw private-key material was exported. An attacker could have invoked an already-loaded signer, retained signing service, or compromised process. My firm position is therefore signing-plane compromise until disproved, especially because some wallets reportedly had not used Bloom since early 2025. Bloom’s narrow “no key exposure” statement does not establish wallet safety.

For TranchePool’s claimed $1.013 million settlement exploit, I cannot validate the amount, exploit path, affected contracts, or fund destinations from the available evidence; the firm operational position is to freeze the affected settlement path and reconcile contract state before restart, not extrapolate it into the 230-protocol total. Likewise, “malicious wallet extensions” is not actionable without extension IDs, hashes, signing certificates, and store listings. For Fireblocks mpc-lib VU#701544, the available evidence does not establish affected versions, exploitation, or key extraction; custodians should treat it as an exposure-management question pending exact inventory and vendor remediation—not announce compromise merely from the advisory identifier.

Tonight, I would do only three things:

1. Exchanges: flag and temporarily hold deposits traceably linked to the Bloom outflow while preserving evidence and contacting affected parties.
2. Protocols: pause TranchePool’s affected settlement function and reconcile every settlement against balances, contract state, and outbound transfers before reopening.
3. Custodians: inventory mpc-lib versions and wallet-extension exposure immediately; isolate affected signing infrastructure and rotate or migrate Bloom-connected signing authority rather than relying on the “no key exposure” wording.