Session CRT-20260622 — 22 June 2026 · Morning Edition

That correction matters. The room should treat the React Router item as broader than the initial createFileSessionStorage() framing. James is now saying the earlier guidance under-scoped the exposure: the corpus points to several React Router vulnerabilities around 7.9.3, including open redirect, denial of service, XSS in redirect handling, and a more severe deserialization path tied to Framework Mode with possible RCE. Just as important, we should not assume React Router 6.x is automatically safe. Some advisories appear to map to 6.x fixes as well, with different patched versions depending on the issue.

The operational takeaway is that this is no longer a single-function check. Teams need to inventory how React Router is used: Framework Mode, Data Mode, unstable RSC, redirect helpers, and any handling of untrusted paths or redirect targets all change the risk picture. The caveat is that we are still relying on the advisory corpus as presented here; we have not independently validated every version-to-CVE mapping in the room. So the safe phrasing is: verify against the exact advisory matrix, but do not dismiss 6.x or 7.9.3-era deployments without checking them.

That naturally leads to two tracks. First, we need Alex to drill into the mode-specific React Router risk so defenders can prioritize which applications are truly urgent versus merely version-adjacent. At the same time, we are broadening back out to the other high-impact items: James will give the M365 defense plan for AI-assisted adversary-in-the-middle activity, and Sofia will assess the breach-claim implications assuming sensitive Council of Europe HR, payroll, banking, tax, medical, CV, and personnel data may be involved.

Good, this action gave us three useful separations.

On React Router, Alex has narrowed the triage question to mode and data path. The most severe concern in this corpus is not “any React Router app equals RCE”; it is specifically the Framework Mode deserialization path, where server-capable loaders/actions make the exposure materially different. Declarative Mode and Data Mode appear out of scope for that RCE class, based on the evidence Alex cited, though they may still be relevant for redirect, XSS, or open redirect issues if untrusted input reaches navigation or redirect functions. So the room’s practical checkpoint is: identify the router mode first, then trace whether attacker-controlled input reaches redirect/navigation or deserialization boundaries, and only then assign severity.

On Microsoft 365, James is drawing a hard line between user-awareness controls and session-defense controls. AI-assisted AiTM does not fail because users never had MFA; it often succeeds after users complete MFA. The defense plan therefore has to prioritize blocking device-code flow by default, fast session and refresh-token revocation, phishing-resistant MFA, consent governance, Conditional Access based on risk, location, IP, and device posture, and monitoring for post-auth persistence such as OAuth grants, inbox rules, mailbox delegation, and new device registration. Training still helps, but it cannot be the control that stops token replay.

On the Council of Europe claim, Sofia’s point is procedural discipline under uncertainty. The breach and the PeopleSoft zero-day claim are not confirmed in this action, but the alleged data categories—HR, payroll, bank, tax/social security, medical, CV, and personnel records—are serious enough that a European institution should preserve evidence, document the incident, prepare notification paths, and assess whether Article 33 and Article 34 thresholds are met. The caveat is important: high risk is plausible, not yet proven from the packet alone.

Next, we turn to two cleanup questions where precision matters. Alex will tighten the separate ksmbd and AryStinger vulnerability items so we do not blur unrelated technical risks, and Lena will reconcile the Council of Europe scope claims, especially the difference between “10,000 employees” and the much larger corpus figures being reported.

Thanks, that helps narrow two very different risk lanes.

On ksmbd and CVE-2026-52911, Alex has kept us disciplined: the supported claim is session confusion inside the Linux kernel SMB server path. The issue is about a connection-wide binding state allowing lookup of sessions that should not be reachable from that connection. So the defensible outcome is unauthorized session resolution or access-control bypass within SMB handling, not, from this packet alone, remote code execution, arbitrary kernel memory corruption, or a universal Linux compromise. The immediate scoping question is therefore very practical: is the host actually running ksmbd and exposing that SMB service path? If it is using user-space Samba instead, this specific ksmbd claim does not automatically apply.

We should also note what did not get tightened here: the AryStinger lane was assigned, but the returned answer only addressed ksmbd. So we should not treat AryStinger as resolved by this action.

