Re: Are sonatype-2025-002050 and sonatype-2025-002284 planned for a fix?

Dawid Weiss <[email protected]> Mon, 1 Sep 2025 23:36:57 +0200
Newsgroups gmane.comp.jakarta.lucene.user
Message-ID <CAM21Rt_VEcD_eVUREr35Jmi9A_r4Da7Ou=FrDwN3Q5D1kkXVUg@mail.gmail.com>
--0000000000005f1a4a063dc42d6c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Is there any public reference to these "vulnerabilities" that we could look
at? Like many such reports,
they seem to be highly... theoretical. For example, this is what I found,
looking around the Web -

https://osv.dev/vulnerability/OSV-2023-696

if you click on the affected range of commits... it makes no sense at all.

A fuzzifier is great but without a reasonable postmortem on a crash and
perhaps a more human-palatable reproducer, it's fairly useless.

Dawid

On Mon, Sep 1, 2025 at 7:49=E2=80=AFPM Gr=C3=A9goire Gu=C3=A9ret
<[email protected]> wrote:

> Hello Lucene community team,
>
> As most tech companies do, our security department is performing automate=
d
> vulnerability scans. They identified 2 similar Sonartypes on Lucene, on
> all versions (as far as I know).
>
> I've been wondering if the Lucene team plans to fix them, but could not
> find the information on Lucene's website. Any insight or pointers to
> the proper page would be appreciated.
>
> *sonatype-2025-002050*
> *The lucene package is vulnerable due to an Improper Check for Unusual or
> Exceptional Conditions. The clone() method in the CharTermAttributeImpl
> class does not properly handle exceptional events that may occur during t=
he
> deep clone process. A remote attacker can exploit this vulnerability by
> supplying a crafted termBuffer that, upon being processed by the clone()
> function, will result in an unhandled SecurityException, potentially
> leading to Denial of Service (DoS) or other unexpected behaviors.*
>
> *sonatype-2025-002284*
> *The lucene package is vulnerable due to an Improper Check for Unusual or
> Exceptional Conditions. The normalize() method in the SoraniNormalizer
> class does not properly validate the input buffer and length parameter us=
ed
> to normalize Sorani text. A remote attacker can exploit this vulnerabilit=
y
> by supplying a specially crafted text that results in an invalid value fo=
r
> the string buffer or length parameters. This action will cause an
> unexpected exception to be thrown when the delete() operation is performe=
d,
> potentially leading to a Denial of Service (DoS) condition or other
> unexpected behaviors.*
>
> With Regards,
> Gregoire Gueret
>

--0000000000005f1a4a063dc42d6c--