Module 4: Lightwell Hot-Swap

Remember: this is a what-if. Lightwell did not exist in 2022. This module demonstrates the model using today’s fixed library version — what you would have done in minutes during the gap between October 2022 and February 2023.

Maven Central publishes this release as 1.33; security write-ups and Lightwell artifacts refer to it as 1.33.0. They are the same open-source release — only the version string differs. The Lightwell fixed build is 1.33.0.rhlw-00001. NOTE: Run all commands from the repository root (where compose.yaml lives).

What you are about to apply

Module 2 showed the attack: YAML with special markers (!!javax.script.ScriptEngineManager, and so on) tricked SnakeYAML into loading and running malicious.jar.

Module 3 showed that waiting for open-source SnakeYAML 2.0 still forced a parser rewrite — the fix arrived bundled with breaking API changes.

The Lightwell artifact 1.33.0.rhlw-00001 applies the same security behavior SnakeYAML 2.0 eventually shipped — dangerous global markers are blocked by default — but on top of the 1.33 library you already use. Your PipelineConstructor and PipelineYamlParser source files stay as they are. Only the dependency coordinate changes.

Add Red Hat’s fixed library repository

Edit demo-app/pom.xml and add:

<repositories>
  <repository>
    <id>redhat-lightwell-remediated</id>
    <url>https://packages.redhat.com/lightwell/java/remediated/</url>
  </repository>
</repositories>

Ensure .m2/settings.xml includes credentials for packages.redhat.com.

Pin the fixed library version

Set the SnakeYAML version to 1.33.0.rhlw-00001 (same 1.33 API as the baseline):

<snakeyaml.version>1.33.0.rhlw-00001</snakeyaml.version>

Build and test — zero application code changes

podman compose --profile tools run --rm maven clean test -Dsnakeyaml.version=1.33.0.rhlw-00001

Tests pass without touching PipelineConstructor.java. That is the point: the fix lives in the library, not in a rushed parser rewrite.

Start the stack

Module 2 cleanup already stopped the stack (make down). Start it again so the app boots with your updated pom.xml and resolves 1.33.0.rhlw-00001. Leave this running in a terminal:

make up

Re-run the attack demo

In another terminal, send the same malicious YAML as Module 2:

rm -f .workshop-data/pwned
curl -s -X POST http://localhost:8080/api/pipelines/validate \
  -H 'Content-Type: text/plain' \
  --data-binary @./scripts/examples/exploit-payload.yaml

Verify the fix

test ! -f .workshop-data/pwned && echo "Attack blocked"

The application should return an error response (for example HTTP 500) and must not create .workshop-data/pwned.

Legitimate pipeline YAML from Module 1 should still work — the library blocks the attack path from Module 2, not normal pipeline parsing for your own types.

Summary: what Lightwell provided

You changed two lines in pom.xml (repository + version), rebuilt, and re-ran the same attack. The outcome flipped: Module 2 created .workshop-data/pwned; Module 4 did not. No SafeConstructor refactor, no SnakeYAML 2.0 compile failure, no Spring Boot 3 migration.

Before (1.33) After (1.33.0.rhlw-00001)

Your Java source

Unchanged

Unchanged

Dangerous !! markers in untrusted YAML

Honored — attack demo succeeded

Blocked — same rule SnakeYAML 2.0 added later

Maven Central 1.x drop-in fix in Oct 2022–Feb 2023

None available

Counterfactual: Lightwell remediated repo would have had this

What the backport actually does. SnakeYAML 2.0’s changelog described the fix as: do not allow global tags by default. The Lightwell build applies that rule to the 1.33 codebase. Your app keeps calling the same constructors and type mappings; the library simply refuses the marker trick from Module 2.

What happens beyond your laptop (the model today, not a 2022 claim). Lightwell’s documented lifecycle does not stop at publishing 1.33.0.rhlw-00001:

  1. Red Hat validates and tests the backport

  2. You consume the signed artifact from the remediated repository — what you did in this module

  3. Red Hat opens a pull request with the SnakeYAML maintainers, offering a minimal 1.33-compatible patch with the same behavior change

  4. Red Hat works with maintainers toward merge, and keeps maintaining the .rhlw build if upstream is slow or ships the fix differently (as they did with the breaking 2.0 release)

We do not claim Red Hat submitted that pull request during the original 2022 incident. SnakeYAML 2.0 credits Jonathan Leitschuh; the community fix arrived in February 2023 as a major release. This module shows the customer-facing half of the model (minutes to patch) and the ecosystem-facing half (contribute the same fix upstream so everyone benefits).

Compare that to the three choices from Module 3: refactor now, wait months and refactor anyway, or stay exposed. Lightwell is the missing option — a fixed jar on the version you already pin, while upstream catches up on its own schedule.