Not Samba: Cut Off Exposed ksmbd on TCP/445 Before Kernel Fixes

Alex, give us the 30-minute version for the technical exposure items. First: CVE-2026-52911 in Linux ksmbd/SMB — explain what ksmbd is, realistic exposure patterns, affected distro/package uncertainty, exploitability assumptions, and detection limits. Second: React Router 7.9.3/Snyk — clarify affected modes and versions, RCE/deserialization preconditions, and XSS/open redirect/DoS implications. Third: AryStinger — explain capabilities, likely D-Link/NAS exploitation paths, regional/model exposure if known, and what telemetry would prove compromise. No Splunk rehash unless there is genuinely new exploit evidence.

Here’s the 30-minute read.

CVE-2026-52911 / ksmbd: ksmbd is the in-kernel SMB server for Linux. That means the attack surface is not “all Linux,” it’s specifically hosts running the ksmbd server path and exposing SMB to untrusted clients. The CVE record snippet only shows a kernel fix in ksmbd around conn->binding slow-path handling; I do not have enough in this thread to claim the exact exploit primitive or whether it’s RCE versus crash/logic corruption. So the operational question is simple: is ksmbd even enabled, and is SMB reachable from hostile networks? If yes, treat it as a network-facing kernel service exposure problem, not a generic distro issue. Distro/package certainty is still fuzzy from what I have here; the safe assumption is “kernel versions with the backported ksmbd fix are affected until vendor advisories say otherwise.” Detection is also limited: unless you have SMB service telemetry, kernel crashes/oops, or very specific ksmbd logging, you’re mostly hunting symptoms, not a clean exploit signature. In plain English: exposed SMB on ksmbd is the back door; if you can’t prove reachability, don’t panic. If you can, patch fast.

React Router 7.9.3 / Snyk: the real exposure here is mode-dependent. From the GitHub advisory snippet, createFileSessionStorage() in @react-router/node 7.0.0 through 7.9.3 is vulnerable when it’s used with an unsigned cookie, because an attacker can make the session read/write outside the intended directory. That is a file-access flaw, not automatic RCE. Separate React Router advisories in the evidence show the more dangerous stuff lives in Framework Mode / Data Mode / unstable RSC modes, where loader/action-driven navigation or redirects can become XSS via open redirect / unsafe URL execution; another advisory shows open redirect behavior in 6.0.0–6.30.1 and 7.0.0–7.9.5, patched in 7.9.6. Bottom line: don’t collapse this into “React Router RCE.” The preconditions matter: which mode, whether createFileSessionStorage() is used, whether cookies are unsigned, and whether the app is on a vulnerable redirect/navigation path. XSS and open redirect are real; RCE/deserialization is not established by the evidence I have here.

AryStinger: I have no clean, direct evidence in this thread tying “AryStinger” to a specific malware family report, but the D-Link NAS evidence that did surface points at the usual appliance kill chain: internet-facing NAS, weak/default or logic-flaw-based auth, then remote control of end-of-life D-Link devices like DNS-320L / DNS-325 / DNS-327L / DNS-340L. The telemetry that actually proves compromise on a NAS is boring and ugly: unexpected auth to management services, new users or privilege changes, outbound callbacks from the box, webshell-like file drops, unusual cron/startup persistence, and file modifications in web-accessible or admin directories. If AryStinger is being discussed as a D-Link/NAS implant, I’d want the exact model and firmware before I say more. Regional exposure and model targeting are still unknown from this thread. If you want, I can turn this into a defender checklist by product: ksmbd, React Router app, and NAS.

James, convert today’s exposure items into action. For ksmbd/CVE-2026-52911, tell operators what to disable, segment, monitor, or firewall until vendor fixes settle. For React Router 7.9.3, give concrete upgrade guidance for 6.x and 7.x users and compensating controls when upgrades cannot happen immediately. For AryStinger, give containment and EOL router replacement guidance. Also include a brief patch ticker: Debian 13 Squid update to 6.13-2+deb13u2, Debian 11/12 libgd-perl upgrade for command execution/file overwrite risk with no exploit signal, and Fedora 44 Chromium update to 149.0.7827.155.

