CVE-2026-53727

Summary

Ruby CSS Parser: SSRF and Local File Disclosure in `CssParser::Parser#read_remote_file`

Severity

high

EPSS

0.4% (p30)

CWE

CWE-918

Also known as

GHSA-9pmc-p236-855h

Published

2026-07-09

Updated

2026-07-09

Advisory details

Summary

CssParser::Parser#read_remote_file (and therefore load_uri!, and the @import-following branch of add_block!) issues HTTP/HTTPS requests against any host, port and URI it is handed, with no scheme allowlist, no host / IP filtering, and no protection against link-local, loopback or RFC‑1918 addresses. Location: redirects are followed recursively back into the same function, which also services file:// URIs, so a single attacker-controlled HTTP redirect upgrades the bug from SSRF to arbitrary local file disclosure.

In practice, any consumer of css_parser that hands it attacker‑influenced CSS together with a base_uri: option — Premailer being the canonical example — is exposed. The attacker only needs the ability to land one @import url(...) in the CSS that the host application parses.

Vulnerable code

lib/css_parser/parser.rb#L613-L687:

def read_remote_file(uri) # :nodoc:
  ...
  begin
    uri = Addressable::URI.parse(uri.to_s)

    if uri.scheme == 'file'
      # local file
      path = uri.path
      path.gsub!(%r{^/}, '') if Gem.win_platform?
      src = File.read(path, mode: 'rb')        # <-- arbitrary local read
    else
      # remote file
      if uri.scheme == 'https'
        uri.port = 443 unless uri.port
        http = Net::HTTP.new(uri.host, uri.port)
        http.use_ssl = true
      else
        http = Net::HTTP.new(uri.host, uri.port)  # <-- arbitrary host:port
      end

      res = http.get(uri.request_uri, ...)
      ...
      elsif res.code.to_i >= 300 and res.code.to_i < 400
        unless res['Location'].nil?
          return read_remote_file Addressable::URI.parse(...)  # <-- cross-scheme redirect
        end
      end
    ...

There is no validation of uri.host, uri.scheme, or the resolved IP address — neither before the HTTP request, nor before the recursive call on the Location header.

The user-facing entry points that reach this sink are:

• Parser#load_uri! — directly calls read_remote_file (line 513).
• Parser#add_block! — when invoked with base_uri: and the default import: true, scans the CSS for @import url(...) rules and resolves each one through load_uri! (line 150).

Threat model and scope

File-disclosure scope (cross-scheme redirect leg)

The file:// branch of read_remote_file does an unconditional File.read, but the contents are then handed back to add_block! and fed through the CSS tokenizer (parse_block_into_rule_sets!). Only content that fits the grammar at the lexer level survives:

• Selector slot — any text accumulated before the next { becomes the selector for that rule (including text spanning multiple lines).
• Declarations slot — only prop: value; pairs inside { ... } are retained. The Declarations parser splits on ;, requires :, and drops anything else (rule_set.rb#L655-L681).
• A rule is only added when the raw declarations string between { and } is non-empty (parser.rb#L396).

Empirical results against vulnerable 2.2.0 with Location: file://<path>:

In practice this means high-value targets that aren't CSS-shaped — TLS keys, SSH keys, JWTs, .env files (KEY=VALUE lines), /etc/passwd, binary content — do not leak their bytes through the parser API. Configuration files written in block-style DSLs (nginx, HCL/Terraform, Caddy, etc.) leak heavily. The File.read itself always executes, which is enough to (a) act as a file-existence oracle and (b) cause resource exhaustion on large pseudo-files like /dev/zero.

The stronger recovery channel is the SSRF leg, not file disclosure: when the response comes from an internal HTTP service, Premailer-style consumers serialize the parsed CSS back into rendered HTML/email output, and any CSS-shaped bytes in the response surface there.

Is it "blind"?

It is not a classic blind SSRF. The bug has two recovery channels:

1. Application output. The library is most commonly driven by Premailer, which writes the parsed CSS back into the rendered HTML. Any response bytes that happen to form CSS rules are emitted into the output document and therefore visible to whoever receives the rendered output. Internal endpoints frequently return content that parse

References

• https://github.com/advisories/GHSA-9pmc-p236-855h
• https://github.com/premailer/css_parser/security/advisories/GHSA-9pmc-p236-855h
• https://github.com/rubysec/ruby-advisory-db/blob/master/gems/css_parser/CVE-2026-53727.yml
• https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-53727

Related advisories

• CVE-2026-44312 — medium · RubyGems/css_parser
• CVE-2026-75856 — critical · crates.io/deepseek-tui
• CVE-2026-71428 — critical · PyPI/unstructured
• CVE-2026-64849 — critical · PyPI/mlflow
• CVE-2026-73080 — critical · Go/github.com/seaweedfs/seaweedfs
• CVE-2026-54725 — critical · Go/github.com/bank-vaults/vault-secrets-webhook
• CVE-2026-67426 — critical · PyPI/flyto-core
• CVE-2026-54735 — critical · Go/github.com/prebid/prebid-server/v4

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Summarize with AI

ChatGPTClaudePerplexity