Alerts and Advisories

Latest Alert - December 10, 2021

Updated: December 15, 2021

ALERT :  New zero-day exploit for Log4j Java library CVE-2021-44228 Exploited in the Wild

Risk: HIGH

Severity: HIGH               

New zero-day exploit for Log4j Java library CVE-2021-44228 Exploited in the Wild

WTS is strongly recommending that all administrators of systems or applications that are using any version of Apache Log4j take immediate action to review the installation against this advisory and references, and take any action as necessary to address this vulnerability.

Vendor: Apache

Description: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

*Note: It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. log4j 2.16.0 has been released to fix this (CVE-2021-45046)

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all versions from 2.0-beta9 to 2.14.1





Patch Log4j to version 2.16.0 or greater


If your version of Log4j is at 2.10.0 or newer:

Originally suggested remediation steps are no longer valid:

  • Set 'formatMsgNoLookups=true'

If your version of Log4j is older than 2.10.0 then you can do either of:

  • Modify every logging pattern layout to say '%m\{nolookups}' instead of '%m' in your logging config files
  • Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior.


Updated remediation steps:

  • Remove the JndiLookup class from the classpath by running the following command.
    • “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”
  • This mitigation measure has been expanded to include all versions of Log4j < 2.16.0.

Latest Advisory - February 2, 2022

SAMBA Vulnerability

Security Operations Advisory

                                Cyber Alerts & Notifications

Risk: Medium

Severity: HIGH     


WTS is strongly recommending that all administrators of any systems using the SAMBA VFS module “vfs_fruit”  take immediate action to implement the required patches or mitigations to address this vulnerability.

Vendor: SAMBA


All versions of SAMBA prior to 4.13.17 are vulnerable to an out-of-bounds heap read write vulnerability that allows remote attackers to execute arbitrary code as root on affected Samba installations that use the VFS module vfs_fruit. The specific flaw exists within the parsing of EA metadata when opening files in smbd. Access as a user that has write access to a file's extended attributes is required to exploit this vulnerability. Note that this could be a guest or unauthenticated user if such users are allowed write access to file extended attributes.

Severity: High

Base CVSS Score: 9.9

Versions Affected:

  • All versions of Samba prior to 4.13.17



Upgrade Samba to 4.13.17, 4.14.12, and 4.15.5 and apply patches

vfs_fruit can be disabled as a temporary measure if it is not possible to update to the latest Samba release: 

  • To disable vfs_fruit, remove "fruit" from “vfs objects” lines in Samba configuration files. 
  • Please note: by disabling the vfs_fruit module, some macOS file metadata will become inaccessible. 

*Note: This mitigation may have impact to services if your environment makes use of vfs_fruit



Published on  and maintained in Cascade.