Berkk Dev

December 8, 2025

It started innocently enough. I wanted to show my blog to a friend, pulled up the URL, and... nothing. The site was completely unresponsive. My first thought was the typical developer excuse: "It was working fine yesterday."

Except this time, something was genuinely wrong.

The Discovery

When I SSH'd into my server and checked the Docker logs, I was greeted with something I wasn't expecting:

chmod: x86: No such file or directory
/bin/sh: ./x86: not found
sh: can't create /dev/ijnegrrinje.json: Permission denied
sh: can't create /dev/fghgf: Permission denied
Connecting to 89.144.31.18 (89.144.31.18:80)
wget: can't open 'x86': Permission denied
/bin/sh: curl: not found
⨯ [Error: NEXT_REDIRECT] {
  digest: '12334\nmy nuts itch nigga\nMEOWWWWWWWWW'
}

And that's when it clicked. These weren't my errors. Someone was trying to execute arbitrary code on my server.

What the Attacker Was Trying to Do

Looking at the logs, the attack pattern becomes clear:

Download malicious payload: The attacker attempted to fetch an executable (x86) from 89.144.31.18:80
Create persistence mechanisms: Tried to create files like /dev/fghgf, /dev/stink.sh, and /dev/ijnegrrinje.json
Execute the payload: Attempted to run the downloaded binary

The good news? They failed.

Why the Attack Failed

The attacker couldn't complete their exploit for several reasons:

File system permissions: Docker's default security prevented writing to /dev/ and other critical locations
Missing utilities: The container didn't have curl installed, limiting their download options
Read-only file system constraints: The production environment was locked down enough to prevent arbitrary file creation

However, the attacker adapted. Since direct exploitation failed, they resorted to a different strategy: resource exhaustion. They flooded the server with massive payloads, consuming all available RAM until the Docker container crashed.

The Charming Touch

I have to give credit where it's due—whoever wrote this exploit has a sense of humor. The error digest '12334\nmy nuts itch nigga\nMEOWWWWWWWWW' is simultaneously juvenile and memorable. It's the digital equivalent of graffiti on a failed heist.

The Fix

The solution was straightforward: upgrade Next.js from 15.5.6 to 15.5.7 (or any patched version: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, or 16.0.7). The React team patched the underlying vulnerability in versions 19.0.1, 19.1.2, and 19.2.1.

After the upgrade, I rebuilt and redeployed the container. No more mysterious crashes, no more "my nuts itch" messages in the logs.

Lessons Learned

Patch immediately: This vulnerability was publicly disclosed on December 3, 2025, with working exploits circulating within 30 hours. There's no grace period for critical security issues.
Defense in depth works: While the vulnerability existed, Docker's security constraints prevented full exploitation. The attacker got nuisance-level access instead of complete system compromise.
Monitor your logs: I only discovered the attack because I checked the logs when the site went down. Regular monitoring can catch active exploitation attempts.
Keep dependencies updated: I was only one patch version behind, but that was enough to be vulnerable. Automated dependency updates for security patches are worth setting up.

Final Thoughts

There's something oddly educational about being on the receiving end of an attack. It transforms abstract CVE descriptions into tangible reality—complete with weird error messages and crashed containers.

The attacker didn't succeed in fully compromising my system, but they did remind me of an important truth: security isn't a checkbox you tick once. It's an ongoing process, and staying one patch version behind can be the difference between an amusing blog post and a serious incident.

Now, if you'll excuse me, I have some automated security updates to configure lol.

Resources:

How I Got Hacked (Almost)