Session CRT-20260625 — 25 June 2026 · Morning Edition

Good checkpoint. We tightened several loose threads, but not all of them equally. On Langflow, Alex gave us a much sharper technical picture: treat versions before 1.9.2 as affected, focus on exposed Public Flows or Shareable Playground use, and watch /api/v1/build_public_tmp for unauthenticated build requests carrying Python code inside the submitted JSON flow object. The immediate hunting path is clear: reverse proxy hits to that route, public-flow changes, then host telemetry for child processes, interpreter launches, and outbound connections from the Langflow box. One caveat: the Livewire thread did not get the same level of confirmation in this pass, so we should not overstate mechanics or version guidance there yet.

James added the operator layer for containerd and CI/CD. The key point is that containerd is a node-runtime problem for Kubernetes nodes and Docker hosts actually running affected branches, not a generic “all Linux” panic. Tenable can help sort versions, but it is not exploitation evidence. For the first day, patch runtime nodes, prioritize clusters where untrusted users can create pods, and look at kubelet, containerd, log access, and host file access paths. On Cordyceps-style CI/CD risk, he kept the audit practical: workflow files, reusable actions, generated YAML, pull_request_target, and any place PR metadata or comments cross into privileged execution.

Lena helped put confidence labels around the noise. FortiBleed sounds newly operationalized at scale, but the response posture does not really change: rotate credentials, revoke sessions, verify MFA, and treat appliances as potentially compromised. For Cordyceps, the mechanism is credible; the broad campaign framing is less proven. Akira remains the stronger threat-actor signal, while OpenClaw prompt-injection is a lower-confidence, surface-specific watch item rather than a driver of today’s queue.

That sets up the next turn nicely: we need to challenge the prioritization. If Langflow has a clean unauthenticated RCE path on exposed public flows, does “medium pending inventory” still hold, or should it move up alongside the infrastructure and CI/CD items?

Good, this challenge materially changed the prioritization. James accepted that the earlier “medium pending inventory” placement was too conservative for exposed Langflow and Livewire. The important distinction is exposure: if Langflow Public Flows or Shareable Playground are internet-facing, CVE-2026-48519 now belongs near the top of the queue because the room is treating it as unauthenticated RCE with a fixed version at 1.9.2. That moves it ahead of broad containerd version checking and ahead of general CI/CD audit work.

He made the same adjustment for Laravel Livewire, with a caveat that our Livewire technical detail is still thinner than Langflow’s. The risk framing is no longer just “possible web framework issue”; James tied the concern to remote command execution during property update hydration and to campaign reporting around credential theft, including .env-style secret harvesting. So for operators, the practical order over the next 24 hours becomes: KEV or actively exposed Ubiquiti and Cisco SD-WAN first, then internet-exposed Langflow and Livewire, then containerd where there is real pod-creation or multi-tenant exposure, and finally broader CI/CD audit work.

What we have not yet done is give defenders the same concrete hunting package for Livewire that Alex gave for Langflow. We still need version guidance where known, the exploit path in plain language, what the reported campaign infrastructure or naming such as shoc.enz actually implies, and what web, server, and application telemetry would make this actionable. That is the logical next turn: fill the Livewire gap so the elevated priority comes with specific checks rather than just a higher severity label.

That fills an important gap. Alex is now saying Livewire has the firmer exploitation picture in this discussion: Livewire v3 from 3.0.0 up to, but not including, 3.6.4 is the range he identified, with the attack path centered on crafted property-update hydration leading to code execution. The key operational takeaway is that this is not just “possible RCE” in the abstract. The presence or execution of shoc.enz changes the incident posture because Alex described it as a credential-stealer stage intended to pull .env material and application secrets, not merely a loader or proof-of-concept artifact.

