Support 
Second Log4j vulnerability discovered, patch already released
After the disastrous Log4j vulnerability disrupted the online world, another vulnerability surfaced online.
The Log4j vulnerability has become one of the largest security issues we’ve seen in recent times. With the level of attention now being focused on this problem both by attackers and defenders, it’s likely that we’ll see further information and possible vulnerabilities.
A second vulnerability involving Apache Log4j was found on Tuesday after cybersecurity experts spent days attempting to patch or mitigate CVE-2021-44228. The description of the new vulnerability, CVE 2021-45046, says the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was “incomplete in certain non-default configurations.”
“This could allow attackers… to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack,” the CVE description says.
In the aftermath of the immediate response, companies should carefully consider how they can manage this type of risk strategically. Improving detection of software versions and using software supply chain security tools are good examples of defense-in-depth security measures that can provide short-term mitigations. Using these tools gives IT departments the time needed to coordinate comprehensive patching and testing of their software systems in a safe and controlled fashion.
It turns out that the first patch was ‘incomplete’, and therefore, another Apache Log4j version has been released. Second Apache Log4j Bug Found Reportedly, Apache has released another major update for its Log4j code library addressing a serious bug. Identified as CVE-2021-45046, this vulnerability appeared following an incomplete patch of the (now infamous) Log4Shell flaw (CVE-2021-44228). As stated in the vulnerability description, It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.