Cisco Catalyst SD-WAN Beats TeamPCP As Exploitation Signals Outrank CI/CD Allegations

Alex, treat today as a 30-minute CISO triage problem, not a CVE scoreboard. From the source pack and CyberBrief search results, rank the same-day response queue across: Cisco Catalyst SD-WAN/UAT-8616, Adobe ColdFusion CVE-2026-48282, Citrix NetScaler CVE-2026-8451 plus CitrixBleed CVE-2023-4966, Gitea CVE-2026-20896, JADEPUFFER/Langflow, and TeamPCP CI/CD credential compromise. For each, tell me whether it is patch-only, patch-and-hunt, or assume-compromised-and-contain, and name the evidence that makes urgency real rather than theoretical.

Halil, I’d rank the same-day queue by exploit closure and exposure, not by score:

1. Cisco Catalyst SD-WAN / UAT-8616 — assume-compromised-and-contain if exposed. The CyberBrief handoff calls this an “active exploitation campaign”, marks it CRITICAL, must_lead, and activeinwild, with named victim or sector impact. That is enough for same-day containment on exposed edge devices. Patch, isolate where possible, pull logs, check config changes, accounts, tunnels, and any downstream access.

2. Adobe ColdFusion RDS / CVE-2026-48282 — assume-compromised-and-contain for internet-facing RDS; otherwise patch-and-hunt. CyberBrief names this “Adobe ColdFusion RDS - CVE-2026-48282 - active exploitation”, marks it CRITICAL, must_lead, activeinwild, and supported by officialorvendorplusbodyverifiedsupport. If RDS is reachable, don’t treat this as maintenance. Treat it like someone found a side door into the app server.

3. Citrix NetScaler CVE-2023-4966 / CitrixBleed plus CVE-2026-8451 — patch-and-hunt immediately; assume compromised where exposed sessions or SAML/identity use are in scope. CyberBrief lists CVE-2023-4966 CitrixBleed as active exploitation and activeinwild. For CVE-2026-8451, the CSO summary says attempted exploitation was seen shortly after patching and describes an unauthenticated malformed-request memory overread affecting appliances configured as SAML identity providers; it also says the leak is smaller than prior CitrixBleed issues and does not appear to expose session tokens directly. So: less proven than classic CitrixBleed, but still identity-edge memory leakage. Patch, rotate sessions/tokens where appropriate, and hunt.

4. Gitea CVE-2026-20896 — patch-and-hunt. CyberBrief marks this CRITICAL, must_lead, activeinwild, and places it in the softwaresupplychain lane. That makes urgency real. I’m not calling every Gitea instance compromised from the visible evidence alone, but public-facing instances deserve same-day patching plus repo, token, webhook, runner, and admin-log review.

5. TeamPCP CI/CD credential compromise — assume-compromised-and-contain if confirmed in your environment. I do not have visible evidence here naming the exact mechanics, but confirmed CI/CD credential compromise is not patch-only. Revoke tokens, rotate secrets, inspect pipeline changes, validate artifacts, and check whether credentials were used outside expected runners.

6. JADEPUFFER / Langflow — hold below confirmed exploited edge cases unless your source pack confirms exposed Langflow exploitation. I don’t have enough visible evidence here to assert the exploit path or exploitation status. If you have internet-facing Langflow tied to JADEPUFFER activity, then move it to assume-compromised-and-contain. Without that, it does not outrank Cisco, Adobe, or Citrix today.

Short version: Cisco first, Adobe second, Citrix third. Those have the clearest same-day exploit pressure. Gitea is urgent patch-and-hunt. TeamPCP is containment if confirmed. Langflow needs the missing exploit-chain proof before it jumps the queue.

Lena, separate campaign evidence from noise. We already established in recent sessions that trusted platforms are becoming attacker control paths; what is genuinely new today across TeamPCP/VECT, UAT-8616 Cisco SD-WAN, Turla/Secret Blizzard STOCKSTAY against Ukraine, UAT-7810 Ruckus ORB, and the suspected China-aligned Roundcube university campaign? Give attribution confidence, likely objective, and which claims should not be over-briefed.