So for defenders, the hunt has two layers. First, look at the application edge: Livewire component update traffic, unusual POSTs around hydration behavior, and suspicious property-update patterns. Second, pivot quickly to host and runtime evidence: curl | bash style fetches, Bash children spawned from the web application context, filesystem reads against .env, config files, and application directories, and any direct sign of shoc.enz. If that script executed, the room’s working assumption is that database credentials, API keys, Stripe keys, AWS keys, mail credentials, and session or signing secrets may have been exposed, especially anything reachable through the app’s runtime identity.

The caveat is that we are relying on Alex’s stated affected range and mechanics here; we have not independently walked through vendor advisories or exploit code in this round. But for prioritization, the practical conclusion is clear: exposed Livewire apps in that version window deserve urgent patching to 3.6.4 or later, log review, and secret rotation if compromise indicators appear.

With that web-app credential theft thread established, the discussion naturally turns to identity abuse on the SaaS side. Marcus will now close the Microsoft 365 device-code and token phishing segment, where the question is less about server-side RCE and more about how tenant admins constrain token issuance, session persistence, and risky authentication flows before stolen or phished credentials become durable access.

Thanks, Marcus. That gives us a practical closeout on the Microsoft 365 device-code phishing thread. The main point is that this attack path is not really about stealing the user’s password at all. It abuses a legitimate authorization flow: the victim completes the device-code prompt, the attacker receives usable tokens, and the tenant may then be dealing with refresh-token access rather than a simple credential compromise.

The control message is also clear: if the organization does not have a real business dependency on device-code flow, block it with Conditional Access. If it does have a dependency, Marcus is urging a narrow exception model, not broad tolerance. Those exceptions need to be visible and monitored, especially by filtering Entra ID sign-in logs for device-code activity through authentication flow or protocol tracking. The caveat he raised is important too: defenders should not assume that “we blocked it” means there will be no related successful activity, because Conditional Access is evaluated at token issuance and existing refresh tokens can complicate what shows up in the logs.

For incident response, the priority order matters. If a device-code phish is suspected, revoking sessions is the immediate move; password reset alone is not enough if token theft has already occurred. Where available, Token Protection can reduce token replay risk by binding refresh tokens to the device, but that is a control to deploy ahead of time, not a substitute for revocation during an active incident.

That sets us up naturally for the next challenge. We have just talked about an attack where phishing succeeds without the attacker needing the password directly. So now we need to test a broader claim: whether phishing-resistant authentication such as FIDO2 or passkeys would prevent every breach that begins with phished credentials, or whether token theft, session abuse, enrollment gaps, fallback paths, and post-authentication compromise leave room for exceptions.

That correction is important, Marcus, and it helps us avoid an overly simple takeaway. What the room just clarified is that “phishing-resistant” does not mean “token-abuse-proof.” FIDO2 and passkeys are very strong against credential replay and many adversary-in-the-middle patterns, but they do not automatically stop an attacker who convinces a user to complete a legitimate device-code flow, grant OAuth consent, or operate inside an already-issued session. In those cases, the organization may not be fighting over the password anymore; it may be fighting over valid tokens, consent grants, and session state.

So the more defensible position is narrower: passkeys materially reduce a large class of phishing risk, especially where the attacker’s goal is to capture or replay credentials, but they are not a complete answer to device-code phishing, malicious consent, or post-authentication token persistence. That distinction matters because it changes the response playbook. If the suspected path is token or consent abuse, password reset alone may be insufficient. The response has to include revoking sign-in sessions, reviewing or removing suspicious app consents, and deciding whether device investigation or reimage is warranted.

This also ties back neatly to the control strategy we have been circling around: reduce the exposed flows, not just the exposed passwords. Block device-code flow where the business does not need it, make exceptions explicit and narrow where it does, enforce phishing-resistant authentication for interactive sign-in, and use token-binding or token-protection capabilities where they are available. And from a detection standpoint, Marcus is pointing us toward hunting for device-code activity and unusual consent patterns rather than assuming MFA success means safety.

With that correction on the table, we can now move into the final synthesis with a more balanced conclusion: passkeys are a major upgrade, but identity defense still has to account for authorized flows, tokens, consent, and session lifecycle.