A database version printed during a patch project may not match every copy of MariaDB in an environment. Containers, managed services, embedded appliances, and recovery images can run different builds. CVE-2026-85745 makes build provenance part of vulnerability response because six release lines are affected and an older image can return during an otherwise successful deployment.
The flaw is an out-of-bounds read in ST_Area() when MariaDB processes an invalid WKB MultiPolygon. The parser advances past a nested geometry header without first confirming enough input remains. A low-privilege authenticated SQL user can reach the path, and the base CVSS score is 4.3.
Know which MariaDB is running
The vendor lists affected versions from 10.6.1 through 10.6.27, 10.11.1 through 10.11.18, 11.4.1 through 11.4.12, 11.8.1 through 11.8.8, 12.3.1 through 12.3.2, and 13.0.1. The fixes are 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2.
For a native installation, query the running server version and retention path. For a container, connect the service label to the exact image digest, then inspect the binary version inside that image. For a managed service, retain the provider's patch notice and maintenance record. For an appliance, ask the vendor how its bundled MariaDB build is updated.
An inventory that records only "MariaDB" cannot answer any of those questions. Include branch, full version, package origin, image digest, deployment owner, and last verified time.
Prevent rollback to a vulnerable layer
Blue-green deployment and failover plans can reactivate old capacity. After updating production, verify that the standby, warm replica, and rollback image use a fixed MariaDB release. Automated infrastructure definitions can otherwise recreate a vulnerable process even when the current running host reports a safe version.
Store the patch evidence with the deployment object. A digest or image identifier provides stronger provenance than a screenshot of a version string, but the version check is still needed to confirm what the application actually started. Check both.
Review reachability
The vulnerability needs an authenticated session, not an anonymous query. A container that accepts public geometry uploads can still forward attacker-controlled data under its database service identity. Determine which paths call ST_Area() and whether they consume external WKB.
Disable or do not grant spatial function access to applications that do not need it. This narrows the number of reachable inputs. MariaDB says there is no workaround, so access restriction does not replace a fixed image.
Interpret external exposure
A current ZoomEye search for app="MariaDB" returned 5,116,420 matches. This is an internet product-fingerprint count. It does not reveal container digest, exact branch, or a vulnerable function path.
The Filter query vul.cve="CVE-2026-85745" returned zero. That is a scoped index observation. It is not evidence that internal or managed databases are patched, and it cannot reconcile a mixed container fleet.
Testing the service path
After upgrading an image, test ST_Area() through the same connection path used by the application. Include successful calculations for representative MultiPolygon values and clean errors for malformed WKB. Verify the result through a load balancer and one failover candidate. If the application relies on a database driver with geometry handling, confirm that it does not transform data into a format that bypasses expected validation.
Check logs for repeated parsing failures and for services still connecting with the old user, driver, or schema. A rollout that leaves an old pod in the service selector should show up in both version evidence and runtime error data.
Completion evidence
The fixed release must be present in every place ST_Area() can execute. For a container platform, that means image provenance, running digest, service version, and redeployment behavior. For a managed service, it means a provider confirmation and an application-level check. For a recovery path, it means proof that restored capacity still runs the fixed binary.
Red Hat's record describes the memory disclosure as supporting an ASLR bypass and a later privilege escalation chain. That makes CVE-2026-85745 a concise test of patch provenance: knowing the current host is not enough when deployment machinery can bring an older MariaDB layer back.