Recently, a critical out-of-bounds vulnerability, assigned to CVE-2021-44142, was disclosed in Samba versions prior to 4.13.17. The Samba vulnerability carries a critical CVSS of 9.9 and allows attackers to remotely execute code on machines running a Samba server with a vulnerable configuration. The vulnerability was disclosed as part of the Pwn2Own Austin competition where researchers are challenged to exploit widely-used software and devices with unknown vulnerabilities.

Last week, a critical vulnerability identified as CVE-2022-0185 was disclosed, affecting Linux kernel versions 5.1 to 5.16.1. The security vulnerability is an integer underflow in the Filesystem Context module that allows a local attacker to run arbitrary code in the context of the kernel, thus leading to privilege escalation, container environment escape, or denial of service.

Modern software projects are mostly composed of open source code. The question of who really controls this code, and is responsible for detecting and fixing software supply chain security issues, became a significant source of concern after the discovery of the Log4Shell vulnerability.

Very recently, the JFrog security research team has disclosed an issue in the H2 database console which was issued a critical CVE – CVE-2021-42392. This issue has the same root cause as the infamous Log4Shell vulnerability in Apache Log4j (JNDI remote class loading). H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk.

Dealing with hundreds of security alerts on a daily basis is a challenge. Especially when many are false positives that waste our time and all take up too much of our valuable time to sift through. Let me tell you how our security team fixed this, as we built security around the JFrog products. First, let me tell you a little bit about our team.

The high risk associated with newly discovered vulnerabilities in the highly popular Apache Log4j library – CVE-2021-44228 (also known as Log4Shell) and CVE-2021-45046 – has led to a security frenzy of unusual scale and urgency. Developers and security teams are pressed to investigate the impact of Log4j vulnerabilities on their software, revealing multiple technical challenges in the process.

The discovery of the Log4Shell vulnerability in the ubiquitous Apache Log4j package is a singular event in terms of both its impact and severity. Over 1 million attack attempts exploiting the Log4Shell vulnerability were detected within days after it was exposed, and it may take years before we see its full impact.

At many organizations, the surprise discovery that the widely used Apache log4j open source software has harbored a longtime critical vulnerability was as if Scrooge and the Grinch had teamed up for the biggest holiday heist of all. Incident response teams across the globe have scrambled to remediate thousands, if not millions of applications. “For cybercriminals this is Christmas come early,” explained Theresa Payton, former White House CIO and current CEO of Fortalice Solutions.