Our website publishes news, press releases, opinion and advertorials on various financial organizations, products and services which are commissioned from various Companies, Organizations, PR agencies, Bloggers etc. These commissioned articles are commercial in nature. This is not to be considered as financial advice and should be considered only for information purposes. It does not reflect the views or opinion of our website and is not to be considered an endorsement or a recommendation. We cannot guarantee the accuracy or applicability of any information provided with respect to your individual or personal circumstances. Please seek Professional advice from a qualified professional before making any financial decisions. We link to various third-party websites, affiliate sales networks, and to our advertising partners websites. When you view or click on certain links available on our articles, our partners may compensate us for displaying the content to you or make a purchase or fill a form. This will not incur any additional charges to you. To make things simpler for you to identity or distinguish advertised or sponsored articles or links, you may consider all articles or links hosted on our site as a commercial article placement. We will not be responsible for any loss you may suffer as a result of any omission or inaccuracy on the website.

One Year on from Log4j Vulnerability: Have Lessons been Learned?  

by Staff GBAF Publications Ltd
0 comment



On the anniversary of the Log4j vulnerability disclosure, Check Point Software looks back on one of the biggest security shake ups in recent years 


On December 9th, 2021, an acute remote code execution (RCE) vulnerability was reported in the Apache logging package Log4j versions 2.14.1 and below (CVE-2021-44228). Apache Log4j is the most popular java logging library, used by companies worldwide. It is embedded in almost every internet service or application we are familiar with, including Twitter, Amazon, Microsoft, Minecraft and many more.  


At the time, Check Point Research witnessed a pandemic-like spread of attacks, recording almost 200,000 attempts to exploit the vulnerability within 24 hours of the initial disclosure. Within a week, hackers, including Chinese-backed state groups, had launched more than 1.2m attacks.  

As we moved through 2022, it became clear that cybercriminals would continue to exploit the vulnerability. In February, Iranian state-sponsored cyber criminals used the flaw to break into a US government network, illegally mine cryptocurrency, steal credentials and change passwords. Then in October a group associated with the Chinese government used the vulnerability to launch attacks on various targets including a Middle Eastern country and electronics manufacturer. 

The Log4j vulnerability continues to plague businesses today. It consistently ranks first or second in Check Point Research’s threat reports, impacting 41% of organizations globally as of October 2022. 

Deryck Mitchelson, Field CISO at Check Point said: “Log4j was a game changer due to how easy it was to compromise, with a single line of code and millions of services and devices around the world that were vulnerable. It is estimated that 1 in 10 corporate servers were exposed. I think it was a wake-up call for an industry that was relatively blasé around the management of open-source libraries and their use therein and were perhaps too trusting of their vendors and the supply chain’s vulnerability management capabilities.  

“When managing services as an operational C-Suite leader, vulnerability management was critical to my business continuity, particularly in healthcare. However interestingly, not all vendors were vulnerable to Log4j, and while some vendors stepped up and provided patches very quickly, others were days and weeks behind. It does make you think, does your vendor take your security as seriously as you do?” 

What’s next for Log4j? 

The Log4j vulnerability was a wakeup call for every organization, and it was a time that many security professionals would like to forget. However, with widespread use of Log4j and an ever-growing network of internal and third-party servers to patch, the vulnerability will be felt for a long time.  

Muhammad Yahya Patel, Security Engineer at Check Point added: “Log4j acted as a stark reminder that security needs to underpin all applications and services. Time is of the essence in these situations, and it forced many companies to review their vulnerability patch policies; any delay could cost them significantly.  

“We need to learn from these zero-day vulnerabilities to avoid the next log4j incident from happening. Don’t trust open-source software without doing your own checks. It is good practice to take open-source software and put your bespoke security controls around it. Build software code securely right from the start to avoid any surprises in the future, and make sure any changes to the software pass through your security checks.”