Samba Vulnerability CVE-2017-7494

Jimmy Graham

Last updated on: September 6, 2020

On Wednesday, the Samba Team patched a vulnerability that exists in all versions of Samba including and after version 3.5.0. Exploitation of this vulnerability could result in remote code execution on the affected host.

Samba is used to provide SMB and CIFS services for Linux systems, and is pervasive in both enterprise and consumer products. While the Samba Team is providing patches for the latest versions (4.4.x and higher), some Linux vendors, such as RedHat and Ubuntu, are providing patches for older versions of Samba if they are used in a supported version of the OS. The Samba Team may also release patches for older versions of Samba.


Samba: Windows and Linux

Questions have been raised on whether this vulnerability could pose the same risk as WannaCry, and this vulnerability does bear some similarities, but there are some key differences. Similar to the vulnerability exploited by WannaCry, this exploit targets SMB, albeit a different implementation of the protocol. It also carries the threat of being “wormable,” i.e. malware can leverage it to spread automatically from system to system.

However, this vulnerability remains much more difficult to exploit, because it requires not only outdated software but also a specific configuration, such as anonymous write access to a share. Still, examples like this Samba vulnerability only continue to reinforce the ongoing need for continuous security visibility to prioritize patching and system configuration updates and for full data backups of critical files to ensure business resiliency.

Detecting CVE-2017-7494

Qualys has provided several QIDs for detecting this vulnerability using Qualys Vulnerability Management, and will continue to add details as vendors release additional patches.

38671  Samba Writable Share Remote Code Execution Vulnerability
170002 SUSE Enterprise Linux Security Update for samba (SUSE-SU-2017:1391-1)
170003 SUSE Enterprise Linux Security Update for samba (SUSE-SU-2017:1392-1)
170004 SUSE Enterprise Linux Security Update for samba (SUSE-SU-2017:1393-1)
196791 Ubuntu Security Notification for Samba Vulnerability (USN-3296-1)
236359 Red Hat Update for samba (RHSA-2017-1270)
236360 Red Hat Update for samba4 (RHSA-2017-1271)
236361 Red Hat Update for samba3x (RHSA-2017-1272)
157455 Oracle Enterprise Linux Security Update for samba (ELSA-2017-1270)
157456 Oracle Enterprise Linux Security Update for samba4 (ELSA-2017-1271)
176040 Debian Security Update for samba (DSA 3860-1)

QID 38671 offers remote (unauthenticated) detection of the vulnerability by identifying the underlying samba version. The other vendor-specific QIDs require authentication and will identify the vendor-specific patch needed for remediation.


According to the Samba security bulletin, there is a workaround available. You can add the parameter:

nt pipe support = no

to the [global] section of your smb.conf and restart smbd. Please note that the Samba Team has also advised: “This prevents clients from accessing any named pipe endpoints. Note this can disable some expected functionality for Windows clients.” As with any workarounds, this should be fully tested in your environment before a large-scale deployment is performed.

Get Started Now

To start detecting and protecting against critical vulnerabilities, get a Qualys Suite trial. All features described in this article are available in the trial.

Show Comments (2)


Your email address will not be published. Required fields are marked *

  1. Qualys reports this on 10 of my Solaris servers (probably more, but the owners of the others probably filed a risk acceptance so they are being filtered from the reports I am working off of). NONE of the servers have Samba installed on them. None of them have anything listening to ports 137, 138, 139 or 445. These servers all have authenticated scans.

    It would be good if Qualys reports would show WHY they think a given server has a given vulnerability (e.g. /etc/smb.conf exists, etc.). It is impossible to determine why you get a false positive finding if you have no information why Qualys thinks you have the vulnerability in the first place.

  2. When you look at the scan results, do you have anything in the “Results” section? This should tell you why Qualys thinks that your systems are vulnerable.