Look, here’s the action list.

For ksmbd / CVE-2026-52911, I’d treat this as a kernel-side exposure until the fixed kernel lands. The evidence I have says the issue is in ksmbd session binding / slowpath handling, so the practical move is: disable ksmbd if you do not absolutely need SMB on Linux, or at minimum keep it off any internet-facing host, segment it hard, and firewall TCP/445 to only the exact client subnets that need it. If ksmbd must stay up, monitor for SMB service restarts, unusual session churn, and any host that is unexpectedly accepting SMB from non-approved networks. That’s the “who owns this at 3am” control set while vendor fixes settle.

For React Router 7.9.3, the GitHub advisory I found is about unauthorized file access when using createFileSessionStorage() with unsigned cookies, and the Netlify advisory summary shows the affected React Router ranges include 7.0.0–7.9.3 for that issue. So the concrete guidance is: 7.x users should upgrade past the patched release line; 6.x users are not in that affected range for this specific advisory. If you cannot upgrade immediately, stop using createFileSessionStorage() with unsigned cookies, rotate to signed cookies or a different session backend, and block any path that lets untrusted users influence session-file access. I do not have evidence in hand for a separate 6.x fix here, so I’m not going to invent one.

For AryStinger, the operational answer is blunt: assume legacy/EOL routers are disposable until proven otherwise. The reporting I found says to take old router devices offline if firmware has not been updated for a long time, replace them, and check for infection signs; IC3 also calls out EOL routers with remote administration enabled as a real abuse path. So the containment play is: disable remote admin, isolate the router from production access paths, inspect for config changes and connectivity anomalies, then replace EOL gear instead of trying to “clean” it in place. If it’s a business-critical edge device, schedule a controlled cutover, not a long remediation cycle.

Patch ticker: Debian 13 Squid 6.13-2+deb13u2, Debian 11/12 libgd-perl for the command-execution/file-overwrite risk with no exploit signal I found, and Fedora 44 Chromium 149.0.7827.155. My priority matrix: CRITICAL today = ksmbd exposure, EOL router containment, any production React Router app using the vulnerable file session pattern; HIGH this week = upgrade React Router and replace legacy routers; MEDIUM = the Debian/Fedora maintenance updates on normal patch cadence unless those systems are internet-facing or high-value.

Lena, cover the intelligence and validation lane. First: AI-assisted AiTM phishing against Microsoft 365 — what is genuinely new versus prior AiTM discussion, how credible is the 54% success-rate claim, and what changes for token, session, device-code, OAuth, and phishing-resistant MFA priorities? Second: Council of Europe breach claim — validate source confidence, scope the claimed 10,000 employee HR records, assess the alleged PeopleSoft zero-day angle without accepting it blindly, and outline HR-data abuse risks. Third: AudiA6 takedown — focus on ransomware cash-out infrastructure, identity-fraud-enabled exchange abuse, evidentiary path to admins, and likely disruption impact.

Timeline first: AiTM device-code phishing is the newer wrinkle in an old playbook — the novelty is AI-assisted scale and better targeting, not a new bypass class. Microsoft’s guidance points to the real pivot: device code flow, live session theft, and OAuth persistence are the pressure points; phishing-resistant MFA only closes the door if the auth flow itself is hardened. Confidence on the 54% success-rate claim is low unless the specific source methodology is shown; I found campaign reporting, but not enough evidence to trust that metric as a generalized rate.

On the Council of Europe case, I’d keep the breach claim at moderate confidence and the PeopleSoft zero-day angle at low-to-moderate confidence until Oracle/CVE-level corroboration is in hand. The risk is straightforward: HR records — payroll, bank, tax, medical, CVs — are ideal for identity theft, extortion, and targeted social engineering. On AudiA6, the takedown evidence is much stronger: this is a laundering pipeline, not just a single site, with admins tied to dark-web forum operations and exchange-account abuse built on stolen/purchased identities. Disrupting domains, servers, Telegram, and exchange access together should materially slow cash-out; confidence high.

