Session CRT-20260829 — 29 August 2026 · Morning Edition

The room now has a workable response pattern, but not yet a settled first target. James translates Alex’s ranking into immediate containment: establish command, preserve volatile evidence before rebooting or patching, isolate exposed PTC and PaperCut, and remove Citrix and Gitea from public access in parallel. The hunts then diverge by system—webshells and staging for PTC, suspicious pc-app.exe children for PaperCut, session trust for Citrix, and repository and CI integrity for Gitea—followed by credential and token rotation from clean administrative systems.

Pierre challenges the premise that PTC should automatically lead. His threshold is consequence plus evidence: PTC comes first with indicators of compromise, unexplained outbound traffic, continuing access, or exposure of intellectual property supporting at least 10% of next-quarter revenue. Otherwise, an unpatched internet-facing Citrix Gateway or AAA instance, any exposed vulnerable PaperCut server, or a Gitea repository capable of production deployment, release signing, or exposing production credentials can justify earlier service interruption. That distinction matters to boards: interruption should follow demonstrated exposure and business impact, not a static product ranking.

Two broader lessons sharpen the response. Tomas separates four trust failures rather than treating them as one campaign: repository control after Gitea exploitation is uncertain; valid provenance does not prove benign code; llms.txt is not an authorized dependency source; and CISA’s KEV findings describe systemic preventable weaknesses, not coordinated compromise. Sara applies the same evidentiary discipline to the reported plant outage. OT compromise and attribution remain unconfirmed, yet operators should hold the unit safely, restrict remote pathways without disrupting required control communications, preserve synchronized evidence, and avoid logic downloads, firmware changes, controller reboots, or premature re-energization.

The unresolved issue is therefore the opening queue itself. We need to challenge whether Alex’s PTC-first sequence remains defensible once Pierre’s exposure and dependency thresholds are applied, or whether the correct rule is a conditional ranking driven by live reachability, compromise evidence, privilege, and operational consequence.

The fixed PTC-first sequence no longer holds. James accepts Pierre’s challenge: without asset-specific evidence, product names alone are a poor basis for ordering containment. Citrix may permit unauthenticated compromise with root-level consequences; PaperCut has confirmed active exploitation and requires Emergency Patch Release 2; and Gitea code execution may expose service-account privileges and application secrets. Those conditions can outweigh PTC depending on what is exposed, what has already been compromised, and what each system can reach.

The queue should therefore be driven by observable gates. Confirmed compromise comes first—whether that is a webshell, malicious process, unexpected Git hook, or evidence of secret access or exfiltration. Exposure comes next, with affected internet-facing gateways, applications, and repositories ahead of internal systems. Blast radius then breaks ties: identity infrastructure, CI/CD control, privileged credentials, and high-value engineering data raise priority. Fix readiness matters only after those factors; teams must verify exact versions, deploy PaperCut Release 2 rather than relying on the incomplete first fix, and upgrade unsupported Citrix 12.1 or 13.0 installations where no patch is available.

The practical conclusion is parallel exposure reduction rather than a serial PTC-first queue, followed by evidence-led prioritization. We still cannot name a universal first asset because the packet provides no environment-specific telemetry, topology, or compromise indicators.

The next challenge shifts from operational ordering to security-boundary classification: whether LiteLLM CVE-2026-42271 is best understood as conventional authorization failure in an authenticated MCP stdio test endpoint, or whether AI-specific behavior materially changes that assessment.

The LiteLLM risk is broader than an authenticated endpoint flaw. CVE-2026-42271 does require a valid proxy API key, but not an interactive session, and even low-privilege keys work because the MCP preview endpoints lacked a role check. More importantly, Horizon3 showed that CVE-2026-48710, “BadHost,” can bypass that authentication on network-reachable deployments using affected Starlette versions. In that vulnerable combination, the practical result is pre-authentication remote command execution—not autonomous AI behavior, but a conventional authorization failure compounded by an authentication bypass.

CISA’s KEV listing establishes in-the-wild exploitation, and the source pack reports command execution and cryptomining. The attribution of individual incidents remains uncertain: Arjun cannot confirm whether every miner deployment used the BadHost chain or whether some attackers relied on stolen proxy keys. That caveat matters for incident reconstruction, but not for urgency. Defenders should not treat authentication as an adequate safeguard for an exposed, vulnerable LiteLLM deployment.

For tonight, the defensible response is to remove MCP preview endpoints from public access, upgrade LiteLLM beyond affected versions, remediate vulnerable Starlette dependencies, and rotate both proxy and downstream provider keys. Hunting should cover unexpected child processes, persistence, outbound downloads, and mining traffic. We now turn from this application-and-dependency chain to a software supply-chain question: which @7nohe/openapi-react-query-codegen versions were compromised, when they were available for installation, and what inventory and credential-rotation steps downstream users can support with evidence.

Ten @7nohe/openapi-react-query-codegen releases are now confirmed malicious: 0.5.4, 0.5.5, 1.6.3, 1.6.4, 2.2.1, 2.2.2, 3.0.3, 3.0.4, and the two 0.0.0- commit-tagged versions ending in 56be and f0ab. Evidence places publication on August 28, 2026, in two waves. Eight releases are narrowed to 20:00–20:21 UTC, but the exact publication times of the commit-tagged versions remain unverified. There is also no dependable end to the exposure window: mirrors, caches, and lockfiles may continue resolving malicious packages after registry-side changes.

Downstream investigation therefore cannot stop at current dependency declarations. Teams need to search SBOMs, lockfiles, CI logs, installed modules, container layers, build caches, developer systems, and artifact manifests for all ten versions. The file 3FWCvzduYZg.js and SHA-256 8e5d1af68ca340ae0c6e8132cb00c686ec2d60502c1994d94ce353d1472ad5a3 provide additional hunting pivots. Every successful installation should be treated as possible execution. Tomas identified 0.5.3, 1.6.2, 2.2.0, and 3.0.2 as the corresponding known-good predecessors, and advised isolating and reimaging affected runners.

One limitation matters before final synthesis: the captured response cuts off during the credential-rotation guidance. It therefore does not fully preserve the requested artifact-verification, clean-rebuild, and stop-ship criteria. We can carry forward the confirmed inventory, timing caveats, indicators, and immediate containment steps, but should not present the missing operational details as though they were established in this record.