Snakewell: CVE-2022-1471 Inner Loop

Snakewell — SnakeYAML meets Lightwell

In late 2022, a serious bug was found in SnakeYAML — one of the most common libraries for reading YAML in Java apps. Teams were told to fix it immediately, but there was no simple replacement on Maven Central for months. This workshop replays that situation on a realistic sample app, shows what went wrong when the official fix finally arrived, and demonstrates how Project Lightwell would have made the whole thing much easier.

What went wrong with SnakeYAML?

SnakeYAML (org.yaml:snakeyaml) turns YAML text into Java objects. You probably have it in your project even if you never added it yourself — Spring Boot, Jenkins, Confluence, and many other tools bring it in automatically.

The problem lives in SnakeYAML’s Constructor class. When your app uses that class to read YAML from someone you do not trust — for example, YAML uploaded through your API — the file can include special markers that tell SnakeYAML to create any Java class, not just the ones you intended. A skilled attacker can chain that into running their own code on your server.

Google’s security researchers published a working demo of this in October 2022. The bug was rated critical — the highest severity level security tools use. The recommended fixes were: use SnakeYAML’s safer SafeConstructor class for untrusted input, or upgrade to SnakeYAML 2.0 or later, which blocks those dangerous markers by default.

Our demo app is built to show the risky pattern on purpose: a web API that accepts pipeline YAML over HTTP and parses it with a custom Constructor. That is exactly the kind of app this bug was meant to warn about.

Not as famous as Log4j — but still a real headache

This bug never caused the same worldwide panic as the Log4j crisis in 2021. There was no wave of automatic attacks spreading from server to server. For many Spring Boot apps, the risk was lower than it looked on paper: Spring Boot already used SafeConstructor when loading application.yml, and the Spring team pointed out that most apps only load config files they control themselves.

That did not make the problem disappear:

  • Security tools flagged every old version. If your pom.xml listed snakeyaml below version 2.0, your build pipeline lit up — even when your app never parsed YAML from users.

  • There was no quick fix for months. The bug became public in October 2022, but the first official fixed release was SnakeYAML 2.0 in February 2023 — more than four months later. During that time, Maven Central had no fixed 1.x version you could drop in and move on.

  • The fix that finally arrived broke existing code. SnakeYAML 2.0 changed how constructors work. Apps that called SnakeYAML directly — like our Pipeline Definition API — could not just change one line in pom.xml and be done.

  • Big products still had to ship updates. In December 2023, Atlassian told Confluence, Jira, and Bitbucket customers to upgrade across many version lines. There was no config switch to turn the problem off — you had to install a newer product version.

  • The library authors pushed back on the panic. SnakeYAML’s maintainers said the bug only matters when you parse untrusted YAML with the permissive Constructor class — a design choice for full YAML support, not a hidden flaw in every app that happens to depend on the library.

The bottom line: less chaos than Log4j, but still weeks of engineering time, pressure from security and compliance teams, and a hard choice between living with the risk, rewriting your parser code, or waiting for a major upgrade that breaks your build.

Timeline

When What happened

Apr 2022

Bug reported privately to SnakeYAML maintainers

Sep 2022

SnakeYAML 1.33 released — still affected

Oct 13, 2022

Bug made public; Google publishes a working demo

Dec 1, 2022

Listed in public security databases as critical

Dec 12, 2022

Added to GitHub’s security bug list

Oct 2022 – Feb 2023

The gap: tools flagging old snakeyaml versions, but no fixed 1.x jar on Maven Central

Feb 26, 2023

SnakeYAML 2.0 — first official fix, but it breaks code that used the old API

Dec 2023

Atlassian and other vendors push customers to upgrade installed products

What is Project Lightwell?

Project Lightwell is a Red Hat offering for teams that depend on open-source libraries directly — the jars in your pom.xml, not only what ships inside RHEL or a product installer.

When a security fix would normally mean upgrading to a new major version (and rewriting code that calls the library), Lightwell can ship a backport: the same fix applied to the version you already use, published as a signed artifact you can swap in with a dependency change.

For this workshop, the important ideas are:

  • Remediated builds — fixed library versions such as 1.33.0.rhlw-00001 in Red Hat’s repository (https://packages.redhat.com/lightwell/java/remediated/)

  • API parity — your existing PipelineConstructor code keeps compiling; you are not forced onto SnakeYAML 2.0’s breaking API

  • Upstream contribution — Red Hat’s model includes working with the original open-source project to propose the same fix there (this lab does not claim that happened for SnakeYAML in 2022)

This lab is the inner loop: you change a dependency, build, and test locally. Module 5 explains the gap between this inner loop lab and outer loop remediation at enterprise scale (Lightwell + RHADS). The real next step for most teams is a customer workshop via your Red Hat account team; an optional example TSSC lab on RHDP previews supply-chain topics.

What if Lightwell had existed in 2022?

Lightwell did not exist in 2022. This lab uses a real bug and a real affected app to show what the Lightwell model offers today:

If Lightwell had existed back then, you would have pulled 1.33.0.rhlw-00001 from Red Hat’s fixed library repository — no code changes — while Red Hat worked with the SnakeYAML maintainers to contribute the same fix to the open-source project.

That fixed build would have blocked the dangerous YAML markers (same behavior as SnakeYAML 2.0) while keeping the 1.33 API your code already uses — so you would not hit the compile errors you will see in Module 3.

What you will do

  1. Explore a legacy Pipeline Definition API (Java 11, Spring Boot 2.7, SnakeYAML 1.33)

  2. Run a safe, contained demo that shows how the bug lets an attacker run code on the server

  3. Try upgrading to SnakeYAML 2.0 and watch your build break

  4. Swap in 1.33.0.rhlw-00001 from the Lightwell fixed library repository

  5. Read Module 5 — inner loop, outer loop, and next steps with your Red Hat account team

Prerequisites

See Environment Setup. You need:

  • Podman with Podman Compose

  • curl, bash

All commands run from the repository root. See compose.yaml for the stack definition. Demo API: 8080. Mock server: 9999 (compose DNS name mock-server from the app).

Repository layout

Makefile           make setup, make up, make preview, …
compose.yaml       Podman Compose stack (app + mock-server + tools)
demo-app/          Spring Boot sample application
content/           RHPDS Showroom / Antora lab guide (this site)
scripts/           demo scripts and thin compose wrappers

Local preview of this lab guide

Preview the Showroom content with Podman:

podman run --rm --name antora -v $PWD:/antora:z -p 8000:8080 \
  ghcr.io/juliaaano/antora-viewer

Open http://localhost:8000 — this previews the lab guide, not the demo API (port 8080).