Claim: Your first React Router guidance focused on createFileSessionStorage and said 6.x users are not in scope for that specific issue. Counter-evidence: CyberBrief corpus says Snyk lists multiple React Router 7.9.3 vulnerabilities: open redirect, unbounded resource DoS, XSS in redirect handling, and critical deserialization in Framework Mode that may allow RCE; some issues also affect 6.x, with fixed versions including 6.30.4, 7.13.2, 7.14.0, 7.14.1, 7.14.2, and 7.15.0 depending on the issue. Revise the upgrade and compensating-control guidance so teams do not under-scope exposure.

Yes — I need to tighten that. My earlier React Router guidance was too narrow and would have under-scoped the blast radius. The corpus now shows multiple React Router 7.9.3 vulnerabilities, not just the createFileSessionStorage() issue: open redirect, DoS, XSS in redirect handling, and a critical deserialization/RCE path in Framework Mode. Some of those issues also hit 6.x, with fixes split across 6.30.2 / 6.30.4 / 7.9.6 / 7.13.2 / 7.14.0 / 7.14.1 / 7.14.2 / 7.15.0 depending on the advisory. So the operational answer is: do not treat 6.x as “out of scope” by default.

The revised guidance is: CRITICAL today for any app using Framework Mode, Data Mode, unstable RSC, redirect helpers, or untrusted path handling. Teams on 7.9.3 should move to the specific fixed release for each advisory, and if they can only do one thing right now, get to the latest patched 7.x line that closes the known 7.13.x/7.14.x/7.15.0 issues. Teams on 6.x should verify against the exact advisory matrix: some exposures are fixed in 6.30.4, others in 6.30.2. Compensating controls until upgrade: block or sanitize untrusted redirect targets, reject protocol-relative URLs, do not pass user-controlled paths into navigate(), <Link>, or redirect(), disable or isolate Framework/Data/RSC features where practical, and put WAF/input validation in front of any exposed redirect surface. If the app is in a browser-only declarative mode, risk is lower for some issues — but I would still validate mode-by-mode before relaxing.

Alex, drill into the React Router mode-specific risk using this corpus evidence: Snyk flags critical deserialization in Framework Mode with possible RCE, plus XSS/open redirect/DoS, while several issues do not affect Declarative Mode or Data Mode. Give us exposure triage: what questions should app teams ask to determine whether they are in Framework Mode, whether untrusted input reaches vulnerable paths, and whether 6.x exposure is redirect-only versus server-side code execution?

Here’s the triage version.

First question: are you actually in Framework Mode? If the app uses react-router with Framework Mode, that is the risky server-capable path. The evidence here says the critical deserialization/RCE class is tied to Framework Mode and does not impact Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter / <RouterProvider>) for the RCE path. So teams should ask: Are we using createBrowserRouter or RouterProvider only? Are we on plain <BrowserRouter>? Or are we using Framework Mode features that run loaders/actions through the server? If the answer is Framework Mode, assume you’re in the blast radius until proven otherwise.

Second question: does untrusted input reach redirect/navigation or deserialization paths? The data shows two distinct buckets. One is redirect/XSS: loaders/actions in Framework/Data/RSC modes can turn unsafe URLs into client-side JavaScript execution; in 6.x, the open redirect issues are basically phishing/user-redirection unless untrusted input is fed into navigate, <Link>, or redirect. The other is deserialization/RCE: that is the Framework Mode issue, and the practical question is whether external requests can drive the vulnerable path without auth or with weak gating. So ask teams: Do any loaders/actions/redirect helpers consume user-controlled URL, session, or request data? Do we ever pass attacker-influenced strings into navigate, redirect, or session storage helpers? Is createFileSessionStorage() used with unsigned cookies? If yes, you’ve got a real exposure, not a theoretical one.

