Crass EUVD-2026-114323

The consuming application must use Crass (< 1.0.7) to parse attacker-supplied CSS with the default configuration - specifically with :preserve_comments NOT enabled (false), which is the default. The attacker supplies a stylesheet containing a very large number of adjacent CSS comments (crash observed empirically above ~12,000 comments). LIMITING FACTORS: exploitation is avoided entirely by setting :preserve_comments => true (recursion does not occur when comments are preserved) or by upgrading to 1.0.7; the application must actually pass untrusted CSS through Crass; and the resulting SystemStackError is a catchable Ruby exception, limiting impact to a parse-time crash rather than lasting corruption.

This is a denial-of-service vulnerability (CWE-674, uncontrolled recursion) in the Crass Ruby CSS parser, not an information-disclosure issue as the input tag suggests. No CVSS score or vector was supplied by the input, so attack-vector, complexity, and privilege signals must be inferred from the description rather than confirmed. There is no EPSS score, no CISA KEV listing, and no verified public exploit reference in the provided data - the regression test in the patch commit demonstrates the crash internally but is not published exploit code. The vuln.today decision label is 'this_month', consistent with a moderate-severity availability bug rather than an emergency. Real-world risk is bounded: the impact is a recoverable SystemStackError (a thrown Ruby exception, not memory corruption or code execution), and exploitation requires that the consuming application feed attacker-controlled CSS to Crass under its default (comments-discarded) configuration. The vendor itself rates this Moderate. Net: a genuine but low-to-moderate DoS, worth patching on a normal cycle; it is not a high-urgency, actively-exploited threat on the available evidence.

An application that uses Crass (directly or via a CSS/HTML sanitizer) to parse user-supplied stylesheets under the default configuration accepts a stylesheet consisting of a very large run of adjacent comments (crash observed empirically above roughly 12,000 comments). Crass discards each comment by recursively consuming the next token, so the long run exhausts the Ruby call stack and raises SystemStackError, aborting the parse. No public, verified exploit code is identified at time of analysis, though the mechanism is fully described in the advisory.