CVE-2026-1933: Samba Privilege Escalation Vulnerability

CVE-2026-1933 Overview

CVE-2026-1933 is an access control flaw [CWE-284] in Samba's handling of NTFS-style reparse points. Samba fails to apply Server Message Block (SMB) layer access checks when authenticated users manipulate reparse point metadata on shares configured with read only = yes. Users holding underlying filesystem write permissions can create or delete reparse points through SMB operations, even when the share is explicitly marked read-only. This allows conversion of files into symbolic links or other reparse point types, altering SMB-visible file behavior and bypassing the intended share-level restrictions.

Critical Impact
Authenticated users can modify reparse point metadata on read-only Samba shares, enabling them to convert files into symbolic links and alter how exported content is presented to SMB clients.

Affected Products

Samba (NTFS-style reparse point handling)
Samba shares configured with read only = yes
Linux distributions packaging affected Samba versions, including Red Hat Enterprise Linux

Discovery Timeline

2026-05-27 - CVE-2026-1933 published to the National Vulnerability Database
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-1933

Vulnerability Analysis

The vulnerability resides in Samba's SMB-layer enforcement logic for reparse point operations. Samba supports NTFS-style reparse points to interoperate with Windows clients that expect symbolic link and mount point semantics. When a share is exported with read only = yes, Samba is expected to reject all client-initiated write operations against that share, regardless of the underlying POSIX permissions on the host filesystem.

The flaw is exploitable over the network by an authenticated SMB user. No user interaction is required, and attack complexity is low. The impact targets integrity and availability of files exposed through the share, because reparse point manipulation can redirect file access to other paths or convert regular files into symlinks. Confidentiality is not directly impacted by the flaw itself.

This falls under the Improper Access Control category. Administrators relying on the read only = yes directive as a defense-in-depth control should treat that assumption as broken until patched.

Root Cause

Samba's reparse point code path does not invoke the SMB-layer access checks that normally gate write operations on read-only exports. Instead, the operation proceeds based on the underlying filesystem permissions of the authenticated user. When a user has write permission on the backing filesystem, Samba allows the reparse point create or delete request even though the share configuration forbids writes.

Attack Vector

An authenticated SMB client connects to a Samba share configured with read only = yes. The client issues SMB requests that create or remove reparse point metadata on files within that share. Because the access check is missing at the SMB layer, the server performs the operation when underlying POSIX permissions permit it. The attacker can then convert a regular file into a symbolic link, change the target of an existing reparse point, or remove reparse point attributes to alter how subsequent SMB clients resolve the file.

No verified public exploit code is available. Refer to the Samba Bug #15992 and Red Hat CVE-2026-1933 Advisory for upstream technical details.

Detection Methods for CVE-2026-1933

Indicators of Compromise

Unexpected symbolic links or reparse points appearing on shares configured with read only = yes
SMB audit log entries showing FSCTL_SET_REPARSE_POINT or FSCTL_DELETE_REPARSE_POINT operations against read-only exports
Files on read-only shares whose contents resolve to paths outside the original share root
Authenticated SMB sessions issuing write-class FSCTL operations despite share configuration prohibiting writes

Detection Strategies

Enable Samba full_audit VFS module on read-only shares to log create, unlink, and FSCTL operations per user
Compare file inventories on read-only exports against a known-good baseline to detect new symlinks or reparse points
Correlate SMB session telemetry with filesystem change events on the backing storage to flag writes to read-only paths
Hunt for authenticated user sessions that issue reparse-related IOCTLs against shares marked read-only

Monitoring Recommendations

Forward Samba audit logs and SMB session metadata to a centralized SIEM for correlation against share configuration state
Alert on any successful reparse point create or delete operation targeting a path that resolves to a read only = yes share
Monitor for sudden increases in symlink count on file servers exporting Samba shares

How to Mitigate CVE-2026-1933

Immediate Actions Required

Inventory all Samba servers and identify shares configured with read only = yes that rely on Samba to enforce write restrictions
Apply the Samba security update from your distribution as soon as it becomes available, tracking the Red Hat CVE-2026-1933 Advisory for package releases
Restrict the set of authenticated users who hold write permissions on the underlying filesystem of read-only exports
Audit existing read-only shares for unexpected reparse points or symbolic links created before patching

Patch Information

A fixed Samba release is tracked in Samba Bug #15992 and the corresponding Red Hat Bug #2447317. Distribution maintainers will ship updated samba packages. Apply the vendor-provided update on all affected file servers and restart the smbd service after upgrading.

Workarounds

Set restrictive POSIX permissions on the backing filesystem so that SMB users do not hold write access, removing the precondition for exploitation
Disable reparse point support on affected shares by setting smb3 unix extensions = no and avoiding NTFS reparse point emulation options where feasible
Limit access to read-only shares to users whose underlying filesystem permissions are also read-only
Use valid users and invalid users directives in smb.conf to constrain which principals can connect to sensitive read-only exports

bash

# Configuration example: harden a read-only Samba export
[public_readonly]
    path = /srv/samba/public
    read only = yes
    # Defense-in-depth: ensure underlying filesystem is not writable by SMB users
    # chown root:root /srv/samba/public && chmod 0755 /srv/samba/public
    valid users = @readers
    smb3 unix extensions = no
    vfs objects = full_audit
    full_audit:success = pwrite write rename unlink mkdir rmdir
    full_audit:failure = none
    full_audit:facility = local5
    full_audit:priority = notice