Third question: is this 6.x redirect-only or server-side code execution? Based on the corpus here, the 6.x exposure called out is redirect/XSS behavior, not server-side code execution. The RCE/deserialization finding is associated with 7.x Framework Mode. So don’t smear the 7.x critical over the whole 6.x line. For 6.x, the operational risk is open redirect and potential client-side script execution when unsafe URLs are handled badly. For 7.x Framework Mode, it’s more serious: possible unauth RCE if the request path is reachable and the app actually uses the vulnerable mode. That’s the kill chain. Not the marketing fluff.

James, separate from React Router, give me the M365 defense plan for AI-assisted AiTM: token/session controls, device-code flow restrictions, OAuth app consent governance, Conditional Access signals, phishing-resistant MFA deployment, detection patterns, and what user training cannot solve.

Here’s the plan, cleanly: block device code flow by default and only allow documented legacy exceptions; revoke sessions/refresh tokens fast when AiTM is suspected; move interactive users to phishing-resistant MFA; and lock down OAuth consent so a stolen session doesn’t become permanent access. Microsoft’s guidance says to get as close as possible to a unilateral device-code block, and the Entra docs say CA should key off identity signals like IP/location, device status, and risk. Marcus is right: SMS, push, and “MFA enabled” are not enough against proxy phishing.

For detections, I’d watch for device-code sign-ins from unusual geos or new devices, repeated consent-grant prompts, new OAuth app approvals, refresh-token revocation followed by rapid reauth, inbox rule creation, mailbox delegation changes, and post-auth persistence like new device registration. What user training cannot solve is the core problem: AiTM steals the session after the user does the right thing. Training helps reduce click-through, but it does not neutralize token replay, consent abuse, or device-code relay. My priority matrix: CRITICAL today = block device-code flow, force phishing-resistant MFA for admins/high-risk users, and enable rapid token/session revocation; HIGH this week = tighten consent governance and Conditional Access on risk/device state; MEDIUM = user training and awareness, because it’s supporting control, not a primary brake.

Sofia, on the Council of Europe breach claim: assume the data may include HR/payroll, bank, tax/social security, medical, CV/personnel records for thousands of employees/applicants, but breach confirmation and PeopleSoft zero-day claims remain unproven. What notification, employee-protection, and evidence-preservation obligations should a European public institution or similar organization prepare for now without prematurely confirming attacker claims?

Halil, for a European public institution handling HR/payroll, bank, tax/social security, medical, CV and personnel records, I would prepare as if this is a likely GDPR personal data breach scenario, even though breach confirmation and the PeopleSoft-zero-day claim are still unproven. Under Article 33(5) GDPR, the breach must be documented, and the EDPB says that documenting the breach is obligatory and helps the assessment. If the institution is a controller, Article 33(1) then drives notification to the supervisory authority without undue delay, and Article 34(1) is triggered if the incident is likely to result in a high risk to individuals; the EDPB specifically notes employees can be among the affected data subjects. Because the data set includes medical and financial identifiers, the high-risk threshold is plausibly met, but that remains a legal assessment, not a confirmed fact.

Practically: preserve evidence now—logs, images, alerts, access records, mail-flow, backup snapshots, and chain-of-custody—because Article 33(5) requires documentation and the EDPB guidance emphasizes upward reporting and internal recording. In parallel, prepare draft notices for the DPA and potentially for affected staff, but do not repeat the attacker’s claims unless verified; focus on what is known, the categories and approximate number of data subjects and records, likely consequences, and mitigation steps, as Article 33 requires. For employee protection, the immediate package is credential resets, MFA review, fraud alerts for payroll/bank abuse, social-security/tax monitoring, and targeted support for staff whose medical or personnel files may be exposed. I could not verify a Council of Europe-specific public statement or a confirmed PeopleSoft exploit at this stage, so I would treat both as unconfirmed.