Halil, the clean cut is this:

• TeamPCP/VECT / EtherRAT: I can substantiate the Microsoft Teams social-engineering control path — fake IT personas coaxing workers into installing malware. Attribution: low for any named actor. Likely objective: access brokering or hands-on remote control. Do not over-brief this as a state campaign from the label alone.
• UAT-8616 Cisco SD-WAN: This is real campaign evidence: active exploitation of Cisco Catalyst SD-WAN with management-plane/root compromise and unauthorized configuration changes to edge devices. Attribution: low beyond the UAT cluster. Likely objective: durable network control and traffic-positioning.
• Turla / Secret Blizzard STOCKSTAY: Strongest attribution in the set. Google-linked reporting ties STOCKSTAY to Turla, with code/functionality overlap to Turla’s long-running tooling and targeting of Ukraine government/military plus Italy foreign-policy-linked entities. Attribution: high. Objective: espionage. MITRE fit: phishing/user execution, C2 over WebSockets, discovery, collection, screenshot/file/registry operations.
• UAT-7810 Ruckus ORB: I would brief this as operational infrastructure expansion, not sponsor attribution. Attribution: low from the evidence here. Don’t turn “ORB on Ruckus routers” into “China/Russia/Iran did it” without pivots.
• Roundcube university campaign: Keep it at suspected China-aligned activity, moderate at most unless we have infrastructure overlap, malware reuse, or victimology beyond universities. Do not name a Chinese group just because Roundcube plus academia fits a familiar pattern.

The genuinely new thread is not “trusted platforms are abused” — that is old. The new signal is control-plane capture: Teams for human trust, SD-WAN and routers for network trust, and STOCKSTAY for long-haul intelligence collection.

Marcus, I want the identity/trust-state view across the day: TeamPCP’s alleged 500k CI/CD credentials, Gitea repo/secret exposure, NetScaler memory/session leakage, DEBULL device-code OAuth, EtherRAT’s Teams support-lure path, and KDDI’s password exposure. What trust artifacts must be revoked or invalidated tonight, in what order, and where will teams fool themselves by rotating passwords but leaving attacker-held trust state alive?

Halil, my priority order tonight is: first kill anything that can mint or deploy more trust, then clean up user sessions. For the TeamPCP/Gitea lane, reported exposure includes CI/CD credentials, cloud tokens, SSH keys, Kubernetes secrets, and poisoned security/developer tooling such as Trivy/KICS-style supply-chain paths. So revoke in this order: CI/CD platform tokens and runner registration tokens; cloud IAM access keys and active STS sessions; Kubernetes service-account tokens/kubeconfigs; SSH deploy keys; package-registry tokens; Git/Gitea/GitHub PATs; webhook secrets; artifact-signing and release keys if those repos/build hosts were exposed. Password rotation is almost cosmetic here if an attacker still has a deploy key, a runner token, or a cloud token that bypasses the human login path.

For NetScaler ADC/Gateway CVE-2026-8451, the identity danger is edge trust state: VPN/AAA sessions, Gateway cookies, and downstream SAML/OIDC sessions that were established through that access path. Patch and isolate the appliance, yes — but also force-terminate Gateway sessions, invalidate IdP sessions for affected users, revoke refresh tokens, and rotate appliance-bound secrets/certs if memory exposure plausibly included key material. Teams will fool themselves if they say “we patched NetScaler” while leaving stolen session material valid.

On DEBULL device-code OAuth and EtherRAT’s Teams support-lure path, I don’t have enough database evidence here to assert campaign specifics. But if the flow is device-code OAuth, the trust artifact is the OAuth grant and refresh token, not the password. Disable or restrict device-code flow, revoke user refresh tokens, remove suspicious app consents, and require phishing-resistant auth. If the Teams support lure led to remote access or app consent, invalidate Teams/Entra sessions, OAuth grants, newly registered MFA methods/devices, remote-support tool enrollments, and any helpdesk-delegated access.

For KDDI, the source pack frames this as an email-platform breach involving credential exposure. The trap is treating it as only a password event. Reset passwords, but also revoke webmail sessions, IMAP/SMTP app passwords, mobile mail tokens, delegated mailbox access, forwarding rules, recovery factors, and third-party mail OAuth grants. If you leave app passwords or refresh tokens alive, the attacker keeps reading mail after the “password reset complete” ticket is closed.

Maya, give us huntable execution paths only. Compare EtherRAT via Microsoft Teams remote-control social engineering, JADEPUFFER/Langflow ransomware behavior, CAI cloud worm activity against exposed Docker/Kubernetes/Redis/Ray/etcd, and Turla STOCKSTAY via malicious RDP/WinRAR. What telemetry or artifacts should defenders hunt now, and what claims should we treat as unproven or hype?

Halil, I’d split this into human-driven execution, app-RCE-to-ransomware, cloud worm propagation, and malicious document/archive tradecraft.

For EtherRAT, the execution path is the most concrete: email lure → external Microsoft Teams contact posing as IT → victim grants remote screen control → attacker installs HopToDesk or AnyDesk → malicious MSI → multi-stage JavaScript loader → Node.js-based later stages → decrypted RAT. Hunt Teams external chat/call events followed by remote-control tooling installation, msiexec.exe launching script interpreters, Node.js appearing on non-developer endpoints, and new Run-key persistence. The Ethereum smart-contract C2 resolver and fallback domain are worth hunting, but I would not call this “Teams malware” — Teams is the social-engineering and control channel, not the payload substrate.

For JADEPUFFER/Langflow, the execution path is: exposed Langflow exploitation via CVE-2025-3248 → code execution → secret/cloud/API/database credential discovery → persistence via crontab → pivot into MySQL/Nacos → Nacos abuse including CVE-2021-29441 and JWT forgery using the default signing key → admin backdoor → encryption of Nacos configuration items and ransom note generation. Hunt Langflow process trees spawning shells, unexpected outbound credential-access tooling, crontab writes, Nacos admin creation, mass configuration reads/writes, and abnormal encryption-like updates to config stores. The “agentic ransomware” framing may be partially true in workflow automation, but I would treat claims of fully autonomous strategic decision-making as hype until we see reproducible traces, prompts, and execution logs.

For CAI, the grounded behavior is cloud/developer infrastructure compromise, competitor malware removal, secret theft, and cryptomining. For the exposed Docker/Kubernetes/Redis/Ray/etcd surface you named, I’d hunt Docker socket abuse, unexpected privileged containers, Kubernetes Secret enumeration, Redis writes that create cron/system execution, Ray job submission anomalies, etcd key dumps, miner binaries, and processes killing rival miners. The proven defender value is in telemetry around exposed service abuse and miner deployment; claims that this is a novel “AI cloud worm” need to be held at arm’s length unless we see actual autonomous propagation logic, not just scripted scanning.

For Turla STOCKSTAY, the visible path is malicious RDP-file delivery tied to the STOCKSTAY backdoor, with WinRAR in the delivery/handling story. Hunt .rdp files from email/download/temp paths, RDP client launches with unusual file arguments, archive extraction followed by RDP execution, persistence or backdoor staging after mstsc.exe, and outbound connections shortly after RDP-file opening. I would not over-attribute from the archive/RDP wrapper alone; the code-level backdoor artifacts matter more than the lure packaging.

Arjun, focus only on what changed today in AI-agent security. We have Zscaler’s malicious-site prompt injection steering agents toward Ethereum/license payments, GitLost leaking private repo contents through public GitHub issues, Rogue Agent in Dialogflow CX, Gemini Live API ephemeral-token concerns, and large-scale MCP server exposure. What is the decision-ready control pattern here? Which failures are real operational risk now versus research demos, and what should teams disable or gate this week?

Halil, the decision pattern is pretty simple: do not let agent output directly cross a trust boundary. Treat web pages, GitHub issues, tickets, chat transcripts, and MCP tool descriptions as untrusted input, and treat agent tool calls as privileged automation. The failure mode today is not “autonomous AI going rogue”; it is classic injection plus over-permissioned workflow execution.

