Recently, I had an incident with Dify/Langchain and reached this conclusion.

Retrospective

About 7 months ago, I deployed the open-source Dify to the server and started an instance through the official docker compose. However, recently, due to a sandbox escape vulnerability in Dify’s code node (CVE-2025-3466), I was privilege-escalated via webshell and had a Monero mining program implanted.

Fortunately, after this privilege escalation, the intruder didn’t do much, and the intrusion was in the docker container, with limited damage.

CVE-2025-3466 Details

CVE ID: CVE-2025-3466 Release Date: July 7, 2025 CVSS Score: 9.8 (Critical) Affected Versions: langgenius/dify 1.1.0 - 1.1.2 Fixed Version: 1.1.3

Vulnerability Description: Dify’s code node has a sandbox escape vulnerability, allowing attackers to bypass sandbox security restrictions by overwriting global JavaScript functions (such as parseInt), thereby executing arbitrary code with full root privileges.

Attack Flow:

1. Attacker crafts malicious payload in the code node’s input
2. Malicious code overwrites global JavaScript functions before sandbox restrictions are enforced
3. Uses the overwritten functions to bypass security checks
4. Executes arbitrary commands, gaining complete control of the container
5. Implants webshell backdoor and Monero mining program

Impact Scope:

• Unauthorized access to secret keys and API keys
• Access to internal network servers
• Lateral movement within the dify.ai system
• Complete takeover of server control

Related Links:

• NVD Details
• GitHub Advisory GHSA-x53g-q9xm-rf4m

From this perspective, several key factors are indispensable for protecting server security.

Personal Server Security

From a security perspective, there are several things that must be done on personal servers. The first thing is to avoid using passwords as much as possible. For example, SSH passwords.

SSH Passwords

Password login must be disabled. SSH password cracking is relatively easy. If the password is simple, or if the user changes the password themselves and uses a simple password, the server will be breached.

If using Debian/Linux, disabling password login and disabling root login are mandatory:

The fewer software packages used, the narrower the attacker’s attack surface. Once only nginx is exposed on your server, and port 80 and port 22 (SSH) are not open, the attacker’s attack surface is limited to nginx-related content.

Use Rootless Docker

Using container technology is equivalent to further virtualizing on top of the cloud service provider’s infrastructure.

Using rootless docker can further limit container permissions. Even if the container is breached, the attacker cannot directly gain root privileges on the host. This is the last line of defense.

Limit Container Network Access

Most services don’t need unrestricted external network access permissions. Reasonably configuring container network policies to limit unnecessary network access can greatly reduce the attack surface.

For example, many services only need to access databases or internal services, and don’t need to access the external network at all. If the container doesn’t have external network access permissions, even if breached, the attacker cannot download mining programs or communicate with C2 servers.

How to Use Open Source Software with Caution

This incident made me reflect on the following points when using emerging open source software:

Choose Mature Projects

Look at the project’s star count, commit frequency, and issue handling status. If a project:

• Has few stars (less than a few hundred)
• Hasn’t been updated in recent months
• Has a large number of unresolved issues

Then the risk of using this project is high.

Audit Dependencies

Open source software often depends on a large number of third-party libraries. Like Dify in this incident, there was a serious code node sandbox escape vulnerability. Before deployment, it’s best to:

1. Look at the project’s dependency tree
2. Check for known vulnerabilities
3. Regularly update dependencies

Regular Updates and Security Scanning

• Regularly check CVE databases
• Use tools like snyk, trivy for dependency vulnerability scanning
• Update to fixed versions in a timely manner

Limit Permissions

Even if you trust a certain open source software, you should give it minimal permissions:

• Don’t give containers privileged permissions
• Limit container resource usage (CPU, memory)
• Use read-only file systems (if possible)
• Don’t mount the host’s sensitive directories into the container

Monitoring and Alerting

Security is a continuous process, can’t rely solely on prevention. Establishing comprehensive monitoring and alerting mechanisms is crucial:

• Monitor system resource usage (CPU, memory, disk IO anomalies may indicate mining programs)
• Monitor network traffic (abnormal outbound connections)
• Monitor process list (abnormal processes)
• Set up log alerts (e.g., failed login attempts)

Conclusion

Open source software provides us with great convenience, but also brings security risks. Although this incident didn’t cause much loss, it gave me an important lesson:

Don’t blindly trust any software, especially emerging open source projects. Do more investigation before use, give minimal permissions during use, and continuously monitor and update after use.

Server security is not a one-time solution, but requires continuous attention and maintenance.