GHSA-48qf-xh34-q73r: Infoleak

Published Oct 8, 2026
·
Updated

Description When encoding a GeoJSON Polygon or MultiPolygon parameter for the binary protocol, the connector sized its output buffer from the length property of each ring, then wrote each ring only if it was a real array. The two loops disagreed: any non-array ring carrying a numeric length (a string, or an object such as {"length": 4000}) still reserved 4 + 16 length bytes, but wrote none of them. The buffer came from Buffer.allocUnsafe() and was returned in full regardless of how far the write position had advanced, so every reserved-but-unwritten byte was uninitialized Node.js heap.

The sibling LineString case handled this correctly, aborting with null on the first malformed point, so no reserved byte could escape unwritten.

The only gate on this path is value.type naming a GeoJSON type, so any object shaped like {"type": "Polygon", ...} reached the encoder.

Impact An application that passes an attacker-influenced object as a parameter to execute() or batch() writes uninitialized process memory into the database, where it is readable by anyone who can read that row and persists into backups and replicas. Applications accepting GeoJSON for map or location features are the natural case, as the attacker controls coordinates directly.

The disclosed memory is not scoped to the requesting user: in a shared Node.js process the heap may hold other users' request and response bodies, session tokens and cookies, database credentials and TLS key material. The leak is silent — the insert succeeds and the column simply holds more bytes than it should.

No non-default connector option and no particular server configuration are required. query() is not affected: the text encoder builds geometry as strings rather than through Buffer.allocUnsafe().

Resolution Both the Polygon and MultiPolygon encoders now reject a non-array ring before reserving space for it, so no byte of the allocation can be left uninitialized by the writing loop, matching the existing LineString behaviour.

Workarounds Validate that GeoJSON coordinates are properly nested arrays of numbers before passing the object as a parameter, or use query(), until upgraded.

Affected Software

4 affected componentsFixes available
npm/mariadb>=3.5.0-rc.0<3.5.4
3.5.4
npm/mariadb>=3.4.0<3.4.7
3.4.7
npm/mariadb>=3.3.0<3.3.4
3.3.4
npm/mariadb<3.2.5
3.2.5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/mariadb to a version that resolves this vulnerability.

    Fixed in 3.5.4
  2. Upgrade

    Upgrade npm/mariadb to a version that resolves this vulnerability.

    Fixed in 3.4.7
  3. Upgrade

    Upgrade npm/mariadb to a version that resolves this vulnerability.

    Fixed in 3.3.4
  4. Upgrade

    Upgrade npm/mariadb to a version that resolves this vulnerability.

    Fixed in 3.2.5
  5. Compensating control

    Validate that GeoJSON coordinates are properly nested arrays of numbers before passing Polygon or MultiPolygon objects as parameters, or use query() instead; query() is not affected.

Event History

Oct 8, 2026
Advisory Published
via GitHub·07:42 PM
Data Sourced
via GitHub·07:42 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which applications are exposed in practice?

Applications are exposed if they pass attacker-influenced objects to execute() or batch() as GeoJSON Polygon or MultiPolygon parameters. Map or location features that accept GeoJSON are specifically relevant.

2

What must an attacker provide to trigger the leak?

The attacker needs to supply an object whose type names a GeoJSON Polygon or MultiPolygon and whose rings include a non-array value with a numeric length property. Examples include a string or an object such as {"length": 4000}.

3

Where can leaked data be accessed after exploitation?

The uninitialized process memory is written into the database value. It can be read by anyone able to read the affected row and may persist in database backups and replicas.

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