Sparklemotion
Monthly
Denial-of-service in Nokogiri before 1.19.3 stems from three distinct ReDoS vulnerabilities in the CSS selector tokenizer, affecting string-literal and identifier tokenization. Any Ruby application passing attacker-controlled input to `Node#css`, `Node#at_css`, `Nokogiri::CSS.xpath_for`, `Searchable#search`, or `CSS::Parser#parse` is vulnerable to exponential regex backtracking that can exhaust CPU resources and deny service. No public exploit code has been identified at time of analysis, but the unauthenticated network attack surface and low exploitation complexity make this a high-priority patch target for Nokogiri-dependent Ruby applications.
Out-of-bounds memory read in Nokogiri (CRuby) versions before 1.19.4 crashes the host Ruby process when application code incorrectly passes a non-Node argument to the protected internal `Node#initialize_copy_with_args` method. The method backs the public `Node#dup` and `#clone` APIs and, prior to 1.19.4, unwraps its argument directly as a libxml2 `xmlNode` struct without verifying the object's type, causing it to misread an `xmlNs` (Namespace) struct out of bounds. Critically, the vendor explicitly confirms this cannot be triggered by untrusted external input - only by a programming error in application code - making the provided CVSS 4.0 score of 8.7 (AV:N/PR:N) a significant overstatement of real-world risk. No public exploit has been identified at time of analysis.
Cross-origin credential leakage in the Mechanize Ruby library (versions prior to 2.14.1) allows attackers who control a redirect target to capture bearer tokens, session cookies, Proxy-Authorization credentials, or Cookie2 values that the calling application supplied through Mechanize#request_headers= or the per-request headers argument. The flaw is conditional: it only triggers when an application actually sets credentials via those header APIs and a response issues a cross-origin HTTP redirect (or a cross-origin meta refresh), so same-origin redirects are unaffected and credentials managed through Mechanize#cookie_jar or Mechanize::HTTP::AuthStore are explicitly out of scope; there is no public exploit identified at time of analysis. Because the attacker must influence the redirect destination rather than merely reach the service, this is a genuine but conditional information-disclosure issue (CWE-200) rather than a mass-exploitation priority.
Credential-header leakage in the Ruby Mechanize gem before 2.14.1 allows sensitive headers to be forwarded to a lower-trust destination during redirect following, because Mechanize::HTTP::Agent#response_redirect considered a redirect same-origin whenever the host matched, without comparing scheme or port. A same-host HTTPS-to-HTTP downgrade can put caller-supplied Authorization (or Proxy-Authorization) and Cookie (or Cookie2) headers on the wire in cleartext, and a same-host redirect to a different port can deliver a caller-supplied Cookie to an unrelated service listening there. Per the assessed vector (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) the impact is confidentiality-only with no integrity or availability effect, and no public exploit was identified at time of analysis; the practical risk is limited because the consuming application must explicitly inject its own credential headers and an attacker must control or man-in-the-middle the redirect response, while cookies held in Mechanize#cookie_jar are scoped correctly and are not leaked. Vendor-released patch: 2.14.1.
Credential leakage in the Ruby Mechanize library before 2.14.1 lets an attacker who controls page content encountered during a crawl capture bearer tokens or session cookies, because a cross-origin meta refresh caused Mechanize::HTTP::Agent#response_follow_meta_refresh to reapply the caller's global default headers to the refresh request. Exploitation is conditional and rated AC:H: Mechanize#follow_meta_refresh must be explicitly enabled (it defaults to false), the caller must have placed sensitive credentials in the agent-wide default headers via Mechanize#request_headers=, and the attacker must be able to serve attacker-controlled markup to the crawl, though the request itself is unauthenticated (PR:N) and requires no user interaction (UI:N). There is no KEV entry, no public exploit identified at time of analysis, and no EPSS score supplied; the vendor-released fix is Mechanize 2.14.1, where cross-origin meta refreshes now discard credential and cookie headers under the same origin rules as HTTP redirects.
Unchecked return value in Nokogiri's CRuby extension (versions 1.5.1 through 1.19.0) causes the `canonicalize` method to silently return an empty string on XML canonicalization failure instead of raising an exception. This silent failure propagates incorrectly to downstream SAML libraries, which have been demonstrated in practice to accept the malformed output as a valid canonicalized document, enabling signature validation bypass. The JRuby implementation is not affected; exploitation has been confirmed as demonstrated by a HackerOne researcher but is not listed in CISA KEV.
Heap memory leaks in Nokogiri's XSLT transform method (versions before 1.19.3) enable gradual denial of service against long-running Ruby applications that pass attacker-controlled input to `Nokogiri::XSLT::Stylesheet#transform` parameters containing null bytes. Each null-byte-bearing call leaks approximately 24-32 bytes of heap memory; meaningful service degradation requires sustained, high-rate malicious traffic against the specific code path. No public exploit has been identified at time of analysis, and the vulnerability is absent from CISA KEV. Notably, the VulnCheck-reported CVSS 4.0 score of 6.9 is higher than the Nokogiri maintainers' own assessment of CVSS 5.3 Moderate, reflecting scoring convention differences rather than disagreement on impact.
Use-after-free in Nokogiri's CRuby XInclude processing (versions prior to 1.19.4) can leave Ruby wrapper objects pointing at freed libxml2 memory after `#do_xinclude` is called on a document whose nodes have already been exposed to Ruby. An application that triggers this condition may experience invalid memory reads or writes, potentially resulting in a crash or memory disclosure. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.2 reflects the high attack complexity driven by an unusual, non-default API usage pattern required to reach the vulnerable code path.
Use-after-free in Nokogiri's CRuby implementation (versions prior to 1.19.4) allows an application crash via segfault when an `XML::XPathContext` object outlives its source document and that document is freed by Ruby's garbage collector. Only CRuby is affected; JRuby is not. This is not triggerable by malicious document input and cannot be reached through the standard `Document#xpath`, `#css`, or related methods - it requires an unusual direct API usage pattern in application code. No public exploit has been identified, this is not listed in CISA KEV, and the CVSS 4.0 score of 1.7 reflects the tightly constrained triggering conditions.
Heap use-after-free in Nokogiri's CRuby implementation (prior to 1.19.4) can corrupt process memory when application code assigns a DTD node as a document root via `Document#root=`. The root cause is insufficient type validation in the setter, which accepted any `Nokogiri::XML::Node` subclass rather than restricting to element nodes, leaving libxml2 in an inconsistent internal state that triggers a dangling pointer dereference during Ruby garbage collection or finalization. No active exploitation is confirmed (not in CISA KEV), no public exploit is identified, and the Nokogiri maintainers rate this low severity; the CVSS 4.0 score of 1.7 with E:U corroborates that assessment.
Use-after-free in Nokogiri's CRuby native extension (versions prior to 1.19.4) can corrupt process memory or cause a segfault when an application accesses an XML attribute's child node and subsequently replaces that attribute's value via `Attr#value=` or `#content=`. The underlying libxml2 wrapper frees the native child node while a Ruby object in the document node cache retains a stale pointer, which a later GC mark pass or direct access can dereference. With a CVSS 4.0 score of 1.7, no KEV listing, and no public exploit identified at time of analysis, real-world risk is low and constrained to application availability.
Null pointer dereference in Nokogiri prior to 1.19.4 crashes the Ruby process when application code incorrectly calls `.allocate` directly on a native-backed class inheriting from `Nokogiri::XML::Node` and then invokes methods on the resulting uninitialized object. Only CRuby is affected - JRuby is explicitly not vulnerable. No public exploit has been identified; the CVSS 4.0 base score of 1.7 with E:U accurately reflects that this defect requires a developer programming error rather than any crafted external input, placing it firmly in the low-priority category.
Out-of-bounds read in Nokogiri's `NodeSet#[]` method (all versions before 1.19.4) enables an attacker who can supply a large negative integer index to bypass a 32-bit-truncated bounds check and trigger a read outside the node set's allocated memory. On CRuby (MRI Ruby), this typically crashes the process - denial of service - with ancillary potential for heap memory disclosure; on JRuby, the runtime's managed memory prevents memory corruption, but an incorrect node is silently returned. No public exploit or active exploitation has been identified; exploitation requires the target application to forward attacker-controlled integers directly to the `NodeSet#[]` or `#slice` API.
NONET network restriction bypass in Nokogiri's JRuby implementation permits external resource fetching during XML Schema parsing despite the default network-blocking parse option being set, exposing applications to potential SSRF and XXE attacks. Only JRuby-based deployments are affected - CRuby users are fully protected because libxml2's xmlNoNetExternalEntityLoader enforces NONET at the I/O layer independently of Nokogiri's option handling. Rated low severity by maintainers (CVSS 2.6); vendor-released patch is available in version 1.19.4, and no public exploit has been identified at time of analysis.
Use-after-free in Nokogiri's CRuby (libxml2) implementation allows freed heap memory to be read on subsequent calls to Document#encoding, potentially causing a segmentation fault or leaking stale heap bytes into a Ruby String object. Versions prior to 1.19.4 are affected when the three-step exploitation pattern occurs: an invalid encoding assignment, exception rescue, and continued document use. No public exploit has been identified and this vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 1.7 accurately reflects the low real-world priority.
Denial-of-service in Nokogiri before 1.19.3 stems from three distinct ReDoS vulnerabilities in the CSS selector tokenizer, affecting string-literal and identifier tokenization. Any Ruby application passing attacker-controlled input to `Node#css`, `Node#at_css`, `Nokogiri::CSS.xpath_for`, `Searchable#search`, or `CSS::Parser#parse` is vulnerable to exponential regex backtracking that can exhaust CPU resources and deny service. No public exploit code has been identified at time of analysis, but the unauthenticated network attack surface and low exploitation complexity make this a high-priority patch target for Nokogiri-dependent Ruby applications.
Out-of-bounds memory read in Nokogiri (CRuby) versions before 1.19.4 crashes the host Ruby process when application code incorrectly passes a non-Node argument to the protected internal `Node#initialize_copy_with_args` method. The method backs the public `Node#dup` and `#clone` APIs and, prior to 1.19.4, unwraps its argument directly as a libxml2 `xmlNode` struct without verifying the object's type, causing it to misread an `xmlNs` (Namespace) struct out of bounds. Critically, the vendor explicitly confirms this cannot be triggered by untrusted external input - only by a programming error in application code - making the provided CVSS 4.0 score of 8.7 (AV:N/PR:N) a significant overstatement of real-world risk. No public exploit has been identified at time of analysis.
Cross-origin credential leakage in the Mechanize Ruby library (versions prior to 2.14.1) allows attackers who control a redirect target to capture bearer tokens, session cookies, Proxy-Authorization credentials, or Cookie2 values that the calling application supplied through Mechanize#request_headers= or the per-request headers argument. The flaw is conditional: it only triggers when an application actually sets credentials via those header APIs and a response issues a cross-origin HTTP redirect (or a cross-origin meta refresh), so same-origin redirects are unaffected and credentials managed through Mechanize#cookie_jar or Mechanize::HTTP::AuthStore are explicitly out of scope; there is no public exploit identified at time of analysis. Because the attacker must influence the redirect destination rather than merely reach the service, this is a genuine but conditional information-disclosure issue (CWE-200) rather than a mass-exploitation priority.
Credential-header leakage in the Ruby Mechanize gem before 2.14.1 allows sensitive headers to be forwarded to a lower-trust destination during redirect following, because Mechanize::HTTP::Agent#response_redirect considered a redirect same-origin whenever the host matched, without comparing scheme or port. A same-host HTTPS-to-HTTP downgrade can put caller-supplied Authorization (or Proxy-Authorization) and Cookie (or Cookie2) headers on the wire in cleartext, and a same-host redirect to a different port can deliver a caller-supplied Cookie to an unrelated service listening there. Per the assessed vector (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) the impact is confidentiality-only with no integrity or availability effect, and no public exploit was identified at time of analysis; the practical risk is limited because the consuming application must explicitly inject its own credential headers and an attacker must control or man-in-the-middle the redirect response, while cookies held in Mechanize#cookie_jar are scoped correctly and are not leaked. Vendor-released patch: 2.14.1.
Credential leakage in the Ruby Mechanize library before 2.14.1 lets an attacker who controls page content encountered during a crawl capture bearer tokens or session cookies, because a cross-origin meta refresh caused Mechanize::HTTP::Agent#response_follow_meta_refresh to reapply the caller's global default headers to the refresh request. Exploitation is conditional and rated AC:H: Mechanize#follow_meta_refresh must be explicitly enabled (it defaults to false), the caller must have placed sensitive credentials in the agent-wide default headers via Mechanize#request_headers=, and the attacker must be able to serve attacker-controlled markup to the crawl, though the request itself is unauthenticated (PR:N) and requires no user interaction (UI:N). There is no KEV entry, no public exploit identified at time of analysis, and no EPSS score supplied; the vendor-released fix is Mechanize 2.14.1, where cross-origin meta refreshes now discard credential and cookie headers under the same origin rules as HTTP redirects.
Unchecked return value in Nokogiri's CRuby extension (versions 1.5.1 through 1.19.0) causes the `canonicalize` method to silently return an empty string on XML canonicalization failure instead of raising an exception. This silent failure propagates incorrectly to downstream SAML libraries, which have been demonstrated in practice to accept the malformed output as a valid canonicalized document, enabling signature validation bypass. The JRuby implementation is not affected; exploitation has been confirmed as demonstrated by a HackerOne researcher but is not listed in CISA KEV.
Heap memory leaks in Nokogiri's XSLT transform method (versions before 1.19.3) enable gradual denial of service against long-running Ruby applications that pass attacker-controlled input to `Nokogiri::XSLT::Stylesheet#transform` parameters containing null bytes. Each null-byte-bearing call leaks approximately 24-32 bytes of heap memory; meaningful service degradation requires sustained, high-rate malicious traffic against the specific code path. No public exploit has been identified at time of analysis, and the vulnerability is absent from CISA KEV. Notably, the VulnCheck-reported CVSS 4.0 score of 6.9 is higher than the Nokogiri maintainers' own assessment of CVSS 5.3 Moderate, reflecting scoring convention differences rather than disagreement on impact.
Use-after-free in Nokogiri's CRuby XInclude processing (versions prior to 1.19.4) can leave Ruby wrapper objects pointing at freed libxml2 memory after `#do_xinclude` is called on a document whose nodes have already been exposed to Ruby. An application that triggers this condition may experience invalid memory reads or writes, potentially resulting in a crash or memory disclosure. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.2 reflects the high attack complexity driven by an unusual, non-default API usage pattern required to reach the vulnerable code path.
Use-after-free in Nokogiri's CRuby implementation (versions prior to 1.19.4) allows an application crash via segfault when an `XML::XPathContext` object outlives its source document and that document is freed by Ruby's garbage collector. Only CRuby is affected; JRuby is not. This is not triggerable by malicious document input and cannot be reached through the standard `Document#xpath`, `#css`, or related methods - it requires an unusual direct API usage pattern in application code. No public exploit has been identified, this is not listed in CISA KEV, and the CVSS 4.0 score of 1.7 reflects the tightly constrained triggering conditions.
Heap use-after-free in Nokogiri's CRuby implementation (prior to 1.19.4) can corrupt process memory when application code assigns a DTD node as a document root via `Document#root=`. The root cause is insufficient type validation in the setter, which accepted any `Nokogiri::XML::Node` subclass rather than restricting to element nodes, leaving libxml2 in an inconsistent internal state that triggers a dangling pointer dereference during Ruby garbage collection or finalization. No active exploitation is confirmed (not in CISA KEV), no public exploit is identified, and the Nokogiri maintainers rate this low severity; the CVSS 4.0 score of 1.7 with E:U corroborates that assessment.
Use-after-free in Nokogiri's CRuby native extension (versions prior to 1.19.4) can corrupt process memory or cause a segfault when an application accesses an XML attribute's child node and subsequently replaces that attribute's value via `Attr#value=` or `#content=`. The underlying libxml2 wrapper frees the native child node while a Ruby object in the document node cache retains a stale pointer, which a later GC mark pass or direct access can dereference. With a CVSS 4.0 score of 1.7, no KEV listing, and no public exploit identified at time of analysis, real-world risk is low and constrained to application availability.
Null pointer dereference in Nokogiri prior to 1.19.4 crashes the Ruby process when application code incorrectly calls `.allocate` directly on a native-backed class inheriting from `Nokogiri::XML::Node` and then invokes methods on the resulting uninitialized object. Only CRuby is affected - JRuby is explicitly not vulnerable. No public exploit has been identified; the CVSS 4.0 base score of 1.7 with E:U accurately reflects that this defect requires a developer programming error rather than any crafted external input, placing it firmly in the low-priority category.
Out-of-bounds read in Nokogiri's `NodeSet#[]` method (all versions before 1.19.4) enables an attacker who can supply a large negative integer index to bypass a 32-bit-truncated bounds check and trigger a read outside the node set's allocated memory. On CRuby (MRI Ruby), this typically crashes the process - denial of service - with ancillary potential for heap memory disclosure; on JRuby, the runtime's managed memory prevents memory corruption, but an incorrect node is silently returned. No public exploit or active exploitation has been identified; exploitation requires the target application to forward attacker-controlled integers directly to the `NodeSet#[]` or `#slice` API.
NONET network restriction bypass in Nokogiri's JRuby implementation permits external resource fetching during XML Schema parsing despite the default network-blocking parse option being set, exposing applications to potential SSRF and XXE attacks. Only JRuby-based deployments are affected - CRuby users are fully protected because libxml2's xmlNoNetExternalEntityLoader enforces NONET at the I/O layer independently of Nokogiri's option handling. Rated low severity by maintainers (CVSS 2.6); vendor-released patch is available in version 1.19.4, and no public exploit has been identified at time of analysis.
Use-after-free in Nokogiri's CRuby (libxml2) implementation allows freed heap memory to be read on subsequent calls to Document#encoding, potentially causing a segmentation fault or leaking stale heap bytes into a Ruby String object. Versions prior to 1.19.4 are affected when the three-step exploitation pattern occurs: an invalid encoding assignment, exception rescue, and continued document use. No public exploit has been identified and this vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 1.7 accurately reflects the low real-world priority.