Your server is compromised. Thanks to nextjs and RCE.

I've had the same, version 2 needs to update nextjs asap #3833 (comment)

Sigh,.. Thanks will do a v2 release asap.

Security Incident Report - Next.js CVE Exploitation Confirmed

I'm reporting a confirmed exploitation of the Next.js RSC vulnerability (patched in v3.0.2) on a Umami v2.19.0 instance running Next.js 15.4.7.

Incident Summary

Our production instance was actively targeted and exploited through the Next.js vulnerability. The attack was detected through application logs showing multiple exploitation attempts.

Attack Patterns Observed

1. Server Action Exploitation:

   • Multiple attempts to invoke non-existent Server Actions
   • FormData parsing errors indicating payload injection attempts
   • Invalid header manipulation attempts (x-action-redirect)

2. Remote Code Execution Attempts:

   • Commands attempting to download and execute remote scripts via curl and wget
   • Base64-encoded payloads attempting to establish persistence
   • Multiple known malicious IP addresses attempting command injection

3. Database Access Attempts:

   • Errors showing attempts to access non-standard database columns
   • Queries targeting geolocation data (region, country)

Mitigation

Fortunately, the container environment limited the attack surface:

• Minimal Alpine-based container without bash prevented script execution
• Read-only filesystem restrictions blocked persistence attempts
• Most malicious payloads failed due to missing dependencies

Impact Assessment

Potentially compromised: Static assets served to end users (e.g., script.js) during the attack window.

Action taken:

• Instance immediately shut down
• Full rebuild scheduled with v3.0.2
• All secrets rotated
• Client-side script integrity verification in progress

Recommendation

Anyone running Umami < v3.0.2 with Next.js 15.4.x should treat their instance as potentially compromised and:

1. Immediately upgrade to v3.0.2 or newer
2. Verify integrity of static assets (especially script.js)
3. Rotate all secrets (APP_SECRET, database credentials)
4. Review access logs for suspicious activity
5. Consider notifying users if client-side scripts may have been modified

v2 is now updated.

Ugh got bite by this too. Whats extremely sad on my side is I had a note

# TODO: Investigate why Umami doesn't work on a readonly Alpine container.
"readonlyRootFilesystem": false

In our container which would have stopped this dead. I'll go research what blockers I hit with the container writing to random areas to see if they can be fixed with volumes, parameters, configuration or changes.

yep. same.

So I dug into this why I disabled Read Only and it was because prisma downloads the "engine" at runtime during migrations. This writes into x area and causes the container to crash out because read only.

Error: Schema engine exited. Error: Could not find schema-engine binary. Searched in:
- /app/node_modules/.pnpm/@prisma+engines@6.7.0/node_modules/@prisma/engines/schema-engine-linux-musl-openssl-3.0.x

So I thought about this and made a change to our Dockerfile that we deploy into ECS.

FROM ghcr.io/umami-software/umami:postgresql-v2 AS base

# Force Prisma CLI to run at build-time so it fetches engines
RUN cd /app \
  && pnpm prisma -v \
  && pnpm prisma generate

FROM base AS deploy

So just by tricking prisma ahead of time causes my Docker image to be built with the engines inside of it. This means I don't have that outbound network call (or write to IO). This in 24h of testing has worked. I run a readonly Umami container to defend against these type of attacks.

Hope that helps someone.

I have Umami also running in a container and just noticed that it was running at +1000% in docker stats. I since updated it to v2.20.1.

Given that it was in a docker container, is there a risk it could have affected the host system? Do I need to change the HASH_SALT or any other precautions, or is it sufficient to just replace the container?

@MatthK you should at the very least cycle all your env variables