When you run a busy Rails application, you want your background jobs to tick along smoothly, and *Sidekiq* is one of the most popular tools for this. But what if your dashboards—your window into job health—could be knocked out by a single, simple request? That’s exactly what CVE-2022-23837 is about.

Let’s break down why this happened, show some real code, and talk about exploitation (and fixing!)—all in plain language.

What Is CWE-2022-23837?

Sidekiq is a background job processor for Ruby, often integrated into Rails. It comes with a web interface for monitoring. Before version 5.2.10 (for Sidekiq 5.x) and 6.4. (for Sidekiq 6.x), there was a flaw in the api.rb file: it didn’t put any limit on the number of days you could request job stats for in the UI graphs.

In Plain English

If you asked Sidekiq for 1,000 days' worth of job stats in the web interface, it would try to gather and send *all of it*—burning through CPU, RAM, and possibly crashing your monitoring app or wedging your server. This could be triggered intentionally or accidentally, affecting *everyone* relying on the Sidekiq UI.

The Vulnerable Code: Too Trusting for Its Own Good

Let’s see the core mistake. The endpoint in api.rb looked roughly like this (simplified for clarity):

# Sidekiq::Web::Application
get '/stats' do
  days = params[:days].to_i
  # ... get stats for that many days ...
  stats = Sidekiq::Stats::History.new(days)
  # ... return stats as JSON ...
end

Whoops: days is whatever the user supplies—*no checks!* Supply ?days=9999999 and the server will go bananas.

Resource Overload: The app needlessly allocates huge arrays or queries huge lists from Redis.

- Web UI Unavailable: The Sidekiq Dashboard becomes unresponsive or times out, leaving you blind to job activity.

Denial of Service Vector: Someone could automate this to DDoS your Sidekiq admin panel.

This isn’t a direct code execution flaw, but it *does* mean anyone who can hit the /stats endpoint can knock out your monitoring—potentially at a critical moment.

How the Exploit Works

1. Open your browser (or use curl/postman).

Send a GET request to the /stats endpoint of Sidekiq’s web dashboard, e.g.

http://your-app.com/sidekiq/stats?days=10000

3. If your server is running a *vulnerable* version, waiting starts—and the system burns resources computing stats for 10,000 days.

Sample Curl One-Liner:

curl 'http://localhost:300/sidekiq/stats?days=20000';

Result: The dashboard hangs, possibly all requests stall, and Sidekiq’s web interface becomes totally useless.

Official References and Details

- Sidekiq ChangeLog 6.x (look for "Limit how many stats days for Web's graph"
- Sidekiq Security Advisory (GitHub)
- NIST National Vulnerability Database CVE-2022-23837

The Fix: Putting a Lid on Days

How did the Sidekiq team fix it? They *capped* the number of days you can request. Here’s what it looks like now:

# Only allow up to 90 days no matter what the user sends
days = [[params[:days].to_i, 1].max, 90].min
stats = Sidekiq::Stats::History.new(days)

So if someone asks for anything over 90 days, they only get 90—no resource spike.

Do you expose the web dashboard to users (even if internal)?

- Can you request /stats?days=100 and cause a stall?

Conclusion

CVE-2022-23837 is a textbook example of why *input validation* is absolutely critical, even for “internal” tools. If you use Sidekiq, check your version and upgrade. A friendly admin or a curious user could bring your job board to its knees with a single request before these versions.


*Always upgrade, always validate input, and stay safe!*


TL;DR:  
*Sidekiq dashboards let anyone request graphs for unlimited days. This could crash your admin panel. Fix = upgrade ASAP and don’t leave important UIs unguarded.*

- Changelog for Sidekiq
- GitHub Security Advisory
- NVD CVE-2022-23837

Timeline

Published on: 01/21/2022 21:15:00 UTC
Last modified on: 04/25/2022 17:22:00 UTC