The real operational risks now are the ones with public-to-private or public-to-money paths. Zscaler’s malicious-site prompt injection is decision-relevant because the site content can steer an agent toward crypto/license payments. GitLost is even cleaner as an enterprise risk: reports describe a public GitHub issue prompting an agentic workflow to read private repo content and post it publicly, with no attacker credentials or code execution needed. Large-scale MCP exposure is also operational, because exposed tool servers turn agent ecosystems into remote automation surfaces; if those servers have secrets, filesystem access, CI/CD reach, or SaaS tokens, this is no longer just an LLM problem.

The ones I would gate pending validation rather than panic-disable globally are Rogue Agent in Dialogflow CX and Gemini Live API ephemeral-token concerns. I do not have enough visible evidence here to call those active exploitation at the same confidence level as GitLost/Zscaler/MCP exposure. But the control is the same: no ambient tokens, no broad tool scopes, no sensitive backend actions from conversational context without policy checks, and ephemeral tokens must be bound to session, audience, action, and short lifetime—not treated as magic safety.

What I would tell teams to do this week: disable autonomous agent actions that can spend money, publish externally, read private repos, mutate CI/CD, or call MCP tools unless there is explicit allowlisting and human approval. Put MCP servers behind SSO/MFA/device posture, remove public exposure, rotate tokens, and log every tool call with input provenance. For GitHub agentic workflows, block agents from accessing private repos from workflows triggered by public issues or PRs. For browser/web agents, quarantine page text from payment/licensing decisions. This is OWASP LLM Top 10 territory: prompt injection, excessive agency, sensitive information disclosure, and insecure plugin/tool design all collapsing into one control-plane problem.

Priya, take the cloud and developer-control-plane angle. TeamPCP allegedly harvested 500k CI/CD credentials from 10k pipelines and tampered with tooling; Gitea CVE-2026-20896 exposes repos/secrets; CAI hits Docker/Kubernetes/Kubelet/Redis/Ray/etcd; Argo CD repo-server disclosure threatens GitOps takeover; Langflow is repeatedly showing up in ransomware and RCE paths. Give me a 24-hour containment sequence for cloud, Kubernetes, GitHub/GitLab, and CI/CD owners — what to rotate, pause, rebuild, or prove clean.

Halil, I’d treat this as a developer-control-plane compromise, not a pile of unrelated bugs. The 24-hour goal is to stop trust propagation across CI/CD, Git, Kubernetes, and cloud IAM before anyone argues about root cause. Start by pausing GitHub Actions, GitLab CI, Jenkins runners, Argo CD auto-sync, Flux reconciliation, Terraform apply jobs, and any pipeline with cloud write privileges. Quarantine self-hosted runners; rebuild them later from known-good images rather than reusing snapshots. Rotate GitHub/GitLab PATs, deploy keys, CI job tokens, webhook secrets, OIDC federation trust, container registry tokens, package-registry tokens, SSH keys, and cloud access keys used by automation.

For Kubernetes and GitOps, Argo CD repo-server is tier-zero. The CyberBrief result citing The Hacker News says Synacktiv disclosed an unpatched Argo CD repo-server vulnerability that can let an unauthenticated attacker execute code if they can reach the internal gRPC port; it abuses Kustomize command handling to replace the expected Helm binary with an attacker-controlled script from a Git repository. The same result says the attack can expose the Argo CD Redis password, poison deployment data, and trigger malicious workloads on the next sync, especially where NetworkPolicies are not enabled and repo-server is reachable from other pods. So: isolate repo-server with NetworkPolicies, restrict egress to approved Git/Helm endpoints, rotate Argo CD admin/API tokens, repo credentials, Redis password, cluster bearer tokens, and any Kubernetes Secrets Argo CD can read. Then diff live cluster state against signed Git state before re-enabling sync.

