CVE-2022-22577

What it actually does

CVE-2022-22577 is a cross-site scripting issue in Ruby on Rails Action Pack affecting versions in the 5.2.x line. For certain non-HTML responses, Action Pack could emit content in a way that allowed attacker-controlled script execution despite an application's Content Security Policy protections. Because exploitation occurs in a victim user's browser, the impact is primarily unauthorized script execution in the security context of the vulnerable web application, potentially allowing theft or misuse of browser-accessible data, user action forgery, session-adjacent abuse where cookies or tokens are exposed to script, and modification of page content seen by the victim.

Why it matters to the business

A successful attack can compromise trust in a Rails-based web application by allowing an attacker to run malicious browser code against users who visit a crafted link or attacker-influenced page. This can lead to account misuse, exposure of sensitive information visible in the browser, fraudulent user actions, reputational harm, and increased support or incident response costs. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the affected Rails ecosystem is widely deployed, so internet-facing applications using vulnerable Action Pack versions should still be prioritized for routine patching.

How an attack unfolds

An attacker first identifies a Ruby on Rails application using an affected Action Pack version and a route or endpoint that returns a non-HTML response containing user-controllable content. The attacker crafts a payload that is interpreted by the victim browser as executable script and uses the response handling behavior to bypass the intended Content Security Policy restrictions. The attacker then delivers the crafted URL or content to a target user, commonly through phishing, a malicious link, embedded content, or stored attacker-controlled data if the application permits it. When the victim interacts with the malicious content, the browser executes the script in the context of the vulnerable application, allowing the attacker to read or manipulate browser-accessible application data and perform actions as the victim within the limits of the user's session and application permissions.

How to fix it

Upgrade Ruby on Rails Action Pack to a patched version provided by the Rails maintainers or by the operating system/distribution package maintainer. Because the input does not include exact fixed versions, use the latest supported release for the deployed Rails branch, or upgrade off the affected Action Pack 5.2.x release line where feasible. For Debian-packaged deployments, apply the relevant Debian security update for the affected package. As compensating controls, reduce exposure of endpoints that return non-HTML content with user-controlled data, ensure correct Content-Type and X-Content-Type-Options: nosniff headers are set, avoid reflecting untrusted input in responses, encode output according to response type, and review CSP rules, but do not rely on CSP alone as the primary fix.

How to confirm the fix worked

Confirm the application is no longer using an affected Action Pack version by checking the resolved Rails/actionpack package version in Gemfile.lock, bundle list, package manager output, container images, and deployed artifacts. Verify that vendor or distribution security advisories mark the installed package as fixed. Test representative non-HTML endpoints that include user-controlled input to ensure payloads are encoded or rejected and are not executed by modern browsers. Confirm responses use the intended Content-Type and include X-Content-Type-Options: nosniff where appropriate. Re-run dependency scanning or software composition analysis against Ruby gems and OS packages to confirm the finding is cleared.

Typical attack path

1. Identify a Rails application running an affected Action Pack 5.2.x version.
2. Find an endpoint that returns a non-HTML response and reflects or includes attacker-controlled input.
3. Craft an XSS payload that abuses the response behavior to bypass Content Security Policy expectations.
4. Deliver the payload to a victim through a link, message, redirect, or attacker-controlled application content.
5. Victim opens the crafted content while authenticated or otherwise trusted by the application.
6. Malicious JavaScript executes in the vulnerable application's browser context.
7. Attacker steals accessible data, modifies displayed content, or performs unauthorized actions as the victim.

How to detect it

Review historical web server, reverse proxy, WAF, CDN, and application logs for requests to non-HTML endpoints containing script-like payloads or encoded HTML/JavaScript metacharacters. Focus on endpoints returning JSON, JavaScript, XML, text, CSV, or other non-HTML content where request parameters are reflected in the response. Look for common XSS probes such as script tags, event-handler attributes, javascript: URLs, SVG-based payloads, encoded angle brackets, and CSP-bypass testing strings. Correlate suspicious requests with subsequent authenticated user activity, unusual account changes, unexpected data export, session anomalies, or reports of abnormal page behavior. Browser-side execution may not leave server-side evidence beyond the initial malicious request, so include WAF alerts, CSP violation reports if collected, user reports, and endpoint telemetry in the investigation.

• <script
• %3Cscript
• </script>
• %3C%2Fscript%3E
• javascript:
• onerror=
• onload=
• <svg
• %3Csvg
• alert(
• document.cookie
• document.domain
• eval(
• fetch(
• XMLHttpRequest
• Content-Security-Policy-Report-Only
• csp-report
• X-Content-Type-Options

What your security team should do

• Inventory internet-facing and internal Rails applications and identify any using Action Pack 5.2.x or distribution packages flagged as affected.
• Prioritize patching applications that accept user-generated content, expose public endpoints, or handle sensitive user data.
• Upgrade Action Pack/Rails through the application dependency manager or apply the operating system vendor security update for packaged deployments.
• Add regression tests for non-HTML responses containing user-controlled input to prevent future CSP-bypass XSS patterns.
• Harden response headers, especially Content-Type and X-Content-Type-Options: nosniff, and review CSP as defense in depth.
• Search web, WAF, CDN, and application logs for suspicious reflected-script probes or unusual requests to non-HTML endpoints.
• If exploitation is suspected, review affected user sessions, revoke exposed tokens where applicable, and investigate suspicious user-initiated actions during the exposure window.