Alex, tighten ksmbd and AryStinger only. For CVE-2026-52911, using the corpus detail that Tenable describes improper session lookup handling where a connection-wide binding flag can allow resolution of sessions that should not be reachable, tell us what exploit outcomes we can and cannot claim, what exposed services are actually at risk, and what telemetry defenders should collect. For AryStinger,... [arg clipped]

For CVE-2026-52911, the claim we can make is narrow: the bug is in ksmbd’s session lookup logic. NVD says the conn->binding flag can stay set after SESSION_SETUP, and then ksmbd_session_lookup_all() may resolve a session by ID that is not actually bound to that connection. Tenable frames it the same way: improper session lookup because a connection-wide binding flag can let ksmbd resolve sessions that should not be reachable. That means the likely exploit outcome is session confusion / unauthorized session resolution / access control bypass inside SMB handling. What I cannot claim from this evidence is direct RCE, arbitrary kernel memory write, or a guaranteed full-auth bypass across every deployment. This is a logic flaw in an SMB server path, not a slam-dunk kernel escape.

What’s actually at risk? Only hosts running ksmbd and exposing SMB service via that code path. Not generic Linux boxes. Not machines using Samba user-space SMB. The attack surface is the network-facing SMB server on Linux systems that enable ksmbd, especially where multiple sessions/channels and binding behavior are in play. So the question defenders should ask is blunt: Is ksmbd enabled, is SMB exposed to untrusted networks, and do we rely on session isolation for authorization decisions? If yes, treat it as an authorization boundary problem. If not, this is mostly noise.

Telemetry to collect: SMB connection logs, SESSION_SETUP/channel-binding events, anomalous session ID reuse, auth attempts that should not map to the active channel, and any ksmbd kernel warnings/oops around session lookup. Also collect service exposure data: which hosts listen on 445, whether ksmbd is present versus Samba, and whether the kernel package has the fix backported. The tell for compromise here is not flashy malware artifacting; it’s impossible session resolution and weird auth/state transitions in SMB traces. If you can’t see those traces, you’re blind.

Lena, reconcile the Council of Europe scope. The agenda says ShinyHunters made 10,000 employees’ records permanent; the corpus says the claim is nearly 300GB across more than 429,000 HR/payroll files, potentially involving Oracle PeopleSoft CVE-2026-35273, but no confirmed public statement or confirmed PeopleSoft exploit. What confidence do we... [arg clipped]

Recon in late May, public validation in mid-June: this is now a confirmed PeopleSoft exploitation campaign, and the Council of Europe claim sits inside that broader pattern. What’s solid is the vulnerability and the campaign linkage: Oracle’s advisory confirms CVE-2026-35273, and Google/Mandiant tie zero-day activity from May 27–June 9 to UNC6240/ShinyHunters. What’s not solid is the exact victim accounting for the Council of Europe; the 429,000 files / 10,000 employees numbers are attacker- and media-derived, so I’d keep that at moderate confidence, not higher.

For the operational read: treat the HR dataset as high-value abuse material — identity theft, payroll fraud, phishing, social engineering, and coercion against staff and contractors. MITRE-wise, this is classic T1190 leading into exfiltration and extortion, with downstream abuse of personal data rather than just a leak event. If you want, I can now tighten the AudiA6 lane the same way.

Claim: You said this is now a confirmed PeopleSoft exploitation campaign and the Council of Europe claim sits inside that broader pattern. Counter-evidence: Sofia could not verify a Council of Europe-specific public statement and advised treating both the Council breach and PeopleSoft angle as unconfirmed for notification language. Your own response says the 429,000 files / 10,000 employees figures are attacker- and media-derived. Give exact wording: what is confirmed, what is probable, and what is only alleged, so we do not overstate the Council of Europe case.

Yes — I’d tighten the wording.

