Ruby devs, you might want to sit down for this one. One forgotten configuration can give attackers front-row access to your apps.

Three new vulnerabilities just dropped on Rack, the foundational Ruby framework, which have been letting attackers slip in through the back door. And it’s all thanks to a single configuration misstep.

The vulnerabilities were uncovered by Thai Do and Minh Pham of OPSWAT’s 515 Security Team, and they hit with a triple threat: CVE-2025-25184, CVE-2025-27111, and the big one, CVE-2025-27610.

All three have serious implications for Ruby-based web apps. However, the CVE-2025-27610 bug has been assigned a CVSS score of 7.5, officially classifying it as high severity.

What do the vulnerabilities do?

• CVE-2025-25184: lets attackers inject bogus entries into your logs using classic CRLF (Carriage Return Line Feed) tricks. It’s the kind of attack that could hide malicious activity in plain sight or fake it altogether.
• CVE-2025-27111: takes things a step further by allowing attackers to manipulate log data through crafted HTTP headers. Think of it as a stealthy way to rewrite your app’s paper trail.
• And then there’s CVE-2025-27610, the showstopper. This one’s a path traversal vulnerability in Rack::Static that can let attackers reach outside your designated static directory and pluck sensitive files such as configuration files, environment variables, credentials – anything that was never supposed to be public.

Rack::Static is a middleware used in Ruby web applications to serve static assets like images, CSS, and JavaScript directly from the file system without hitting the main application logic. It is popular because it’s simple and powerful. You drop it in, define a couple of paths in :urls, and you’re good to go. But that simplicity hides some sharp edges, and this one can cut deep.

At the center of the mess is a setting called :root. If you don’t explicitly define it when you set up Rack::Static, the middleware quietly defaults to your app’s current working directory.

That sounds harmless enough, until you realize it’ll serve files from there without properly sanitizing the incoming paths. That means someone could slip in a few ../s classic path traversal trickery, and, boom, they’re poking around in files you didn’t intend to serve. Configuration files, logs, maybe even secrets.

Don’t miss our latest stories on Google News

Follow us

Researchers found that the file-serving process doesn’t validate paths properly. Once a request hits the PATH_INFO field and matches a static file prefix, Rack::Static combines that path with the root directory without much thought.

“In scenarios where the application does not explicitly define the :root option, an unauthenticated attacker can exploit this vulnerability to access sensitive data, such as credentials, configuration files, or database files, potentially leading to a significant data breach,” say researchers.

A handcrafted URL could sneak out of the static directory sandbox and expose sensitive data without ever touching your app’s code.

To demonstrate just how dangerous it is, the OPSWAT team built a proof-of-concept using Rack version 3.1.10, confirming that with the right URL and a misconfigured :root, even supposedly off-limits files could be exposed.

So what should you do?

While a patch is presumably in the works, it’s a reminder of the golden rule in dev life: never trust defaults. If you’re using Rack::Static, double-check that :root is explicitly defined and points to a directory outside of anything sensitive.

For the love of clean logs, sanitize your paths. Use tools that normalize incoming file paths before combining them with your root. Just because your app runs smoothly doesn’t mean it’s secure.