Crass CVE-2026-61848

Exploitation requires that the application passes attacker-controlled input to Crass's CSS tokenizer/parser and that the input contains many non-ASCII (multi-byte) characters - this multi-byte content is the specific trigger named in the advisory. The practical condition is therefore any deployment that parses untrusted or user-supplied CSS with Crass (including indirectly via sanitization libraries that embed it). Limiting factors: impact is confined to availability/CPU with no data exposure; the effect is superlinear degradation rather than a guaranteed crash; and exploitation is only reachable if an untrusted-input parsing path exists, so applications that never feed external input to Crass are not exposed. Authentication requirements not confirmed from available data (no CVSS vector provided).

No CVSS score or vector, no EPSS probability, and no KEV listing are provided, so quantitative exploitation signals are absent and cannot be compared; the only priority signal is the vuln.today Decision label 'this_month', which places this below act_now/emergency urgency. This is a CWE-400 resource-exhaustion (denial-of-service) flaw in the Crass Ruby CSS parser: impact is limited to availability (CPU consumption), with no confidentiality or integrity consequence, so even a high-CVSS reading would overstate blast radius. The attack is low-complexity and requires no authentication where an untrusted-CSS parsing path is reachable, which raises likelihood, but the effect is superlinear slowdown ('potentially denial of service') rather than a confirmed hard crash, so real-world severity depends on how exposed the parsing path is. No public exploit identified at time of analysis and no evidence of exploitation, so this reads as a genuine but moderate availability issue to patch on a routine ('this_month') cadence rather than an emergency.

An attacker submits user-generated content - such as CSS in a profile, comment, or document - containing a large run of non-ASCII (multi-byte) characters to an application that parses it with Crass, often indirectly through a CSS sanitization pipeline. Crass's inefficient tracking of multi-byte character positions makes parse time grow superlinearly, so a single crafted input consumes disproportionate CPU and can degrade or deny service. No public exploit identified at time of analysis.