On the Council of Europe / PeopleSoft issue, Lena gave us a useful operational framing but also introduced a confidence boundary we need to test. She treats the broader PeopleSoft exploitation campaign as confirmed, tying CVE-2026-35273 to activity attributed to UNC6240/ShinyHunters, while keeping the Council of Europe victim counts and file-volume numbers at only moderate confidence because those appear to come from attacker or media claims. That distinction matters: defenders can act as though HR and payroll data would be highly abusable if exposed, but we should not overstate the exact scale or victim accounting without independent confirmation.

The next turn should challenge that linkage directly. If another analyst could not verify the Council of Europe connection to confirmed PeopleSoft exploitation, then we need to separate “confirmed campaign exists” from “this named incident is part of it.”

Good, this is an important correction to lock in before we move on. Lena has separated three layers that were getting compressed together. First, there is high-confidence confirmation that CVE-2026-35273 in Oracle PeopleSoft is real and exploitable, and that Google/Mandiant have tied an active ShinyHunters/UNC6240 campaign to exploitation affecting more than 100 organizations. That part can be treated as established for defensive planning.

Second, the Council of Europe item should not be described as publicly confirmed. The better wording is that it is a plausible, reported victim claim under investigation, because media reporting says the Council is looking into ShinyHunters’ claim and the claim fits the broader PeopleSoft exploitation pattern. But fitting a known campaign pattern is not the same as victim confirmation. Third, the headline figures — 10,000 employees, 429,000 files, 297GB, and the detailed data inventory — remain attacker-claimed unless and until validated by the affected organization, investigators, or reliable leaked-data analysis. So our confidence is high on the broader campaign, moderate on Council victimhood, and low on the exact claimed scope.

That distinction matters operationally. Defenders should not wait for a Council-specific confirmation before checking PeopleSoft exposure, patch status, logs, and identity activity. But communicators and analysts should avoid presenting the Council breach or the data volumes as settled fact. The right posture is: confirmed campaign, plausible alleged victim, unverified breach scope.

We now turn from attribution and claim hygiene back to practical control decisions. The next parallel pass looks at two very different but common exposure paths: Marcus will give us a decision-ready Microsoft 365 control plan for AI-assisted adversary-in-the-middle phishing, including device-code flow, OAuth consent, token revocation, and Conditional Access; Rafael will cover AryStinger activity against D-Link and related end-of-life edge devices, focusing on external checks and small-office guidance. Both are about shrinking attack surface before an incident becomes a public claim.

Thanks, Marcus and Rafael. This gives us two very practical defensive tracks to carry into the close. On the identity side, Marcus is saying the M365 answer to AI-assisted AiTM phishing cannot be “train users harder” or “reset the password after the fact.” The decision-ready plan is to reduce attack paths up front: block device-code flow unless there is a documented business exception, restrict OAuth consent and third-party grants, and move priority users toward phishing-resistant MFA such as FIDO2 or passkeys. He also reinforced a key incident-response point: if a session or refresh token has been captured, password reset alone is not sufficient. Teams need token and session revocation built into their playbooks, backed by Conditional Access and telemetry around device-code sign-ins, abnormal session behavior, identity risk, device state, and suspicious sign-in context.

Rafael’s router guidance is a useful reminder that the perimeter is not only cloud identity. For AryStinger, the concern is older D-Link SOHO gear, including DIR-850L and DIR-818LW-class devices, being used for proxying, tunneling, DNS tampering, scanning, or command execution. The public reporting he referenced supports treating exposed end-of-life devices as high-risk, especially where vendor support has already ended. The practical checks are not exotic: identify the exact model and revision, look for unexpected WAN-side management exposure, unexplained outbound connections, altered DNS settings, wrong resolutions, HTTPS warnings, fake-looking login pages, intermittent proxy latency, or signs the router is behaving like a relay. His caveat is important: on EoL routers, “cleaning” may not be durable if there is no supported fix path, so replacement can be the safer business decision.

So the room has now tied together two different but related defensive themes: remove durable footholds, whether they are cloud tokens and OAuth grants or compromised office routers acting as covert infrastructure. We have not independently verified every vendor-specific indicator or every reported campaign detail here, but the controls discussed are reasonable, proportionate, and actionable. With that, we can move from individual scenarios into the final synthesis: what defenders should prioritize first, what language should remain cautious, and where organizations should avoid overclaiming certainty.