On December 9, 2021, a critical vulnerability in the popular Log4j Java logging library was disclosed and nicknamed Log4Shell. The vulnerability is tracked as CVE-2021-44228 and is a remote code execution vulnerability that can give an attacker full control of any impacted system. In this blog post, we will: We will also look at how to leverage Datadog to protect your infrastructure and applications.

This is the first part of a blog post series about bytecode transformations on Android. In this part we’ll cover different approaches to bytecode manipulation in Java as well as how to make it work with Android and the Android Gradle plugin. In the next two parts we’ll dive into the actual bytecode, bytecode instructions and how we can modify the bytecode and inject our own instructions, using Room as an example.

By now, you’re probably assessing your level of exposure — or are in the middle of remediating — the recently disclosed vulnerability known as Log4Shell. We recently introduced a native integration with Snyk, a leading provider of developer security solutions, to help you address zero-day vulnerabilities. Once enabled, Snyk scans your code and its dependencies, and alerts you about security vulnerabilities, including Log4j. All current versions of Log4j 2 up to 2.14.1 are vulnerable.

This post will be updated over the next several days. Recently, a Remote Code Execution vulnerability was discovered in the Apache Log4J library. This vulnerability, which is tracked in CVE-2021-44228, dubbed Log4Shell, allows attackers to execute arbitrary code on affected systems. While HAProxy Enterprise, HAProxy ALOHA, and other products within the HAProxy Technologies portfolio are not impacted by this (they do not use the Log4J library at all), you can use them to block the attack.

The recent Apache Log4j vulnerability CVE-2021-44228 dubbed Log4Shell is a big deal. By now there is no shortage of blogs, other write-ups, and analysis about why this vulnerability is an urgent issue and why there is a very good chance it applies to your environment. Here are some of the articles that dive into the gory details on this CVE.

Last Thursday, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.

Over the last few days, there have been a tremendous amount of posts about the Log4j 2 vulnerability, with Wired going so far as claiming that, “the internet is on fire.” Tl;dr: LogDNA is not exposed to risk from the Log4Shell vulnerability in Log4j 2 at this time. If that’s all you came for, you can stop reading here. If you want to learn more about the vulnerability and how LogDNA protects you from risks like these, grab a cup of coffee and read on.