EEF-CVE-2026-117680

    Dashboard / Vulnerabilities / EEF-CVE-2026-117680

    EEF-CVE-2026-117680

    Published: 1 Nov 2026Last Modified: 1 Nov 2026

    Summary: jsv treats regex match budget exhaustion as a non-match, bypassing patternProperties and not

    Details: ## Summary Improper Check for Unusual or Exceptional Conditions vulnerability in the `pattern` and `patternProperties` keywords in lud jsv allows an unauthenticated remote attacker to bypass schema validation via a string that matches a schema regex only after heavy backtracking. `JSV.Helpers.RegexExt.bounded_match?/2` runs schema regexes with a backtracking budget but calls `:re.run/3` without `:report_errors`, so a match that exhausts the budget returns the same `:nomatch` as a real non-match. A key that matches a `patternProperties` regex is then checked against `additionalProperties` or not at all, and a string that matches a `not` subschema with a `pattern` is accepted. Before the budget existed, `Regex.match?/2` failed the same way at Erlang's default match limit. Only schemas whose regex explores a catastrophic branch before the branch that matches are affected. The attacker controls the data, not the schema, and linear patterns never exhaust the budget. This issue affects jsv: from 0.1.0 before 0.26.2. ## Details **1. Bounded matching.** `JSV.Helpers.RegexExt.bounded_match?/2` in `lib/jsv/helpers/regex_ext.ex` runs each schema regex through `:re.run/3` with `match_limit` and `match_limit_recursion` set to `10_000 + 50 * byte_size(subject)`, capped at 10,000,000. The call omits `:report_errors`, so PCRE's `match_limit` error is returned as `:nomatch`. The function compares the result to `:match` and returns `false` for a genuine non-match and for an exhausted budget alike. **2. Keyword evaluation.** `JSV.Vocabulary.V202012.Validation.validate_keyword/3` uses the result for `pattern`, and `JSV.Vocabulary.V202012.Applicator` uses it to decide which `patternProperties` subschemas apply to each key. The draft 7 vocabulary delegates to the same modules. A `false` from an exhausted budget therefore means a `pattern` keyword fails and a `patternProperties` subschema is skipped. **3. Inversion by combinators.** Under `not`, `anyOf`, `oneOf`, `if` and `contains`, a failing subschema can make the parent succeed, so a false non-match under `not` accepts a string the deny-list should reject. Under `patternProperties` the skipped subschema means the value is checked against `additionalProperties` or nothing. **4. History.** Before the budget was introduced, the same keywords called `Regex.match?/2`, which also returns `false` on Erlang's default limit of 10,000,000 steps. The budget lowered the input size needed from about 25 bytes to about 20 bytes for the advisory's pattern. ## Proof of concept 1. Build a schema with `patternProperties` mapping the regex `^(?:(a+)+b|a+!)$` to `{"type": "integer"}`. 2. Submit an object whose only key is twenty `a` characters followed by `!` and whose value is the string `not an int`. The key matches the regex through its second alternative, but PCRE exhausts the 11,050-step budget in the first alternative. 3. `JSV.validate/2` returns `:ok`. The value is never checked against the subschema. 4. Build a second schema `{"not": {"pattern": "^(?:(a+)+b|a+!)$"}}` and submit the same string. `JSV.validate/2` returns `:ok` although the string matches the denied pattern. 5. Repeat with the short key `aaa!`. Both schemas now reject the data as expected. ## Impact An attacker pads a string until its match exhausts the budget, so a value under a `patternProperties` key skips its subschema or a string passes a `not` deny-list. The application then accepts input its schema should reject. ## Workarounds Pair `patternProperties` with `additionalProperties: false`. A key whose match exhausts the budget is then rejected instead of accepted unchecked. Valid keys that need heavy backtracking are rejected as well. Write schema regexes without nested quantifiers or overlapping alternatives, and do not express deny-lists as a `not` subschema with a `pattern` on untrusted input. ## Configurations The schema must contain a `pattern` or `patternProperties` regex that PCRE can match only after exploring a catastrophic branch first, such as a nested quantifier in an earlier alternative. Linear patterns never exhaust the budget. The attacker controls the validated data but not the schema.

    Affected packages

    Package

    Name: jsv

    Purl: pkg:hex/jsv

    Affected ranges

    Type: SEMVER

    Events:

    Introduced- 0.1.0
    Fixed -0.26.2

    Affected versions

    0.1.0

    Common Vulnerability Scoring System

    Attack Vector
    Network
    Adjacent
    Local
    Physical
    Privileges Required
    None
    Low
    High
    User Interaction
    None
    Required
    Scope
    Unchanged
    Changed
    Confidentiality
    None
    Low
    High
    Integrity
    None
    Low
    High
    Availability
    None
    Low
    High