CVE-2023-22799

What it actually does

CVE-2023-22799 is a denial-of-service vulnerability in the Rails GlobalID component. A crafted GlobalID value can trigger inefficient parsing behavior, causing excessive CPU consumption and request processing latency. The issue does not imply code execution or data disclosure by itself, but it can make application workers, background jobs, or APIs that parse untrusted GlobalID strings slow or unavailable.

Why it matters to the business

Applications that accept or process attacker-controlled GlobalID values may experience degraded performance, worker exhaustion, failed requests, delayed background processing, or temporary service outages. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported mature public exploitation in the provided data; however, it has been public for a long time, so affected dependencies should still be remediated as part of normal vulnerability management.

How an attack unfolds

An attacker first identifies an application endpoint, API parameter, serialized job payload, signed message, or other input path that is passed into GlobalID parsing or lookup functionality. The attacker then submits specially crafted GlobalID-formatted input designed to exercise the vulnerable parsing behavior. If the application processes the value synchronously, request workers may spend excessive time handling the input, increasing CPU usage and response time. Repeated submissions can amplify the effect, potentially exhausting web or job-processing capacity and causing a denial of service. The supplied threat-actor field references HTTP/2 Rapid Reset, but that is a separate denial-of-service technique and is not specific evidence of exploitation of this GlobalID issue.

How to fix it

Upgrade rails/globalid to a version that includes the upstream fix. The provided fixed artifact is rails/globalid commit 574b99fb9a23a9c637e44c0970616dd32b68e93f; use a released package version that contains this commit, or vendor the patched commit only as a temporary measure if a packaged release is not available. Rebuild and redeploy applications after dependency updates, and refresh lockfiles so all runtime and build environments use the patched dependency. As compensating controls, validate and bound the length of user-supplied GlobalID-like strings, reject malformed GlobalID input before parsing, apply request rate limits, set conservative web and job worker timeouts, and monitor CPU saturation and queue depth.

How to confirm the fix worked

Confirm dependency inventory and lockfiles no longer resolve rails/globalid to a vulnerable revision and that the installed source contains commit 574b99fb9a23a9c637e44c0970616dd32b68e93f or a later equivalent release. In Ruby environments, review Gemfile.lock, bundle info globalid, and deployed container or artifact manifests. Exercise application paths that parse GlobalID values with valid and malformed inputs and verify they return promptly without excessive CPU usage. Confirm CI dependency scanning, software composition analysis, and runtime package inventories all report the patched GlobalID version or commit.

Typical attack path

1. Identify a Rails application or service using the vulnerable rails/globalid component.
2. Find an externally reachable input that is interpreted as a GlobalID value or passed into GlobalID lookup/parsing logic.
3. Send a malformed or adversarial GlobalID string that triggers expensive parsing behavior.
4. Repeat requests or submit many payloads concurrently to consume CPU and worker capacity.
5. Cause request timeouts, queue growth, elevated error rates, or temporary service unavailability.

How to detect it

Look for signs of denial-of-service activity against endpoints or jobs that process GlobalID values. Useful sources include application logs, web access logs, reverse proxy logs, APM traces, job processor logs, container metrics, host CPU telemetry, and exception reporting systems. Investigate bursts of requests containing unusually long or malformed strings beginning with GlobalID-style prefixes, repeated 408/429/499/500/502/503/504 responses, request timeout exceptions, worker restarts, queue backlogs, and sustained CPU saturation without corresponding normal traffic growth. In Rails logs and exception trackers, search for GlobalID parsing or lookup errors, unusually slow controller actions around parameters containing gid:// values, and repeated failures from the same source IPs, user agents, API clients, or unauthenticated sessions. Because exploitation primarily causes resource exhaustion, absence of a unique payload string does not rule out attempted exploitation; correlate malformed GlobalID input with timing, CPU, and error-rate anomalies.

• gid://
• GlobalID::Locator.locate
• GlobalID::URI
• GlobalID::Identification
• GlobalID::Verifier
• Invalid GlobalID
• URI::InvalidURIError
• Rack::Timeout::RequestTimeoutException
• Net::ReadTimeout
• ActionController::BadRequest
• Completed 500
• Completed 503
• Completed 504
• worker timeout
• request timeout
• execution expired

What your security team should do

• Inventory applications and services that depend on rails/globalid, including transitive Rails dependencies and background job processors.
• Prioritize remediation for internet-facing endpoints, APIs, webhook handlers, and job ingestion paths that accept untrusted GlobalID-like input.
• Upgrade to a GlobalID release containing commit 574b99fb9a23a9c637e44c0970616dd32b68e93f and redeploy all affected workloads.
• Add input validation and length limits for fields expected to contain GlobalID values.
• Review web, application, and job-processing logs for unexplained CPU spikes, request timeouts, or repeated malformed GlobalID parsing errors.
• Ensure rate limiting, request timeouts, worker recycling, and autoscaling thresholds are appropriate for denial-of-service resilience.
• Track this as routine but necessary remediation: EPSS is low, it is not KEV-listed, and no mature exploitation was provided, but the issue is old and should not remain in production dependencies.