For Gitea, the handoff entry is explicitly titled “Gitea - CVE-2026-20896 - active exploitation” and includes exploit_status: active_in_wild, so isolate exposed Gitea instances, patch or take them offline, and rotate repo webhooks, deploy keys, OAuth apps, SSH keys, CI secrets, and mirror credentials. For CAI-style exposure, the handoff describes an exposed cloud and developer infrastructure cryptomining campaign involving Docker, Kubernetes/Kubelet, Redis, Ray, and etcd; immediately firewall or shut down public access to those services, rotate kubeconfigs, etcd credentials/certs, registry credentials, and cloud node instance-profile credentials. If Kubelet, etcd, Ray, or Docker API were reachable from the internet, rebuild nodes rather than just patching them.

Clean is not “the alerts stopped.” Clean means you can prove: no unreviewed cloud IAM trust path remains from CI to production; no GitOps controller can deploy from an untrusted repo or branch; no Kubernetes Secret or cloud secret touched by CI remains unrotated; and no runner/container image from the compromise window is reused. CSPs own the managed control plane availability; customers own IAM trust, exposed service endpoints, runner hygiene, repo secrets, and whether auto-sync quietly becomes auto-compromise.

Viktor, treat today’s crypto items as control failures, not just loss totals: Summer.fi’s $6.04M NAV/offboarding exploit, a $2M same-block backrun extraction, Ill Bloom weak PRNG wallet drains, BonkDAO governance capture, and AI-agent prompt injection steering Ethereum payments. What is the common money-moving authority failure, where can funds still be traced or frozen, and what should exchanges, custodians, DAOs, and enterprises using payment-capable agents do immediately?

Halil, the common failure is delegated authority without intent verification. In each case, the system treated a technically valid action as authorized money movement: Summer.fi’s vault accounting accepted an inflated NAV/offboarding path; the same-block backrun extracted value from transaction ordering; Ill Bloom wallets appear exposed through weak PRNG key generation; BonkDAO is a governance-authority problem; and the AI-agent case is payment authority being steered by hostile web context rather than verified human intent.

On traceability: Summer.fi is the strongest freeze candidate from the sources I have. Blockaid reportedly identified the attacker address, exploit contract, and affected contracts, and reporting says stolen funds were swapped and moved to an attacker-controlled address. That means exchanges, stablecoin issuers, and analytics providers should already be labeling the cluster and watching for DAI/USDC movement, bridges, mixers, and CEX deposit addresses. For the $2M same-block backrun, the trace starts on-chain, but recovery depends on whether proceeds hit a cooperative exchange; pure MEV extraction can disappear quickly through routing and fresh wallets. For Ill Bloom, the immediate issue is not contract recovery but wallet migration: if weak PRNG generated predictable keys, any remaining funds in exposed wallets should be treated as already compromised. For BonkDAO, I do not have source-backed wallet-path details here, so I would not claim a freeze route without treasury addresses and transaction hashes.

Immediate actions: exchanges should add the Summer.fi attacker cluster and any same-block extraction proceeds to enhanced monitoring and freeze on confirmed deposits. Custodians should treat weak-key wallet products as a live key-compromise class: rotate, migrate, and block reuse of generated seeds. DAOs should require timelocks, quorum-quality checks, emergency vetoes, and treasury movement simulation before governance execution. Enterprises using payment-capable AI agents need hard payment controls now: allowlisted recipients, transaction previews, human approval above tiny thresholds, domain/context isolation, and no agent-initiated Ethereum transfers from untrusted web content.

The money lesson is simple: if a system can move funds, “valid instruction” is not enough. It must prove authority, intent, and adversarial safety before value leaves.

Sofia, give us only the regulatory decisions that matter this week. Map likely obligations or board-level triggers from: CISA emergency directive on Cisco SD-WAN for government/critical infrastructure, active ColdFusion/Gitea/NetScaler exploitation, TeamPCP CI/CD credential exposure tied to ransomware, KDDI’s 12.2M emails/7.6M passwords, DHS HSIN/SharePoint investigation, xAI/Grok deepfake CSAM allegations, and upcoming CIRCIA/EO 14117 direction. Where must organizations preserve evidence, notify, or avoid premature public claims?

