After 5 Years of Coding, This Is What Actually Matters

Kunsang Moktan — Sun, 22 Feb 2026 10:09:03 +0000

After nearly five years of coding and two years of real-world production experience, one thing has become very clear to me:

The programming language or tech stack matters far less than how you think and write your logic.

What truly makes a difference is:

How you structure your logic
How you handle edge cases
How you debug failures
How you manage exceptions
And how you implement meaningful logging for production systems

The endless debate about which language or framework is “better” will never stop. But in real-world engineering, maintainable, readable, scalable, and production-ready code matters far more than the stack itself.

No programming language is inherently superior to another.
Each one exists for a reason and serves a specific purpose. What matters is choosing the right tool based on the problem you’re trying to solve, not personal preference.

A Simple (and Slightly Sarcastic) Analogy

Imagine you’re going to the market to buy a water bottle.
You need something portable, easy to carry, and suitable for drinking. The bottle costs ₹100.

Right next to it, there’s a bucket costing ₹120.

Now, you wouldn’t say:

“I’ll take the bucket because it can store more water.”

Why?
Because storage capacity isn’t your use case. You can’t comfortably drink from it or carry it around.

The same logic applies to software development.

Just because a framework is powerful or popular doesn’t mean it’s the right choice for every project. For example, building a website for a client whose top priority is SEO might not be best served by a client-side heavy React application. In that case, WordPress, SSR, or another SEO-friendly stack could be a far better fit.

The Real Point

Choosing a tech stack should be driven by:

Project requirements
Business goals
Scalability needs
Team expertise
Long-term maintainability

Not by:

Personal bias
Trend popularity
Or attachment to a favorite framework

You can’t—and shouldn’t—build every project using the same stack (like MERN) just because you like it.

Good engineers don’t worship tools. They choose them wisely.

Lessons Learned from the React2Shell Vulnerability (December 3, 2025)

Kunsang Moktan — Sat, 13 Dec 2025 18:17:53 +0000

On December 3, 2025, the React2Shell vulnerability was disclosed, exposing a serious remote code execution risk in certain React and Next.js setups. Unfortunately, this wasn’t just a headline for me—I experienced it firsthand on a client’s production server.

This post documents what happened, how the compromise was detected, and the most important lessons I learned as a developer.

The Incident

One of my client’s servers was running Next.js 16, which was affected by the vulnerability.

When I SSH’d into the server to deploy routine changes, I immediately noticed something was wrong:

node commands were failing unexpectedly
Deployment scripts wouldn’t execute
The server felt unusually slow

Checking system resources revealed the real issue.

What I Found

CPU usage was constantly above 100%
A suspicious process named xmirg was consuming ~106% CPU
Several unauthorized .sh files and a ZIP archive appeared in the project’s root directory

Attempts to kill the xmirg process were unsuccessful—it restarted automatically every time.

After deeper inspection, I discovered the malware had registered itself as a system service:

system.update.update.service

The name was deliberately chosen to resemble a legitimate system update service, making it easy to overlook.

At this point, it was clear that:

The server had been fully compromised
It had been turned into a cryptocurrency mining machine
Application performance had degraded significantly

Containment & Resolution

Fortunately, the cloud service provider detected the malicious activity and temporarily limited the server’s CPU usage.

However, because the compromise occurred at the system level:

Cleaning the server was not safe
Trust in the system was irreversibly lost

The only correct action was to delete the server entirely and provision a new one from scratch.

Key Lessons Learned

1. Never Deploy Applications as the Root User

This was the most critical mistake.

The application was deployed and running with root privileges, which allowed the attacker to:

Install system-level services
Execute arbitrary shell scripts
Persist even after killing processes

Best practice:

Create a dedicated non-root user for deployments
Grant only the minimum permissions required
Use sudo explicitly when necessary

This alone can significantly limit the impact of an RCE vulnerability.

2. Firewalls Alone Are Not Enough

The attack did not bypass the firewall—it came through HTTPS (port 443).

This highlights an important truth:

If your application layer is vulnerable, network-level protection is not sufficient.

Security must include:

Dependency monitoring
Timely patching
Least-privilege execution
Runtime behavior monitoring

Final Thoughts

Vulnerabilities like React2Shell are a reminder that:

Modern frameworks are powerful—but not immune
One misconfiguration can turn a production server into a liability
Server hardening is just as important as secure code

This incident changed how I approach:

Deployment permissions
Server access control
Incident response

DEV Community: Kunsang Moktan