Summary
MariaDB Connector/Node.js exposes uninitialized process memory through malformed GeoJSON parameters
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.
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.
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().
CVE-2026-107383 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.2.5, 3.3.4, 3.4.7, 3.5.4); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
mariadb to 3.2.5 or later; mariadb to 3.3.4 or later; mariadb to 3.4.7 or later; mariadb to 3.5.4 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-107383? CVE-2026-107383 is a high-severity security vulnerability in mariadb (npm), affecting versions < 3.2.5. It is fixed in 3.2.5, 3.3.4, 3.4.7, 3.5.4.
- How severe is CVE-2026-107383? CVE-2026-107383 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of mariadb are affected by CVE-2026-107383? mariadb (npm) versions < 3.2.5 is affected.
- Is there a fix for CVE-2026-107383? Yes. CVE-2026-107383 is fixed in 3.2.5, 3.3.4, 3.4.7, 3.5.4. Upgrade to this version or later.
- Is CVE-2026-107383 exploitable, and should I be worried? Whether CVE-2026-107383 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-107383 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-107383?
- Upgrade
mariadbto 3.2.5 or later - Upgrade
mariadbto 3.3.4 or later - Upgrade
mariadbto 3.4.7 or later - Upgrade
mariadbto 3.5.4 or later
- Upgrade