AI coding agents accidentally introduced vulnerable dependencies

7 points by hsin003 205 days ago | 16 comments

Recently we discovered something unexpected on one of our servers: a cryptominer running in the background.

The machine was hosting a web service built using Next.js. The first sign of trouble was unusually high CPU usage. Even during low traffic periods, the server was consistently running near 100% utilization. After inspecting running processes and network activity, we found a background process downloading and executing a mining binary.

ROOT CAUSE

The entry point was CVE-2025-29927, a vulnerability in Next.js that allows middleware protections to be bypassed. This enabled an attacker to reach internal endpoints that were assumed to be protected. Once they hit the exposed endpoint, they executed a script that pulled down the miner.

HOW "VIBE CODING" FAILED US

This application was largely generated using AI-assisted tools (Claude Code and OpenAI Codex). This workflow—often called "vibe coding"—involved describing the desired functionality and letting the AI assemble the codebase.

The project worked perfectly, but the AI pinned a vulnerable dependency version in the package.json. Because the app ran normally and passed functional tests, we missed the audit step. Automated scanners found the vulnerability within hours.

THE BROADER LESSON

AI increases development speed, but it also increases the "security debt" of every deployment. In traditional development, you review versions carefully. With AI-generated scaffolding, that step is easy to overlook.

The attack chain:

AI-generated project -> Vulnerable dependency -> Middleware bypass -> Automated scan -> Cryptominer

HOW WE FIXED IT

We realized that if we are using AI to speed up development, we need automated "brakes" to match that speed. We moved our apps onto Containarium ( https://github.com/FootprintAI/Containarium ), an open-source platform that uses ZFS-backed, unprivileged LXC containers to consolidate 100+ isolated environments onto a single VM with integrated security monitoring and vulnerability scanning.

This ensures that even if a developer accidentally deploys a vulnerable dependency, the breach is isolated from the host and flagged by runtime monitoring.

OPEN QUESTION

I’m curious how others are handling the "AI audit" problem. Are you adding automated security gates to your dev environments, or are you strictly relying on traditional dependency scanning and hoping the "vibe" doesn't miss anything?

speakingmoistly 205 days ago |

I think some folks are very quick to drop rigor and care as "traditional practices" as if we're talking about churning butter by hand. One thing that might be valuable to keep in mind is that LLM tooling might feel like an expert, but generally has the decisionmaking skills of a junior. In that light, the rigor and best practices that were already (hopefully) part of software engineering practice are even more important.

> In traditional development, you review versions carefully. With AI-generated scaffolding, that step is easy to overlook.

If in "traditional development", everything is reviewed carefully, why wouldn't it be when some of the toil is automated? If anything, that's exactly what the time that's freed up by not having to scaffold things by hand should be invested in: sifting through what's been added and the choices made by the LLM to make sure they are sound and follow best practices.

veunes 204 days ago | |

Reviewing generated code actually takes a higher skill level than writing it. A junior who prompted this Next.js app into existence is physically incapable of auditing the security of those imports. And for a senior it's often cheaper to just write it from scratch than to sit there and audit abstract spaghetti generated by Claude

hsin003 205 days ago | |

Totally agree — AI scaffolding automates work, but best practices like CI/CD and pentesting are still essential. Continuous monitoring is necessary for all commits, and combining it with a dev-like centralized platform ensures every service and endpoint stays safe.

newexpand 205 days ago |

The attack chain you described highlights a gap that most teams overlook: AI-generated code passes functional tests but skips the "why this version?" review that experienced developers do instinctively.

I think the real issue is visibility. When AI generates a project, every dependency choice is implicit — there's no PR comment explaining why it pinned next@14.1.0 instead of 14.2.1. In a human workflow, someone would have caught that during review.

Two things that have helped in my workflow: 1. Running `npm audit` as a post-generation step before even testing functionality 2. Treating AI-generated commits as "untrusted by default" — reviewing them with the same rigor as external contributor PRs

hsin003 205 days ago | |

CVEs are time-dependent. Even if npm audit guarantees no known vulnerabilities at the moment you merge a PR, new CVEs can emerge later, silently impacting your system without anyone realizing it.

That’s why I think continuous monitoring and centralized pentesting are essential — not just at merge time, but throughout the lifecycle of AI-generated projects.

upflag 204 days ago |

This is terrifying but not surprising. I shipped unauthenticated admin endpoints once in a project that was extensively planned out with AI. The volume of code AI generates makes it really easy for vulnerabilities to slip through because review gets lighter as output gets faster. The two things that actually help: dedicated security review sessions in a fresh context (the building session won't catch its own mistakes), and monitoring for unusual patterns like the CPU spike that caught this. If your first sign of compromise is high CPU, at least something was watching.

hsin003 204 days ago | |

That’s a great point about fresh-context reviews — the same session that generated or assembled the code often won’t catch its own mistakes.

What worried us in this incident is that even if you catch everything during review, new CVEs can appear later and suddenly make previously “safe” code vulnerable.

That’s why we started treating monitoring as part of the platform itself — every service runs with centralized checks so unusual behavior (CPU spikes, unexpected processes, endpoint exposure) gets flagged quickly.

P-MATRIX 203 days ago |

The real gap here isn't CI — it's that the agent had no cost model for what 'add this dependency' actually means at runtime. It knew how to write the import; it had no concept of the blast radius if the package was compromised. Post-deploy audits and container isolation catch things after they're already in, but risk assessment before the tool call is what closes the loop. That's a different problem than scanning output.

hsin003 205 days ago |

Hi HN — author here.

This incident showed how AI-generated code can inadvertently introduce vulnerabilities. The cryptominer ran because a dependency version chosen by an AI coding agent had a known CVE.

Containarium now runs centralized pentests and vulnerability checks for all applications on the platform to prevent similar attacks.

Curious if others have similar workflows or lessons learned with AI-generated projects.

veunes 204 days ago | |

Nobody in their right mind builds a pipeline where security relies on a custom container runtime catching things after the fact. Security starts in CI at the image build stage. If your flow actually lets a vulnerable Next.js build slip all the way through to deployment in Containarium, your integration process is fundamentally broken, not your runtime environment

hsin003 202 days ago | | |

I agree CI should catch as much as possible — image scanning and dependency checks at build time are table stakes.

But in practice, CI is only a point-in-time guarantee. A build can pass all checks and still become vulnerable later as new CVEs are disclosed.

So the goal isn’t to rely on runtime to “catch mistakes”, but to add a second layer of defense — continuous monitoring and probing for already-deployed services.

If anything, this incident showed us that CI alone isn’t sufficient once systems are long-lived.

Egonex 204 days ago |

This is what we do. We use AI for drafting but we never merge without doing a manual review of dependencies. Every package version is pinned explicitly, and our CI always runs a dependency scan before deploy.

The AI is fast at scaffolding, the bottleneck is still us catching what it gets wrong. NOthing is easy unfortunately

ATechGuy 203 days ago |

You built https://github.com/FootprintAI/Containarium for this purpose?