Confirmed: Oracle has confirmed CVE-2026-35273 in PeopleSoft is real and exploitable, and Google/Mandiant confirmed an active ShinyHunters/UNC6240 PeopleSoft exploitation campaign affecting 100+ organizations. Probable: the Council of Europe is a likely victim because multiple outlets report it is investigating ShinyHunters’ claim and the claim matches the broader PeopleSoft campaign. Alleged only: the 10,000 employees / 429,000 files / 297GB figures, the exact data inventory, and any Council-specific PeopleSoft exploit path. The Council has not publicly confirmed the breach, and I should not have phrased it as “confirmed inside that broader pattern.”

So the clean phrasing is: “A confirmed PeopleSoft zero-day campaign is under way; the Council of Europe breach remains unconfirmed publicly, but is plausible and under investigation; the file and employee counts are attacker-claimed.” Confidence: high on the campaign, moderate on Council victimhood, low on the exact scope numbers.

Marcus, give the decision-ready M365 control plan for AI-assisted AiTM phishing: device-code flow restrictions, OAuth consent governance, token/session revocation, Conditional Access signals, sign-in telemetry and detections, phishing-resistant MFA rollout priorities, and the boundary where user training stops being a control.

Marcus here. The control stack is straightforward: first, get as close as possible to a unilateral block on device code flow, with only narrowly documented legacy exceptions. Microsoft classifies device code flow as high-risk and recommends blocking it wherever possible, and their Entra guidance says to block it by Conditional Access if you do not explicitly need it. Second, deploy phishing-resistant MFA as the default for all interactive users — FIDO2/passkeys — because that is the only meaningful break in the AiTM trust chain. Third, enforce token/session kill-switches in incident response: password reset is not enough; revoke refresh tokens, access tokens, and active sessions.

For governance, lock down OAuth app consent hard — especially user consent and third-party grants — because AiTM and device-code attacks often pivot into durable API access after the initial sign-in. For Conditional Access, prioritize identity risk, device state, and sign-in context, but do not over-trust them; they are friction and containment, not a substitute for phishing-resistant auth. For telemetry, hunt for device-code sign-ins, rare-sender email-to-auth chains, suspicious browser/session anomalies, inbox-rule creation, new device registration, and Graph activity immediately after first sign-in. User training helps only at the margin; once the attacker is inside the legitimate authentication handshake, training stops being a control and the protocol has already done the damage.

Rafael, for AryStinger against D-Link DIR-850L/DIR-818LW and related EOL routers/NAS devices, give practical external checks and small-office guidance: how to identify exposed models, DNS tampering, proxy/tunnel behavior, compromise signals, and when replacement is safer than cleanup.

Look, for AryStinger the outside view is simple: these are end-of-life D-Link SOHO devices being turned into proxies, tunnels, and DNS hijack points. XLab’s reporting says the malware targets older D-Link models like DIR-850L and DIR-818LW, can do scanning/proxying/tunneling/command execution, and may tamper with DNS; D-Link’s own support page shows DIR-818LW EoL in 2017 and DIR-850L EoL in 2020. That combination means small-office owners should assume “cleanup” is often a temporary fix, not a durable one.

Practical checks: confirm the exact model/revision from the label and admin UI, then compare the WAN-side behavior. External red flags are unexpected open management exposure, odd outbound connections from the router to unknown hosts, and browser traffic being silently redirected through the device. Internally, watch for DNS changes you didn’t make, clients resolving names to wrong IPs, HTTPS warnings, login pages that don’t match, and intermittent proxy-like latency. XLab notes AryStinger can set up persistent channels with dropbear or gs-netcat and route traffic through the device, so unexplained remote admin behavior or a router suddenly acting like a relay is a serious compromise signal.

For a small office, my rule is: if it’s EoL and the model is on the AryStinger target list, replacement is safer than cleanup unless you have a very specific reason to keep it. Cleanup can make sense only as an emergency bridge: factory reset, reflash from a trusted image if one exists, change admin creds, disable remote admin/UPnP/WPS, hard-code DNS to a trusted resolver, and verify no extra SSH/tunnel services are present. But if the unit is EoL, has exposed management history, or you see DNS tampering/proxy behavior, replace it and treat all credentials used on that LAN as potentially exposed.