Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When parsing an input containing non-ASCII characters, inefficiencies in how Crass tracks the positions of multi-byte characters result in superlinear parsing time. An attacker-controlled input consisting of many non-ASCII characters could cause excessive CPU consumption and potentially denial of service. Patches This is fixed in Crass 1.0.7. Workarounds Avoid passing non-ASCII input to Crass. Or cultivate patience.
Recommended action: Upgrade to 1.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the `:preserve_comments` option is not enabled (which is the default behavior), Crass discards CSS comments by recursively consuming the next token. An attacker who provides a stylesheet containing a very large number of adjacent comments can cause excessive recursion and trigger a `SystemStackError`. Patches This is fixed in Crass 1.0.7, which no longer recurses when discarding comments. Workarounds Set the `:preserve_comments` option to `true` if this is acceptable to your use case (recursion doesn't occur when comments are preserved).
Recommended action: Upgrade to 1.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Crass recursively parses CSS simple blocks and functions without a depth guard. An attacker-controlled value containing many deeply nested blocks can recurse until Ruby raises `SystemStackError: stack level too deep`, or can cause excessive memory usage. Patches This is fixed in Crass 1.0.7, which adds a configurable depth limit with a conservative default. Workarounds Add `SystemStackError` handling around Crass calls in your application. Buy more RAM.
Recommended action: Upgrade to 1.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Crass's tokenizer didn't terminate a bad URL token at a `)` that followed an escaped backslash (`\\`). As a result, Crass consumed more input as part of the bad URL than a spec-compliant browser does. CSS sanitizers that parse untrusted CSS with Crass and re-emit it could be tricked into passing through declarations, style rules, or at-rules (including `@import`) that the sanitizer would otherwise have removed, but that a browser would then parse and apply. Details While consuming the remnants of a bad URL (CSS Syntax Level 3, §4.3.15), Crass checked whether the *previously consumed* code point and the next code point formed a valid escape, in addition to checking the next two unconsumed code points. After an escaped backslash, the previously consumed code point is a backslash, so a following `)` was incorrectly treated as escaped and the bad URL token continued until the next unescaped `)` or the end of the input. Browsers terminate the bad URL at that `)`, so…
Recommended action: Upgrade to 1.0.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Crass converts CSS scientific notation number values with unbounded exponentiation before it clamps the result to Float::MAX. Applications that use Crass to parse attacker-controlled CSS strings can be forced to spend disproportionate CPU and memory parsing a tiny input, possibly resulting in a crash. Patches This is fixed in Crass 1.0.7. Related - https://github.com/rubysec/ruby-advisory-db/blob/master/gems/crass/GHSA-6wmf-3r64-vcwv.yml
Recommended action: Upgrade to 1.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.