YAOOK Security Advisory for CVE-2025-14758

What is CVE-2025-14758 and how does it affect YAOOK?

CVE-2025-14758 describes the issue that MariaDB replication traffic is sent
unencrypted between MariaDB instances managed by YAOOK’s infra-operator if the
cluster is IPv6-enabled.

In 2024, YAOOK gained official support for running inside IPv6-only and
dual-stack Kubernetes clusters. For this, various services had to be updated to
allow listening on IPv6 sockets in addition to (or instead of) IPv4 sockets.

For MariaDB, there exist three communication channels: The normal client/server
traffic with MariaDB-compatible clients (such as the OpenStack APIs), the
incremental state transfer and online replication traffic (WSREP) and the SST
channel (used if, after a restart, the incremental state transfer is not
sufficient to bring a replica up-to-date).

The WSREP transfer channel is configured through a single MariaDB configuration
option called wsrep-provider-options. Before the addition of IPv6 support,
this option was set up by YAOOK exclusively through the MariaDB configuration
file. As value to that single option, one provides the path to the TLS
certificates and the listening address of the WSREP channel, formatted as string
into in a MariaDB-specific format.

When IPv6 support was implemented, the listening address of the WSREP socket had
to be changed to [::] in order to be able to accept connections from other
instances via IPv6. This was
implemented by passing an additional --wsrep-provider-options command line argument to the MariaDB process.
Unfortunately, that overrode the TLS-related options from the configuration
file, effectively disabling TLS for the WSREP channel whenever that code path
is hit.

Is my cluster vulnerable?

The affected code path is executed whenever the status.podIP field of the
MariaDB pod is an IPv6 address. This is the case in IPv6-only clusters and may
be the case in dual-stack clusters.

If that is the case, TLS encryption of the WSREP channel is disabled, which
causes almost all MariaDB contents to be transferred without encryption in
transit.

Mitigating factors

  • This vulnerability only affects IPv6-only clusters.
  • The unencrypted traffic never leaves the Kubernetes service network, which
    may or may not already be a trusted domain in your security model.

Upgrading

A new stable release with version 0.20251211.0 has been published. Affected
clusters will face a downtime during upgrades, because TLS encryption on the
WSREP channel cannot be enabled online.

During the upgrade, the highest replica of all databases managed by the
infra-operator will enter a Error / CrashLoopBackOff state. At that point, you
have to execute the following steps for each separate database instance:

  1. yaookctl pause mysqlservices $name
  2. kubectl -n yaook scale sts $name-db --replicas=0
  3. Wait for the last database replica to terminate.
  4. Optional: kubectl -n yaook scale sts $name-db --replicas=$n, where $n is
    the number of replicas you usually have. This may be slightly faster than
    waiting for the infra-operator to reset the replica count after the next
    command.
  5. yaookctl unpause mysqlservices $name

During the time the last replica of a database is shut down, the database can,
obviously, not serve requests. This will cause HTTP 500 responses from affected
API services and may have downstream adverse effects on workloads (such as
Kubernetes Cinder CSI providers running inside the cluster).

Credits

This vulnerability was found by Martin Morgenstern and Maximilian Brandt,
CLOUD&HEAT Technologies GmbH.

en_GB
en_GB