Kubernetes published CVE-2026-3865 for the CSI Driver for SMB. This is a storage safety issue: in affected versions, a user with enough cluster permission to create SMB-backed PersistentVolumes could cause the driver to operate outside the intended managed directory during deletion or cleanup. The practical risk is unintended modification or deletion of directories on the SMB server.
The fix is available. Kubernetes lists CSI Driver for SMB versions before v1.20.1 as affected and v1.20.1 or newer as fixed. The official CVSS rating is medium, but the operational impact can be serious on clusters where SMB shares back application data, customer files, or shared hosting workloads.
Who is affected
- Kubernetes clusters using the SMB CSI driver.
- Clusters where users or automation can create PersistentVolumes that reference that driver.
- Environments where SMB exports contain more writable data than the driver should manage.
- Windows or mixed Linux/Windows Kubernetes environments that rely on SMB-backed storage.
- Hosting, lab, or customer environments where storage privileges have grown too broad over time.
What to patch
Update the CSI Driver for SMB to v1.20.1 or newer. Use the deployment method that originally installed the driver, such as your Helm release, GitOps repository, operator, or managed cluster add-on process. Do not manually edit production manifests unless that is already your normal change-control path.
Before the update, take or verify backups of SMB-hosted data that matters. This issue is about unintended storage operations, so the rollback plan should include storage restore confidence, not only Kubernetes manifest rollback.
Safe admin checklist
- Inventory clusters that use the SMB CSI driver.
- Confirm the installed driver version and compare it with the fixed release.
- Review who can create or modify PersistentVolumes and storage-related automation.
- Confirm SMB exports are scoped to the minimum writable directories needed by the driver.
- Back up or snapshot important SMB-hosted data before changing the driver.
- Update the driver through the normal cluster release process.
- Watch the CSI controller and node pods until they are healthy after rollout.
- Test normal mount, unmount, create, and cleanup behavior with a non-production workload.
- Review storage logs for unexpected directory changes around recent volume cleanup events.
RBAC and tenant isolation
The main permission boundary to review is PersistentVolume creation. In most clusters, untrusted tenants should not be able to create arbitrary PersistentVolumes that reference external storage drivers. Keep that permission limited to trusted platform administrators or controlled automation.
For multi-tenant clusters, also review namespace policies, GitOps permissions, admission controls, and any self-service storage workflow that can create SMB-backed storage. The safest pattern is a narrow storage class and approved provisioning path, not broad manual volume creation by application teams.
Cluster maintenance guidance
- Backups first: confirm SMB share backups before the driver rollout.
- Change window: update during a maintenance window if important workloads use SMB volumes.
- Drain carefully: if your process requires node restarts or driver pod movement, account for workloads with mounted SMB volumes.
- GitOps users: update the pinned driver version in source control so the fixed version does not get reverted.
- Managed clusters: check whether the SMB driver is installed as an add-on or through your own manifests before assuming the cloud provider handles it.
What to review after patching
- SMB CSI controller and node pod health.
- PersistentVolumes that use SMB-backed storage.
- Recent storage cleanup or deletion events.
- SMB server logs for unexpected file or directory operations.
- Application logs for missing files, failed mounts, or permission errors.
- Backup job status for any SMB-hosted application data.
Customer communication note
If customers use SMB-backed Kubernetes storage, tell them this is a driver update and storage-permission review, not a general Kubernetes control-plane compromise. The key message is simple: patch the SMB CSI driver, restrict who can create storage volumes, verify backups, and review shared storage for unexpected changes.