A boost too large for a float parses to Infinity and both query parsers throw IllegalArgumentException

The classic and flexible query parsers read the boost after ^ as the grammar's NUMBER token, digits with no length limit, and convert it with Float.parseFloat. For a literal of 2^128 - 2^103 = 340282356779733661637539395458142568448 or more (39 digits), Float.parseFloat returns Infinity without throwing, so QueryParserBase.handleBoost's "invalid boost means no boost" catch never runs. new BoostQuery(q, Infinity) then throws IllegalArgumentException("boost must be a positive float, got Infinity"), and parse(), which declares only ParseException and converts only ParseException, TokenMgrError and TooManyClauses, lets it through. The flexible StandardQueryParser builds a BoostQueryNode with value Infinity and hits the same exception in BoostQueryNodeBuilder.build instead of a QueryNodeException. The same literal after ~ already gets the declared exception in both parsers. No query is built, so nothing is matched or scored wrongly: only the exception type is wrong, and the trigger is contrived. BoostQuery's finite check came with LUCENE-7996 in 8.0.0, which did not touch the parsers; 7.x silently built (f:lucene)^Infinity. A Float.isFinite check in handleBoost and in BoostQueryNodeBuilder fixes both parsers.

• Classic parser: org.apache.lucene.queryparser.classic.QueryParser (and its subclasses MultiFieldQueryParser, ComplexPhraseQueryParser); parse(String) documents @throws ParseException if the parsing fails.
• Flexible parser: StandardQueryParser (and PrecedenceQueryParser), which parses in three phases (syntax, processing, build); parse(String, String) documents @throws QueryNodeException.
• Float.MAX_VALUE: about 3.4028235e38. A decimal literal of 2^128 - 2^103 = 340282356779733661637539395458142568448 or more rounds to Infinity; one less rounds to Float.MAX_VALUE.

1. The boost token is <NUMBER: (<_NUM_CHAR>)+ ( "." (<_NUM_CHAR>)+ )? > in both grammars (QueryParser.jj:218, StandardSyntaxParser.jj:160).
2. Classic handleBoost (QueryParserBase.java:813-831) does f = Float.parseFloat(boost.image) (:817) inside a catch whose comment says an invalid boost "defaults to no boost" (:821-823). On overflow Float.parseFloat returns Infinity and does not throw, so that fallback never runs, and q = new BoostQuery(q, f) (:828) throws.
3. BoostQuery's constructor (BoostQuery.java:40-41): if (Float.isFinite(boost) == false || Float.compare(boost, 0f) < 0) throw new IllegalArgumentException("boost must be a positive float, got " + boost);.
4. parse() (QueryParserBase.java:129-146) converts only ParseException | TokenMgrError and TooManyClauses into ParseException, so the IllegalArgumentException leaves parse() unwrapped.
5. Flexible: the Boost production builds new BoostQueryNode(node, parseFloat(boost)) with no check (StandardSyntaxParser.jj:701), and BoostQueryNodeBuilder.build (:48) calls new BoostQuery(...) with Infinity. The neighbouring FuzzyOp production validates its number and throws ParseException (StandardSyntaxParser.jj:716-724), as classic handleBareFuzzy does (QueryParserBase.java:786-795).

Stock main 645d4fe14a20, StandardAnalyzer, default field f (a small probe, not the repro):

classic  a^3                -> (f:a)^3.0
classic  a^<Float.MAX_VALUE> -> (f:a)^3.4028235E38
classic  a^<2^128-2^103>    -> java.lang.IllegalArgumentException: boost must be a positive float, got Infinity
classic  a^<39 nines>       -> java.lang.IllegalArgumentException: boost must be a positive float, got Infinity
flexible a^<39 nines>       -> java.lang.IllegalArgumentException: boost must be a positive float, got Infinity
classic  a~<39 nines>       -> ParseException: Cannot parse 'a~<39 nines>': Fractional edit distances are not allowed!
flexible a~<39 nines>       -> ParseException: Syntax Error, cannot parse a~<39 nines>:

The ~ rows show only the exception type: the classic message is wrong for this input, which reaches it because Infinity satisfies fms >= 1.0f && fms != (int) fms (QueryParserBase.java:791).

The same exception for phrase, group, range, fuzzy, wildcard, regexp and *:* boosts, and in MultiFieldQueryParser, ComplexPhraseQueryParser and PrecedenceQueryParser. A stop word as the boosted term hides it: the term is analysed away, handleBoost skips the BoostQuery, and the^<39 nines> gives an empty query.

• Who is hit. Callers of QueryParser, MultiFieldQueryParser, ComplexPhraseQueryParser, StandardQueryParser or PrecedenceQueryParser that handle bad input with catch (ParseException e) / catch (QueryNodeException e). Default configuration, any analyzer that keeps the boosted term, every boost site.
• What it takes. A boost literal of at least 2^128 - 2^103, which is 39 digits, because the grammar has no exponent syntax. Nobody types that by accident; fuzzers and deliberately odd input produce it (rated "contrived").
• What happens. The unchecked exception bypasses the application's "bad query" handler, so depending on the application a malformed query becomes an internal error instead of a validation error. Assertions on or off make no difference.
• What does not happen. No query is returned, so nothing is matched or scored wrongly; no hang, no material resource use, no index effect, no state left behind.
• Why it can matter more later. #9064 (open) proposes bounding boosts to [2^-10, 2^10]. If BoostQuery enforced that, ordinary literals such as ^2000 would take this same path, so the parsers need their own range check anyway.
• Related, separate sites (not part of this bug). The surround parser accepts a^<39 nines> (weight Infinity) and the same exception appears later, in SrndQuery.makeLuceneQueryField. Other unchecked exceptions escape parse() for other inputs: an invalid regex (#7761) and a negative phrase slop (LFV-300).

StandardAnalyzer() no longer removes English stop words by default (LUCENE-7444), so a is kept; a stop word would hide the bug. The test sits in the classic package only to match Lucene's test layout and uses no package-private member.

What it encodes. It asserts the ParseException choice (fix A). Under the "no boost" alternative (fix B) the parser returns a query and this test fails with "Expected exception ParseException but no exception was thrown"; the assertion would then become "parse returns a query", with the same input.

As the regression test: the same test, for example as a method in TestQueryParser next to the boost tests.

cp TestHugeBoostParseException.java $LUCENE/lucene/queryparser/src/test/org/apache/lucene/queryparser/classic/
cd $LUCENE && ./gradlew :lucene:queryparser:test --tests org.apache.lucene.queryparser.classic.TestHugeBoostParseException -Ptests.seed=DEADBEEF
# assertions off: add -Ptests.asserts=false (same result)

# gradle, main 645d4fe14a20, seed DEADBEEF (assertions on; the same with -Ptests.asserts=false)
TestHugeBoostParseException > testBoostAboveFloatMaxValue FAILED
    junit.framework.AssertionFailedError: Unexpected exception type, expected ParseException but got java.lang.IllegalArgumentException: boost must be a positive float, got Infinity
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:D0011E5C370269F9]:0)
        at app/org.apache.lucene.test_framework@11.0.0-SNAPSHOT/org.apache.lucene.tests.util.LuceneTestCaseParent.expectThrows(LuceneTestCaseParent.java:1437)
        at app/org.apache.lucene.test_framework@11.0.0-SNAPSHOT/org.apache.lucene.tests.util.LuceneTestCaseParent.expectThrows(LuceneTestCaseParent.java:1418)
        at app//org.apache.lucene.queryparser.classic.TestHugeBoostParseException.testBoostAboveFloatMaxValue(TestHugeBoostParseException.java:27)

        Caused by:
        java.lang.IllegalArgumentException: boost must be a positive float, got Infinity
            at org.apache.lucene.core@11.0.0-SNAPSHOT/org.apache.lucene.search.BoostQuery.<init>(BoostQuery.java:41)
            at org.apache.lucene.queryparser.classic.QueryParserBase.handleBoost(QueryParserBase.java:828)
            at org.apache.lucene.queryparser.classic.QueryParser.Term(QueryParser.java:710)
            at org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:387)
            at org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:262)
            at org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:230)
            at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:133)

# release jars 10.6.0 and 10.5.2 (assertions on and off): the same failure (handleBoost:852 on 10.6.0, :893 on 10.5.2)

• Contract. QueryParserBase.java:127: @throws ParseException if the parsing fails. StandardQueryParser.java:274 and QueryParserHelper.java:211: @throws QueryNodeException if something wrong happens along the three phases; this exception comes from the build phase. The syntax docs say only "By default, the boost factor is 1. Although the boost factor must be positive, it can be less than 1" (classic/package-info.java:268-269): no upper bound, no failure mode. The flexible BoostQueryNode javadoc says "The boost value may vary from 0.0 to 1.0" (BoostQueryNode.java:29), a stale range that nothing enforces: flexible a^3 builds (f:a)^3.0. The BoostQuery constructor javadoc has no @throws.
• Tests. Upstream QueryParserTestBase.testBooleanQuery (:985-989) asserts that TooManyClauses comes out as a parse exception, and testException (:976-983) asserts parse exceptions for malformed text. No test expects an IllegalArgumentException from parsing query text; the module's IAE tests cover parser setters and the static MultiFieldQueryParser.parse(String[], String[], ...) overloads, which document it for arrays of different lengths.
• History. LUCENE-7996 (#9044, a8a63464e7da, 2017-12-06) touched 22 files, none under lucene/queryparser; its MIGRATE note says only "negative boosts are now rejected", which the grammar cannot produce. The issue thread and the dev@ heads-up mention neither the parsers nor infinite boosts. Before it, every 7.x release returned (f:lucene)^Infinity.
• Precedent (mixed). In LUCENE-950 (#2025, 2007) FuzzyQuery's IllegalArgumentException escaped classic parse() for foo~1. The reporter, Eleanor Joslin, wrote "An application shouldn't blow up just because a user types something silly in a search field". Grant Ingersoll (@gsingers) first wrote "this isn't really an error"; Mark Miller (@markrmiller) later wrote "it seems silly to throw the illegal arg exception in either case". It was closed "Not A Problem" in 2010, the day Robert Muir (@rmuir) noted that the 4.0 fuzzy syntax had made foo~1 legal. Not a ruling that parse() may throw IAE.

The strongest case for "not a bug" (the noise audit's first triage, and the refutation angles a tie-breaker checked): a throws ParseException clause never excludes unchecked exceptions; the input is absurd (39 digits) and the failure is loud and clear; no query is built, so no result is wrong; and other unchecked exceptions already escape parse() (#7761, LFV-300), so "always ParseException" was never achieved.

Why it fails: the input is end-user query text, for which parse() documents a parse exception as its failure, not a developer-chosen argument, and the grammar's own token accepts it. The parsers already convert a runtime failure and already reject the same literal after ~, and handleBoost intends a bad boost to mean "no boost". The loud failure is exactly what breaks a catch (ParseException e) handler. The other escapes are separate open bugs, not evidence of intent. The argument limits severity (low), not validity; the noise audit's challenger and the tie-breaker both kept the claim as Low. This is an inference from the documented contract and the code, not a maintainer ruling: a maintainer may treat it as a low-priority hardening request.

Option A was run through gradle in a scratch worktree of 645d4fe14a20 and is recommended. B and C are the alternatives a maintainer may prefer; B was checked only as a shadowed sketch, C was not tried. No open PR touches these lines.

QueryParserBase.handleBoost gets throws ParseException and a finite check after Float.parseFloat; BoostQueryNodeBuilder.build gets the same check with a QueryNodeException (two imports). Both generated callers of handleBoost already declare throws ParseException, so no generated parser changes. PrecedenceQueryParser uses the same builder; MultiFieldQueryParser and ComplexPhraseQueryParser inherit handleBoost.

// QueryParserBase.handleBoost, now declared "throws ParseException", after Float.parseFloat:
if (Float.isFinite(f) == false) {
  throw new ParseException("Boost " + boost.image + " is out of range");
}
// BoostQueryNodeBuilder.build, before the BoostQuery is built:
if (Float.isFinite(boostNode.getValue()) == false) {
  throw new QueryNodeException(
      new MessageImpl(
          QueryParserMessages.INVALID_SYNTAX, "boost out of range: " + boostNode.getValue()));
}

Trade-offs

• Matches how both parsers already treat a bad fuzzy number. Finite boosts up to Float.MAX_VALUE are unchanged. Error path only: no API, format or performance change.
• Stop words: the classic check runs before the stop-word skip, so the^<39 nines> with a stop-word analyzer now gets ParseException instead of an empty query. The flexible parser still returns MatchNoDocsQuery("") there, because its processors drop the boost node before the build phase. Moving the classic check under if (q != null) keeps the old silent behaviour and matches the flexible parser.
• The flexible message carries the float (Syntax Error: boost out of range: Infinity), because the node keeps only the value. A check in the Boost production (StandardSyntaxParser.jj:701, like FuzzyOp) could quote the literal, but the generated parser would have to be regenerated.
• The flexible check sits in the builder, so it also sees a non-finite boost from configuration rather than query text (a field boost set with StandardQueryParser.setFieldsBoost becomes a BoostQueryNode in BoostQueryNodeProcessor.java:54-57); an infinite one would then give QueryNodeException instead of IllegalArgumentException (by reading, not run).
• The surround parser's separate gap is not covered.

What the checks validated

Gradle with JDK 25 in a scratch worktree of 645d4fe14a20 (removed afterwards), seed DEADBEEF:

• the repro fails on the stock build and passes with the fix, assertions on and off;
• :lucene:queryparser:test: 31 classes, 534 tests, 0 failures, 1 skipped (in TestQPHelper), incl. TestQueryParser 73, TestStandardQP 46, TestQPHelper 38, TestPrecedenceQueryParser 16, TestMultiFieldQueryParser 15, TestComplexPhraseQuery 11;
• :lucene:queryparser:check -x test with the repro in place: BUILD SUCCESSFUL (formatting, ecj lint, forbidden APIs, the three javacc checksum checks);
• outcomes: a^3 and a^<Float.MAX_VALUE> unchanged; a^<39 nines> gives ParseException: Cannot parse 'a^<39 nines>': Boost <39 nines> is out of range (classic) and QueryNodeException: Syntax Error: boost out of range: Infinity (flexible).

Set f = 1.0f when Float.parseFloat returns a non-finite value (and the same in the flexible parser).

Trade-offs

Never fails and matches the code's stated intent for an invalid number, but the user's boost is silently ignored, the flexible parser needs its own change, and the repro's assertion must become "parse returns a query".

What the checks validated

Classic only, as a shadowed class: a fix-agnostic variant of the test passes, and the ParseException test fails as expected. The module suite was not run.

Catch IllegalArgumentException in QueryParserBase.parse (and in the flexible QueryParserHelper.parse) and rethrow it as ParseException / QueryNodeException, as parse() already does for TooManyClauses.

Trade-offs

Also fixes the other escapes of the same kind (#7761 invalid regex, LFV-300 negative slop) in one change, but is broader: an IAE from a bug in a custom subclass or analyzer would also be reported as a syntax error. Not tried.

Method: non-formal (the study's fuzzing baseline, then code reading and executed tests). The study's QueryParserFuzzer (Jazzer, about 470 k executions over three runs) checked that the classic, flexible and simple parsers throw only their documented exception and that parsed queries survive toString, equals, count and rewrite; it reported five query-parser findings, this one among them (a boost of nines that parses to Infinity). The finding was blind: the fuzzer's oracle did not name boosts.

A study verifier then wrote its own deterministic 11-method JUnit test from scratch (2 contract tests fail, 9 characterisation tests pass), found the exact threshold, the other parsers and boost sites and the stop-word mask, and ran it across versions (7.7.3 builds (f:lucene)^Infinity; 8.0.0 to main throw). The 2026-10-29 noise audit replaced that class with the one-test repro, and on 2026-11-01 a reproducer and a tie-breaker re-ran it on main and on the release jars.