GHSA-8678-w3jw-xfc2 CVE-2026-57234
Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247
- Severity
- 2.6 / 10
- Low · CVSS 3.1
- Exploit chance (EPSS)
- 0.20%
- Chance of exploitation in the next 30 days. Higher than 9.69% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-178 Improper Handling of Case Sensitivity
- CWE-184 Incomplete List of Disallowed Inputs
- CWE-611 Improper Restriction of XML External Entity Reference
- Fix
1.19.4- Upgrade nokogiri to this version or later
Description
Summary
The NONET parse option, which Nokogiri turns on by default for Nokogiri::XML::Schema (see CVE-2020-26247), was not correctly enforced on the JRuby implementation. As a result, a schema parsed with default options could still cause external resources to be fetched over the network, potentially enabling SSRF or XXE attacks.
Nokogiri 1.19.4 replaces the scheme denylist with an allowlist. When NONET is enabled, only local resources (a file: scheme, or a relative or absolute path with no scheme) are resolved, and every network scheme is blocked, case-insensitively. This brings the JRuby behavior in line with CRuby.
Only the JRuby implementation is affected. CRuby is not affected, because libxml2's xmlNoNetExternalEntityLoader blocks all network schemes at the I/O layer regardless of scheme or case.
Severity
The Nokogiri maintainers have evaluated this as low severity (CVSS 2.6, CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N). It is a bypass of CVE-2020-26247, which was scored the same way.
Mitigation
Upgrade to Nokogiri 1.19.4 or later.
There are no known workarounds for affected versions.
This change properly enforces NONET on JRuby, which is a breaking change for any code that (perhaps unknowingly) relied on the previous behavior to load network resources with default parse options. If you trust your input and want to allow external resources to be accessed over the network, you can explicitly disable NONET, exactly as documented for CVE-2020-26247:
- Ensure the input is trusted. Do not enable this option for untrusted input.
- Pass a
Nokogiri::XML::ParseOptionswith theNONETflag turned off:
# allows resources to be accessed over the network for trusted input
schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)
References
Credit
This issue was responsibly reported by @bilerden.
Affected versions
RubyGems
| Package | Vulnerable | Fixed in |
|---|---|---|
| nokogiri | < 1.19.4 |
1.19.4 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
nokogiri RubyGems → 1.19.4
- bundler
bundle update nokogiri # Gemfile: gem "nokogiri", ">= 1.19.4"
Severity breakdown
CVSS 3.1 2.6
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- Low
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Weakness
CWE-178: Improper Handling of Case Sensitivity
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
How to prevent it
- Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CWE-184: Incomplete List of Disallowed Inputs
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
How to prevent it
- Implementation: Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
CWE-611: Improper Restriction of XML External Entity Reference
The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.
How to prevent it
- Implementation, System Configuration: Many XML parsers and validators can be configured to disable external entity expansion.
References
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-phwj-rprq-35pp Nokogiri: Possible Use-After-Free when setting an attribute value via `Nokogiri::XML::Attr#value=` or `#content=` | High | Also affects nokogiri |
| GHSA-wfpw-mmfh-qq69 Nokogiri: Possible Use-After-Free in XInclude Processing | Low | Also affects nokogiri |
| GHSA-p67v-3w7g-wjg7 Nokogiri: Possible Use-After-Free when directly using `NokogirI::XML::XPathContext` beyond document lifetime | Medium | Also affects nokogiri |
| GHSA-wjv4-x9w8-wm3h Nokogiri: Possible Use-After-Free when setting `Document#root=` to an invalid node type | Medium | Also affects nokogiri |
| GHSA-5prr-v3j2-97mh Nokogiri: Possible Out-of-Bounds Read in `Nokogiri::XML::NodeSet#[]` | High | Also affects nokogiri |
| GHSA-9cv2-cfxc-v4v2 Nokogiri: Null Pointer Dereference calling methods on uninitialized wrapper classes | High | Also affects nokogiri |
| GHSA-5v8h-3h3q-446p Nokogiri: Possible Use-After-Free when `Nokogiri::XML::Document#encoding=` raises an exception | High | Also affects nokogiri |
| GHSA-v2fc-qm4h-8hqv Nokogiri XSLT transform has a memory leak | Medium | Also affects nokogiri |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor