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

Published Nov 1, 2026
·
Updated

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.boundedmatch?/2 runs schema regexes with a backtracking budget but calls :re.run/3 without :reporterrors, 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.boundedmatch?/2 in lib/jsv/helpers/regexext.ex runs each schema regex through :re.run/3 with matchlimit and matchlimitrecursion set to 10000 + 50 bytesize(subject), capped at 10,000,000. The call omits :reporterrors, so PCRE's matchlimit 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.validatekeyword/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.

Other sources

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.boundedmatch?/2 runs schema regexes with a backtracking budget but calls :re.run/3 without :reporterrors, 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.

— OSV

Affected Software

1 affected componentFixes available
erlang/jsv>=0.1.0<0.26.2
0.26.2

Event History

Nov 1, 2026
CVE Published
via OSV·01:29 PM
Data Sourced
via OSV·01:29 PM
DescriptionSeverityWeakness
Data Sourced
via OSV·01:29 PM
Affected Software
Data Sourced
via NVD·02:18 PM
DescriptionSeverityWeakness

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203