rails A field note by Vikrant Sharma
A Rails CVE got exploited the same day it was patched
A government Rails site was compromised hours after the CVE-2024-28103 patch dropped. The attackers were watching the release notes.
A government Rails application got breached the same day CVE-2024-28103 was patched. The vulnerability allowed arbitrary file reads through Action Pack. The patch went live. Hours later, attackers were inside. This is the zero-day window shrinking to zero. Security teams used to get days or weeks to patch before exploits showed up in the wild. Now the exploit authors are watching GitHub release notes in real time. The patch itself is the announcement. The CVE was in Active Storage, Rails’ file attachment system. An attacker could craft a request to read files outside the intended directory. Think configuration files, database credentials, SSH keys. The patch added path validation. Clear fix, clear impact. What makes this ugly is the timing. The government site was not ignoring the patch. They were in the process of deploying it. The attackers simply moved faster. This is not a story about lazy ops teams leaving systems unpatched for months. This is a story about the patch cycle being slower than the exploit cycle. The practical takeaway is grim. If you run Rails in production, you cannot wait for your regular deploy schedule when a CVE like this drops. You need a process for emergency patches that runs in hours, not days. Automated dependency scanning helps, but only if it triggers an alert that someone acts on immediately. The other takeaway is that public disclosure of vulnerabilities is a double-edged tool. It pressures vendors to ship fixes quickly, but it also hands attackers a roadmap. The moment a patch lands, every smart attacker knows exactly where to look in the diff to build an exploit. The race starts the second the release notes go live.
