CVE-2026-116695
Crass is a Ruby CSS parser that is compliant with the CSS Syntax Level 3 specification. Prior to 1.0.8, Crass incorrectly treats a closing p
CVSS
—
Sem CVSS
EPSS
0.4%
p29
KEV
—
Exploit Today
9
0-100
Publicado: 27 de out. de 2026 · Última mod.: 3 de nov. de 2026 · CWE-436
0.4%EPSS · 30 dias0.4%
2026-10-282026-11-07
Crass is a Ruby CSS parser that is compliant with the CSS Syntax Level 3 specification. Prior to 1.0.8, Crass incorrectly treats a closing parenthesis after an escaped backslash as escaped while consuming the remnants of a bad URL. Crass therefore keeps declarations, style rules, or at-rules inside a bad URL token even though a browser treats them as live CSS. A sanitizer that parses untrusted CSS with Crass and reserializes it without rejecting the bad URL can allow CSS used for UI redress, external resource loading, or CSS-based data exfiltration, but this issue does not enable script execution in modern browsers. This issue is fixed in version 1.0.8.
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-1185174.3 MÉD18.1%
——5The Symfony HtmlSanitizer component UrlSanitizer parses URLs differently from browsers, allowing the allowLinkHosts() and allowMediaHosts() checks to be bypassed for URLs without a well-formed authority, resulting in untrusted hosts being referenced in sanitized output in Symfony versions 6.1.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.
UrlSanitizer parses URLs with league/uri, which follows RFC 3986, while browsers follow the WHATWG URL standard. For URLs without a well-formed authority, such as http:evil.example, ///evil.example, or https://://evil.example/ the sanitizer finds no host, whereas browsers resolve them to evil.example. The guard added for CVE-2026-45066 missed the zero-slash form, and the host 0 was also skipped because PHP treats it as falsy.
This is exploitable when a host allow-list is combined with allowRelativeLinks(true) or allowRelativeMedias(true). The default configuration is not affected.2dCVE-2026-1042698.6 ALT47.3%
——14ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. From 3.0.0 until 3.0.17, ModSecurity's multipart parser does not apply the RFC 2231 filename* parameter precedence used by common Go, Python, Node.js, and Java application parsers. A Content-Disposition header can provide a benign filename parameter for ModSecurity and a different encoded filename* value that the backend prefers, causing MULTIPART_FILENAME rules and the application to make security decisions on different names. Applications that use the backend-selected name for storage, extension checks, or content-type inference can therefore receive a filename that bypassed WAF inspection. PHP's native multipart parser is not affected by this discrepancy. This issue is fixed in version 3.0.17.3dCVE-2026-103866—11.6%
——3Inconsistent interpretation of HTTP requests ('HTTP Request/Response smuggling') vulnerability in Apache Sling Engine. The engine's query/form parser accepts non-standard percent-escapes, wrong charsets, and continues request processing on such errors.
This issue affects Apache Sling Engine: before 3.0.4.
Users are recommended to upgrade to version 3.0.4, which fixes the issue.3dCVE-2026-1223109.9 CRÍ29.6%
——9Kyverno from 1.19.1 before 1.19.2 validates a Policy's context.apiCall urlPath after cleaning it but executes the raw path, whose fragment or query the Kubernetes client discards. A namespace-scoped user who can create a Policy can hide ../ segments behind # or ? to reach cluster-scoped endpoints with Kyverno's ServiceAccount, gaining cluster admin.3dCVE-2026-118516—39.0%
——12The Symfony Routing components CompiledUrlMatcher and UrlMatcher interpret the host and path information differently, allowing path-based authorization rules to be bypassed in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.
For routes that define a host, CompiledUrlMatcher matches the string $host.'.'.$pathinfo against the host regular expression followed by the path regular expression, while UrlMatcher matches the host and the path separately. A host placeholder can therefore match /, and consume the beginning of the path, so the request is routed to a controller, while UrlMatcher would find no route. Rules that look at the path, such as access_control entries and firewall patterns, are evaluated against the actual request path, so they do not apply while the controller of the route runs, potentially allowing an unauthenticated request to reach a protected controller. For example, with the route /admin/report/{id}, the host app.{domain} and the rule access_control: [{ path: ^/admin, roles: ROLE_ADMIN }], an anonymous request for /admin/report/1 is sent to the login page. A request with the Host header app and path /x./admin/report/1 instead reaches the controller, with domain="/x". With the required domain: .+, the real hostname works: app.example.com and /x./admin/report/1 match with domain="example.com./x".
Applications are affected if they have routes with host placeholders protected by path-based rules. With the default requirement, the Host header must be the host of the route without its last labels, such as app: framework.trusted_hosts blocks that, while a web server that only serves known names may not, for instance, Nginx passing the raw Host header to FastCGI for a request line that carries an absolute URI. If the requirement accepts /, such as .+, a real hostname works, and trusted_hosts does not help.2dCVE-2026-120635—9.7%
——3CGI versions before 5.00 for Perl allow form fields to be smuggled past proxies and WAFs via multipart parsing that differs from the RFCs.
The multipart/form-data parser matches the boundary anywhere rather than at the start of a line, uses the boundary without its leading -- for some client-supplied User-Agent values, finds the Content-Disposition name and filename inside the quoted values of other parameters, and corrupts parts when the boundary nears the 4096-byte read size.4d