Developing Fried Rice Theme with Claude Code

Tue, 23 Dec 2025 15:00:00 +0800

Recently, I used Claude Code to add some SEO features to my own blog theme Fried Rice, and the overall experience was quite good.

Background

Fried Rice is a theme forked from hugo-theme-stack. Previously, I had already added some basic JSON-LD structured data, and this time I wanted to continue improving it.

What Was Done This Time

Mainly enhancing SEO structured data:

WebSite schema (supports search action)
Organization schema (includes founder, contact point, address)
FAQ schema (supports inline FAQ in articles)
Enhanced Article/BlogPosting schema (added accessibility metadata)

Claude Code’s Performance

The entire development process took about 2 hours. Claude Code helped me:

Write code - Hugo template syntax is cumbersome, letting AI write it saves a lot of effort
Review code - After I committed, I asked it to check, and it found several issues:
- datePublished was defined 3 times
- founder object was defined repeatedly
- JSON output had double escaping issues
- Variable scope errors
Fix issues - After finding issues, I asked it to fix them directly, all fixed at once
Create PR, tag, write CHANGELOG - These trivial tasks can also be done

A pleasant surprise was that it could find logical issues in the code. For example, Hugo’s jsonify output was HTML-escaped causing JSON format errors, and it found the correct solution (using safeJS).

Shortcomings

Sometimes needs multiple reminders to use the correct tools
Not very familiar with Hugo template syntax in some places, needs several iterations

Summary

For this kind of “add feature + fix bug” task, Claude Code is quite useful. Especially for tedious syntax like Hugo templates, having AI write it is much more efficient.

Based on:

Use Emerging Open Source Software with Caution

Sat, 13 Dec 2025 11:02:40 +0800

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:

Attacker crafts malicious payload in the code node’s input
Malicious code overwrites global JavaScript functions before sandbox restrictions are enforced
Uses the overwritten functions to bypass security checks
Executes arbitrary commands, gaining complete control of the container
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:

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:

Look at the project’s dependency tree
Check for known vulnerabilities
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.

Open Source on Svtter's Blog