CVE-2023-22795

What it actually does

This vulnerability is a denial-of-service issue in Ruby on Rails, specifically in request-handling logic where specially crafted HTTP input can trigger excessive processing. A remote attacker may be able to send malformed or adversarial requests that cause application worker processes to consume disproportionate CPU time or become tied up, reducing service capacity. The flaw does not directly enable code execution, privilege escalation, or data theft, but it can degrade or interrupt availability of Rails-based applications and downstream packaged products that include vulnerable Rails components, including listed Cacti packages.

Why it matters to the business

Successful exploitation can make affected web applications slow, unstable, or unavailable, disrupting monitoring, dashboards, APIs, and business workflows that depend on them. For Cacti deployments, this may impair infrastructure monitoring visibility during an incident. The vulnerability is not currently listed in CISA KEV, is not marked as ransomware-used, and has a relatively low EPSS score, but it has been public since 2023, so remediation should be treated as standard hygiene for any internet-facing or critical Rails-based service.

How an attack unfolds

An attacker identifies an exposed application or packaged product using a vulnerable Rails version. They send crafted HTTP requests designed to hit the vulnerable Rails request-processing path. Instead of being handled quickly, the request causes expensive parsing or matching behavior, tying up application workers or consuming CPU. By repeating these requests or sending them concurrently, the attacker can exhaust available web/application server capacity. Users may then experience high latency, failed requests, timeouts, or intermittent service outages. Because this is a denial-of-service condition, exploitation may leave limited application-layer artifacts beyond unusual request patterns and resource exhaustion symptoms.

How to fix it

Upgrade affected packages to fixed versions or later. For Debian Cacti packages, update to cacti 1.1.27+ds1-3 or later on Debian 11, 12, and 13. For Ubuntu 18.04 LTS Cacti packages, update to cacti 1.1.38+ds1-1 or later. For Rails source deployments, ensure the Rails codebase includes the upstream fix at commit c443466a99f8ed951605fb4993a01de5e41349a4 or use a Rails release that incorporates that fix. If immediate patching is not possible, reduce exposure by placing affected applications behind a reverse proxy or WAF with request-size, header-size, URL-length, and rate limits; enforce per-client throttling; tune application server worker limits and request timeouts; and restrict administrative or monitoring interfaces to trusted networks where feasible.

How to confirm the fix worked

Confirm the installed package or dependency version is at or above the fixed version. On Debian or Ubuntu systems, use package inventory tools such as dpkg-query or apt policy to verify the installed Cacti version. For Rails applications, inspect the Gemfile.lock, package manifest, or source revision to confirm the Rails version or commit includes the upstream fix. Validate that web and application servers enforce sane request limits and timeouts. After patching, monitor that application workers no longer show abnormal CPU spikes or request backlog when exposed to malformed or oversized HTTP requests in a controlled test environment.

Typical attack path

1. Discover an internet-facing Rails-based application or affected packaged product such as Cacti.
2. Fingerprint the application stack or infer Rails usage from headers, routes, errors, assets, or package metadata.
3. Send specially crafted HTTP requests that exercise the vulnerable Rails request-processing code path.
4. Increase request volume or concurrency to consume application workers, CPU, or web server queues.
5. Sustain the traffic until legitimate users experience slow responses, 5xx errors, timeouts, or service unavailability.

How to detect it

Look for signs of attempted or successful denial of service rather than a single definitive exploit string. Useful sources include reverse proxy logs, web server access and error logs, Rails production logs, application server logs, load balancer telemetry, WAF events, host CPU metrics, process monitoring, and APM traces. Investigate time windows with sudden CPU saturation, increased request latency, application worker exhaustion, request queue growth, and spikes in HTTP 408, 429, 499, 500, 502, 503, or 504 responses. In HTTP logs, look for repeated requests from the same source or small source set with unusually long URLs, abnormal headers, malformed parameters, repeated parsing errors, or requests that take much longer than normal while returning errors or timeouts. For Cacti systems, correlate web access anomalies with gaps in polling, graph generation delays, or monitoring collection failures. Because exploitation may not leave a unique artifact, combine application logs with infrastructure metrics to identify whether availability degradation aligns with suspicious request bursts.

What your security team should do

• Inventory all Rails-based applications and affected Cacti deployments, prioritizing internet-facing and business-critical services.
• Patch Cacti and Rails components to the listed fixed versions or later during the next available maintenance window, sooner for externally exposed systems.
• Apply compensating controls at reverse proxies, load balancers, and WAFs: rate limiting, request timeout enforcement, maximum header size, maximum URL length, and per-client concurrency controls.
• Review historical web, reverse proxy, application, and infrastructure monitoring logs for unexplained CPU saturation, request timeouts, 502/503/504 responses, and repeated malformed requests.
• Ensure operational monitoring can alert on application worker exhaustion, queue depth, elevated 5xx rates, and abnormal request latency.
• Restrict access to monitoring tools such as Cacti to trusted networks or VPN paths where possible.
• Do not over-prioritize over actively exploited KEV vulnerabilities solely based on this CVE, but avoid leaving it unpatched because it has been publicly known for an extended period.