Halil, the decisions this week are evidence-preservation and notification-readiness, not broad public disclosure. For Cisco SD-WAN, the hard legal trigger is federal: CISA ED 26-03 applies to FCEB agencies running affected Cisco SD-WAN and directs them to identify, update, and assess possible compromise. Critical infrastructure operators outside FCEB should treat it as regulatory-grade urgency, but not call it a mandatory ED obligation unless they are in scope. Preserve forensic data before remediation where possible; do not patch first and destroy the compromise record.

For ColdFusion/Gitea/NetScaler exploitation, vulnerability exposure alone is not yet a breach notification trigger. The board decision is: preserve logs, determine compromise and data access, and avoid “no data impacted” statements until confirmed. TeamPCP CI/CD credential exposure tied to ransomware is different: preserve CI/CD secrets history, runner logs, repo access logs, ransom communications, and payment evidence. Under CIRCIA, once the final rule is effective, covered entities will have to report covered cyber incidents within 72 hours of reasonable belief and ransom payments within 24 hours; CISA currently says reporting is not required until the final rule is effective.

For KDDI’s reported 12.2M emails / 7.6M passwords, treat this as notification-preparation now: user notice, password reset, credential-stuffing warnings, and regulator assessment. I could not verify the current Japanese APPI notification deadline here, so I would not quote a clock. For DHS HSIN/SharePoint, preserve M365/SharePoint audit logs and avoid premature attribution or “contained” language. For xAI/Grok deepfake CSAM allegations, preserve prompts, outputs, moderation decisions, model-safety logs, and escalation records; do not publicly minimize alleged CSAM as “synthetic” before counsel reviews reporting duties. For EO 14117, I could not verify current implementing details here, so the board action is preparatory: inventory sensitive personal/government-related data flows and vendor access, not announce compliance conclusions.

Claim: You ranked JADEPUFFER/Langflow below Cisco, Adobe, Citrix, Gitea, and TeamPCP because you did not have enough visible evidence to assert the exploit path or exploitation status. Counter-evidence: The source pack marks JADEPUFFER/Langflow ransomware as mustlead, evidence=strong, threat=critical, exploitstatus=activeinwild, and says Picus reported an LLM-run workflow exploiting CVE-2025-3248 in an internet-facing Langflow deployment to hunt credentials and wallets, move laterally, and destroy or encrypt MySQL and Nacos services. It also lists Langflow CVE-2026-55255 as KEV-listed authorization-bypass exploitation and CVE-2024-37014 as critical RCE affecting 0.6.19 and earlier. Reassess: does Langflow stay below the edge-appliance queue, or does it move into the same-day assume-compromised lane for exposed instances?

You’re right to challenge that. With the source-pack evidence now explicit, Langflow does not stay below the queue for exposed instances. It moves into same-day assume-compromised-and-contain.

The difference is kill-chain closure. CyberBrief marks “JADEPUFFER - Langflow - ransomware breach” as CRITICAL, must_lead, evidence=strong, and exploitstatus=activein_wild. The campaign reporting says attackers got code execution on an internet-facing Langflow instance via CVE-2025-3248, then hunted cloud, API, and database credentials, pivoted into MySQL/Nacos, and performed destructive or extortion actions. BleepingComputer’s CyberBrief summary adds the full chain: RCE, recon, credential theft, lateral movement, persistence, privilege escalation, ransomware deployment, rogue Nacos admin creation, and encryption of 1,342 Nacos configuration items. That is not theoretical exposure. That is the whole burglary route, from broken window to emptied safe.

So my corrected queue is: Cisco Catalyst SD-WAN/UAT-8616, Adobe ColdFusion CVE-2026-48282, JADEPUFFER/Langflow, Citrix NetScaler/CitrixBleed, TeamPCP, then Gitea — with the caveat that any confirmed TeamPCP credential compromise jumps straight into containment because stolen CI/CD credentials are already post-exploitation. For internet-facing Langflow, the action is not “patch and watch.” It is contain, snapshot, rotate secrets, inspect Langflow workflows, check cloud/API/database credential use, hunt MySQL and Nacos for rogue users/config changes, then patch.

