[Mobilitydb-dev] Coordinated Vulnerability Disclosure - MobilityDB / MobilityDB

[Esteban Zimanyi]

Hello,

Thank you for the report and for coordinating the disclosure.

We have reproduced the issue and confirmed the root cause described in the
report. The Well-Known Binary (WKB) bounds check in
meos/src/temporal/type_in.c added the requested length to the parse
position, so a negative or very large length read from the input, such as
the length of a text value, wrapped the pointer and passed the check. The
only other guard was an assertion, which release builds compile out. With
the reporter's payload, AddressSanitizer reports negative-size-param
(size=-1) in text_from_wkb_state.

The fix compares every read with the bytes remaining in the buffer, rejects
a negative or oversized length or count before it is used, checks that the
type code in the header names a type of the expected family, and stops
parsing at the first failed check, including when MEOS is used as a library
with an error handler that returns. We validated it with the PostgreSQL
regression suite and with sanitizer-instrumented fuzzing of the binary
input functions (several million malformed inputs per branch, with no
memory error in the WKB readers).

Affected versions: MobilityDB 1.1.x, 1.2.0, 1.2.1 and 1.3.0, and the
development branch. We are publishing the fix today on the development
branch and in patch releases of the 1.3 and 1.2 series, together with a
GitHub security advisory. Please go ahead with the CVE record; could you
send us the CVE ID so that we can add it to the advisory and the release
notes? Please also let us know how the researcher would like to be credited.

Best regards,

Esteban

------------------------------------------------------------
Prof. Esteban Zimanyi
Department of Computer & Decision Engineering  (CoDE) CP 165/15
Universite Libre de Bruxelles
Avenue F. D. Roosevelt 50
B-1050 Brussels, Belgium
fax: + 32.2.650.47.13
tel: + 32.2.650.31.85
e-mail: esteban.zimanyi at ulb.be
Internet: http://cs.ulb.ac.be/members/esteban/
------------------------------------------------------------


On Mon, Sep 28, 2026 at 3:48 PM Brandon Tarr via Mobilitydb-dev <
mobilitydb-dev at lists.osgeo.org> wrote:

>
> Greetings MobilityDB Security Team,
>
>
> I'm a vulnerability analyst at VulnCheck <https://www.vulncheck.com/> an
> exploit intelligence company and research CVE Numbering Authority (CNA),
> where I'm one of several folks who manage our coordinated vulnerability
> disclosure (CVD) program.
>
> An external security researcher recently reported
> <https://www.vulncheck.com/advisories/report> a potential vulnerability
> impacting [MobilityDB / MobilityDB
> <https://github.com/MobilityDB/MobilityDB>] and VulnCheck is acting as
> the intermediary and coordinator.
>
> VulnCheck follows a 120-day disclosure policy
> <https://www.vulncheck.com/vulnerability-disclosure-policy>, meaning we
> afford vendors/maintainers up to 120 days from the time of receiving the
> report to address the issue before publication of a CVE record and
> third-party advisory. For this vulnerability, the 120-day deadline is *January
> 26, 2027 (26/01/2027)*. Of note, patch publication constitutes public
> disclosure — if a patch is issued, we will publish the CVE record at that
> time rather than waiting for the full 120-day window.
>
> The researcher has provided us with a comprehensive technical report,
> which we have attached to this email. Let us know if you have any questions
> for us about the CVD process or for the researcher regarding the reported
> vulnerability.
>
> --
> Thank you,
>
> <https://www.vulncheck.com/>
>
> Brandon Tarr
> VulnCheck
> _______________________________________________
> Mobilitydb-dev mailing list
> Mobilitydb-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mobilitydb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20260929/ef143551/attachment.htm>