Critical Java Log4j Vulnerability

What can go wrong with a tool that just logs messages to a text-based file? Nothing right? That is what virtually every organization on the planet must have been thinking because they all use log4j. Of course, the reality is proving us all wrong. Suddenly on December 11, 2021, we were all exposed to the Log4J vulnerability and our organization could have been (might have been?) breached!

Log4j Vulnerability Explained

Log4j is an extremely popular and heavily used open-source Java library that can be used for unauthenticated remote-code execution, making CVE-2021-44228 and CVE-2021-45046 critical vulnerabilities that you must pay attention to.

In other words: if your software uses this library, then there is a good chance that anyone can gain full remote control of your servers and data.

The log4j vulnerability is among the worst we’ve seen in the last 5 years, in part because the vulnerability itself is so severe and so easy to trigger. Adding to the severity, this vulnerable library is among the most popular and widely deployed open-source Java libraries on the planet.

Differences between log4j vulnerability versions?

The Apache Struts disaster from 2017 (CVE-2017-5638) was a large part of why we launched our startup ( to help companies protect themselves from known-vulnerabilities in open source libraries exactly like these.

This time it’s even worse. Globally, everyone must now urgently scramble to upgrade all applicable software to use Java library log4j version at least 2.15.0 (which was published today). Companies that for whatever reason fail to execute on this upgrade will likely be attacked and exploited within the next few days – assuming they are not already under attack.

We cannot stress how urgent it is for administrators of Java systems to succeed in rolling out this upgrade. Patch this Critical log4j vulnerability in Java CVE-2021-44228 immediately.

How can you check for vulnerabilities?

There is an easy way to check any server for the log4j vulnerability. At the root of your file system, using an administrator account, download and run our free Log4J-Detector tool:

This command can take several hours to complete. Any occurrence of “_VULNERABLE_” in this command’s output indicates with high probability that you are vulnerable to this severe software exploit.

monitoring - Log4j vulnerability

Further reading:

Still interested in learning more about it? Check the video on securing log4j instantly with run-time protection.

MergeBase can help you patch your vulnerable systems to eliminate this bug and help you in situations where patching is not possible. We have a patented cyber-security technique for exactly this situation.

You can try MergeBase to see if you are vulnerable, or download our free tool to detect vulnerable log4j versions on any of your machines and in any application.

API Security – Preventing an API Breach

APIs are everywhere, and their security is becoming challenging.

It goes without saying that APIs are deployed everywhere. For instance a website click quickly initiates a dozen REST calls directly from your browser and another dozen behind the scenes. Software engineers, like you, integrate with APIs more and more to develop new features and enhancements.

Gartner is seeing explosive growth of APIs, and estimates that by 2025 less than 50% of enterprise APIs will be managed; the companies just don’t have the capacity to do it.

Are you able to secure your company’s API sprawl? 

As software engineers, we can divide APIs into two kinds: those we build & maintain ourselves (the homegrown); and those we consume (the 3rd-party externals). In this webinar, TeejLab Founder & CEO Dr. Baljeet Malhotra and MergeBase CTO Julius Musseau talked about API risks, API governance, and best practices for software engineers building and consuming APIs. 

They covered the following topics:

  • Why it’s essential to think about risk when building APIs
  • How to protect your company from the potential damage caused by a compromised API
  • API Security best practices and standards

Do you want to know more about API Security?

OWASP Top Ten #1 Worst Problem: Poor Access Control

As you are probably well aware, access control is the biggest problem in Application Security. OWASP research in 2021 pointed this out, as did Verizon’s well-respected 2022 DIBR report.

Why is this important? The same report points out that web application attacks are the second most frequent attack pattern after DoS. So, if your organization has not been hit in this area, chances are you will be. Get ready!

Access control: the good, the bad and the ugly

Be warned, there are no quick fixes! No magical tools that resolve this for you. Developers’ first response is mostly to ignore access control as an issue and to make matters worse, application frameworks rarely provide details about its functionality since it’s not particularly generalizable.

But don’t despair! Approaches to resolve this are mature and well developed. Join our webinar with Application Security experts Jim, Erwin and Julius to learn about guidelines, patterns, as well as pitfalls to avoid.

Watch this webinar Jim Manico (OWASP Top Ten contributor), Erwin Geirnaert (Co-founder & Chief Hacking Officer at Shift Left Security) and Julius Musseau to learn more.

What you will learn about access control?

They covered everything you need to know when implementing access control in your application. They also show you how to avoid common mistakes and pitfalls so that you can build a secure app without spending too much time on it.

Recording was made on June 20th.

Is your application safe?

How To Avoid Catastrophic Cryptographic Failures In Your Apps

Danger, Cryptography Ahead!

The latest OWASP Top 10 ranks “Cryptographic Failures” as the 2nd worst security problem currently facing software engineers today. In this webinar AppSec experts Jim Manico (OWASP Top Ten contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will discuss why this is the case, and offer the best practices and resources for developers trying to avoid such failures in their own systems.

As the very recent (and very serious) CVE-2022-21449 shows – this problem never goes away! It’s hard for software practitioners to stay up-to-date, because new critical cryptographic weaknesses and configuration disasters are discovered and disseminated every year, and seemingly tiny benign mistakes can be game over.

Answers to the following questions are critical in avoiding cyber failure:

  • Should you use Argon2 or bcrypt?
  • When should you salt things?
  • What parameters should you feed into your TLS endpoints?
  • Anything to be careful about with JWT?

Watch the video of our webinar on How To Avoid Cryptographic Failures from June 3rd, 2022

Want to know more?

OWASP ASVS: your balanced appsec diet

Build strength, fitness and peace of mind!

In this webinar, application security heavyweights Jim Manico (OWASP Top Ten contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will talk about the best thing that can happen to you if your application security team is overwhelmed, overworked and over-worried.


The OWASP Application Security Verification Standard (ASVS) is a balanced way for organizations to approach application security and align it with their organizations’ risk appetite and resources.

ASVS is a set of best practices that can be used by any organization, large or small, to assess the security of their applications. It takes a proactive, risk-based approach to secure applications and is designed to be flexible enough for you to customize it for your specific needs.

Are you thinking of establishing a balanced appsec process, or are you looking at fine-tuning your existing process? Watch Jim, Farshad and Julius in this webinar to hear about:

  • The First application security standard by developers for developers!
  • That defines three risk levels with 200+ controls.
  • And gives you a similar value to ISO 27034 for a fraction of the hassle
recording webinar on OWASP ASVS from May 11, 2022

Did you like this webinar? Don’t miss the next ones!

Secure your spot today!

I was asked: Are your application secure?

How paranoid about application security is enough?

I was asked to secure my company’s software application at a previous job. I dutifully headed off to do some online research. Five hours of googling later, I realized that the concept of an “application secure” was in fact, ephemeral. A growing unease started to grow inside me. Is anything, anywhere safe?

Am I the only one that feels this way? Am I going crazy? I dig even deeper down the rabbit hole. Apparently, psychology has been studying this phenomenon for the past few decades, and while a small corner of my mind feels relieved to find out that I am not alone, another louder part of my mind worries about the fact that psychology is looking at it… is it really that prevalent? 

One quote in a Frontiers paper sticks in my craw: “On balance, the weight of the evidence points to an excessive level of fear regarding information technology within society, in that the level of fear seems to be out of proportion to the actual risks.” This can’t be true, every month brings out reports of more vulnerabilities, more data breaches, more people getting defrauded, of more people getting their identities stolen.

Not so confident of academia’s understanding of the ‘real’ world, I do a quick Google search using the words “security” &  “paranoia”. Immediately I find my feelings echoed on Reddit with the following post*: “So is it just me or the more you learn about cyber security, the more paranoid you are about every little action you do?” The answer provided does not make me feel better: “You learn how to accept risk. The only completely secure computer is powered off at the bottom of a line shaft broken into inoperable pieces.”

So, which is it? Are my “fears out of proportion”, or is security only achievable at the bottom of an abandoned mining shaft?

Is anything, anywhere safe?

Only a small portion of a single course (of 40 total!) from my Computer Science degree actually addressed security in a formal way. It was in this course, Computer Networking, where I met Alice & Bob innocently trying to communicate unaware of the villainous Charlie sneaking around in the middle hacking into their messages. 

There I learned how to use WireShark and started sniffing packets at the local coffee shop. This sharpened my desire to pay attention in class and I diligently studied the “known knowns” of the industry, cognitively arming myself to move around with more environmental awareness in the digital space. 

I started checking for security vulnerabilities on my own sensitive applications with 2FA (2-factor authentication) and preach this as the way to all I know because it is surely infallible. Right? Wrong. 

I read that the 2FA SMS and OTP implementations such as Google Authenticator are often breached* by middling Charlie, and my security blanket once again becomes damp. (FIDO implementations such as Yubikeys are not vulnerable to this).

My research reveals that it is impossible to really anticipate all of the attack vectors, all of the potentially penetrable planes of any process. The monitoring systems that I had once trusted to keep my company’s system safe all of a sudden become the opposite of that*. Facebook Careers can be hacked using Word documents*.  Even harmless wee CSS becomes an affordance upon which one can inject malicious js scripts*.

What really feeds my anxiety beast, though, is the fact that there are still so many dangers lurking in the shadows that I haven’t even conceived of yet. The SolarWinds attack was so effective because internal build processes behind firewalls were presumed safe. Very few ever imagined CSS could be a target either. 

As a digital nomad, it reminds me of when I land in a new city, when I am still unaware of the “bad” areas, of its particular flavour of crime. Are pickpockets rampant here; are the kebabs actually chicken? I remember that time a random woman threw a cat at me, and how her kid ran off with my bag as I was shaking it off. I had never really anticipated getting ripped off in that particular way; had never conceived of it being something to be careful of.

What gave me hope, the only spark of light in all of this darkness was the fact that my boss had decided to take security seriously. She had convinced the money people that even though the process of securing a system can be both time & money consuming in the short run, it ends up being both time & cost-reducing in the long run. She explained how with practice we could learn to anticipate obvious attacks and with creativity, we could start anticipating some not-so-obvious attacks.

What did I do after I embraced my paranoia and decided to build secure applications?

I came across Jack Rhysider’s list of 20 things he learned as a network security engineer. Reading it I see a pattern of measured precautions, little building blocks to feel prepared, to involve a team, to stay on top of matters without panicking. 

I learn that I am not alone in my world of AppSec worries and that this space is rich with interesting, knowledgeable, and appropriately paranoid people. Spend any time trawling through Reddit, lurking within Twitter, and you will find people who are already on the ground running.

Poking my head out of the rabbit hole, I decide once and for all to embrace my paranoia, to make it work for me. I figure that the only way to win this battle, to create a proper offensive, is to think about it as much as attackers do and that my (un-panicked) paranoia will help me do exactly that.

Want to keep your application secure?

Start a free trial today and find out what we can do to help you to assuage your paranoia.


spoiler alert: probably not

Application Security Toolset

In this webinar, application security experts Jim Manico (OWASP top 10’s contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will go over best practices for rolling out an effective Application Security Toolset to your software development and security teams.

How can you best get started, and how can you best optimize your AppSec toolset over time? Watch this webinar NOW!

How can you best get started, and how can you best optimize your AppSec toolset over time?

Are you just thinking of implementing AppSec tools, or are you looking at optimizing your existing tool set? Watch Jim, Farshad and Julius in this webinar to hear:

  1. What combination of tools gives you maximum protection.
  2. What tool gives you the highest value out of the box.
  3. How are threats likely to evolve and how to use your AppSec tool set to stay one step ahead of cyber advisories.

Ready to start security your applications?

When Dependabot Is Worse Than Nothing: Log4J As A Sub-Dependency

Watch if this webinar about Dependabot applies to you and find out how to fix this :).

from the “Webinar Wednesday  from March 30th, 2022, with Jim and Julius

Why should you care about using Dependabot?

Because if you’re using industry-standard software leader Dependabot, then your devs didn’t fix the recent Log4J problem properly.

If you’re using it, then the tools you’re using now aren’t getting the job done.

In practice, it has a serious implementation flaw: it can only see transitive dependencies (aka sub-dependencies) in languages and dependency managers that support lock files.

Dependabot: Theory vs Reality

In theory, Dependabot is exactly what the world needs to keep software dependency chains safe from known vulnerabilities: tightly integrated with Github; auto-generates pull requests; plugged into Github Security Advisories (GHSA); it also supports a wide range of programming languages and dependency managers.

But in practice it has a serious implementation flaw: it can only see transitive dependencies (aka sub-dependencies) in languages and dependency managers that support lock files.

Do you know any languages that currently DO NOT support lock files?

Java / Maven!

This has some bad implications if you’re using it to protect yourself from Log4J (since Log4J is a Java library).

Want to know more?

OWASP Top 10 2021 Explained

Compromises in the application layer are now responsible for 40% of breaches. Two years ago that was 24%. Obviously, time to pay attention to application security. OWASP will give you a running start with their Top 10

Why use OWASP top 10 vulnerabilities?

Imagine if a dozen of the top cybersecurity experts in the world reviewed your software for security problems.  Since application security is generally not well covered in university, college, and bootcamp software courses, it’s likely they would probably find a lot of problems! 

Of course, hiring even 1 security expert to review your work is out of reach for a lot of software teams – let alone 12 experts. But you can do the next best thing:  you can check out the OWASP Top Ten 2021:

What is the OWASP Top 10 list?

The OWASP Top 10 is an important awareness document for web developers and web application security professionals. It represents a broad industrial consensus from cyber security experts about the most critical security risks to web applications.

OWASP Top-10 in-depth

This webinar provides defensive instruction in relation to the OWASP Top Ten to aid developers in authoring secure software. Jim Manico and Julius Musseau covered the OWASP Top-10 (2021 Edition) in-depth:

  • A01:2021-Broken Access Control
  • A02:2021-Cryptographic Failure
  • A03:2021-Injection
  • A04:2021-Insecure Design
  • A05:2021-Security Misconfiguration
  • A06:2021-Vulnerable and Outdated Components
  • A07:2021-Identification and Authentication Failures
  • A08:2021-Software and Data Integrity Failures
  • A09:2021-Security Logging and Monitoring Failure
  • A10:2021-Server-Side Request Forgery

About the panellists:

Video recording of OWASP Top Ten 2021 webinar with Jim Manico and Julius Musseau – 45 min on March 16th, 2022

  Jim Manico

  Julius Musseau

Still interested in learning more? Check other webinars.

How to Instantly Secure Log4j

The log4j vulnerability was announced on December 10, 2021, and ranks as one of the worst in history. How to secure log4j? The best resolution is to upgrade to a secure version. However, sometimes that is not possible, or at least it takes time. In these scenarios, run-time protection for log4j, or other vulnerabilities can be a lifesaver.

In organization that have hundreds or thousands of applications it can take days, or even weeks of all-out effort to upgrade these applications. Or it could be that the vulnerable applications are supplied by a vendor and the vendor does not have a fix immediately available. Run-time protection can be applied with a few clicks of a mouse, the video below walks you through how that works:

How to protect log4j instantly at run-time with Julius Musseau and Delan Elliott

In this video, Julius Musseau and Delan Elliott show how:

  • How access to a vulnerable library can be controlled
  • Either for the full library or surgically for just the method(s) that is at the root of the vulnerability.
  • This enables the organization to respond instantly to new vulnerabilities.
  • It applies to vulnerabilities such as CVE-2021-44228, and CVE-2021-45046
  • But can be applied to any Java based vulnerability.

If you are looking to secure log4j, or other libraries, contact us, or try out MergeBase for free.

Discover More from MergeBase

Open Source Protection

Stay on top of the real risk of open source at any time.

Avoid false positives and get sophisticated upgrade guidance based on risk, compatibility and popularity.

More on Continuous Protection

Add RunTime Protection

Detect and defend against known-vulnerabilities at runtime. The only SCA to do so.

The quickest way to respond to an imminent threat like log4j with CVE-2021-44228.

More on Run-time Protection

Shift Left Now

CodeGreen is an early-warning defence for your in-house development and integrates directly into GitHub and BitBucket

More on BitBucket and Github apps