I’d still keep Cisco and ColdFusion at the very top where exposed because the handoff already marks them active-in-wild edge/server footholds, but Langflow now sits in the same emergency lane. It is not a CVE scoreboard item anymore; it is a demonstrated ransomware path.

James, close this like an operator. You have heard the panel: Alex ranks Cisco SD-WAN, ColdFusion, Citrix/NetScaler, Gitea, and now exposed Langflow/JADEPUFFER as same-day patch-and-hunt or assume-compromised; Marcus says kill artifacts that can mint or deploy trust before ordinary password work; Maya focused on huntable paths for EtherRAT/JADEPUFFER/CAI/Turla; Priya says pause and isolate CI/CD, GitOps, Kubernetes, runners, Argo CD, and cloud IAM until trust is proven; Arjun says agent output must not cross trust boundaries into payments, repo publishing, or tool execution; Sofia says preserve evidence and prepare notification clocks rather than rush public disclosure. Build a decision-ready 24-hour plan and a 7-day stabilization plan. Be explicit about what to do first if teams have limited change windows, and name which items we monitor rather than action today.

Halil, I’d run the first 24 hours as a containment-and-trust operation, not a patch marathon. If change windows are limited, the order is: 1) exposed control planes and edge access, 2) systems that can mint or deploy trust, 3) exposed app vulnerabilities, 4) malware hunts. So: take Cisco SD-WAN Manager evidence first — Cisco evidence available here calls out request admin-tech, /var/log/scripts.log, suspicious vScript activity, and edge configuration changes — then restrict management access and patch only after staging or vendor-confirmed fixed train. For Citrix/NetScaler, exposed Langflow/CVE-2026-55255/JADEPUFFER, and externally reachable ColdFusion/Gitea, put them in the same-day window: snapshot logs, restrict exposure, patch if the app owner can validate version impact, then hunt. I do not have current advisory/patch detail in the evidence here for ColdFusion or Gitea, so if they are internal-only and no exploit telemetry exists, they lose priority to Cisco, NetScaler, Langflow, CI/CD, and cloud IAM.

For the same 24 hours, follow Marcus and Priya’s point: kill trust-minting paths before ordinary password work. Freeze CI/CD deploys, pause GitOps auto-sync, isolate runners, lock Argo CD admin paths, disable repo publishing tokens, rotate cloud IAM keys used by pipelines, and require manual approval for any AI-agent output that can trigger payments, code publishing, shell/tool execution, or production deployment. For hunts, keep them high-fidelity: Cisco vScript/config-change events, NetScaler auth/session anomalies, Langflow unauthorized flow execution and database access, suspicious RDP-file execution for Turla/STOCKSTAY-style tradecraft, and ransomware staging/exfil behavior tied to JADEPUFFER. Do not ship broad YARA/Sigma guesses today; without confirmed rule sources, that will flood the SOC. My expected false-positive rate for the Cisco config-change and vScript hunt is low, roughly 1–3%; generic AI-agent or Langflow behavioral alerts will be noisier, likely 10–20%, so keep those scoped to exposed instances.

Seven-day stabilization: complete staged patching and compensating controls for all confirmed vulnerable Cisco SD-WAN, NetScaler, Langflow, ColdFusion, and Gitea assets; rebuild or re-register CI/CD runners rather than merely rotating one token; reconcile Kubernetes, Argo CD, and cloud IAM state against known-good IaC; rotate signing keys, deploy keys, OAuth apps, service principals, runner tokens, and privileged API tokens before mass user password resets. Sofia’s evidence point matters: preserve logs, images, configs, pipeline histories, cloud audit trails, and agent transcripts now, because notification clocks may move faster than technical certainty. Items I’d monitor rather than action today unless exposed or compromised: internal-only ColdFusion/Gitea, AI tools with no tool-execution/payment/repo-publish capability, non-production runners with no production credentials, and Turla/CAI/EtherRAT hunts outside the relevant exposure profile.