Summary: 

Self-hosted Redpanda customers configure the certificate chain through both node and cluster level config, although the system CA can be used as a fallback. With the recent CVE-2026-111943 the following steps can be taken to determine if you are impacted and what to do about it.  Redpanda Cloud has been reviewed and is not impacted.

Additionally Redpanda containers for Redpanda Connect, Operator, Console, Kminion and RPK could contain impacted ca-certificates package.  These containers will be updated by Redpanda and you can view new releases for each at the links below. At time of release the default version may still be an older version, you should check and pin to at least the listed versions.

Redpanda Core & RPK - Patched Versions 25.3.18, 26.1.19, 26.2.6 and up.

Redpanda Connect - Patched Version 4.115.0 and up.

Redpanda Operator - Patched Versions 25.3.11, 26.1.13, 26.2.5 and up.

Redpanda Console - Patched Versions 2.8.17, 3.13.1, and up.

Kminion - Patched Version 2.3.8 and up.

Severity: 

Medium

Redpanda Products Affected:

• Redpanda Self-Managed - Enterprise

• Redpanda Self-Managed - Community

Release Affected:

Not specific to a Redpanda version. This is a bulletin advising self-hosted customers to check their certificate configuration.

Identification:

It is first important to confirm if your Redpanda cluster is configured to use custom trust stores, there are a number of places that these can be set in the config:

Once you know which trust stores your cluster uses, check each one. The primary check runs entirely on the host and no external connectivity. A connectivity-based check follows it for cases where you want a live confirmation.

Method 1 (primary): offline fingerprint check of your trust stores

What it does. This script reads every certificate in each trust store you list, computes its SHA-256 fingerprint, and compares it against the published set of compromised eMudhra fingerprints. It reports an exact match as CRITICAL, a certificate that anchors the compromised chain as a WARNING, and anything else as ok.

Why this is the recommended check. It runs locally with no outbound network connection, so it works in air-gapped or egress-restricted environments. It does not rely on any third-party site, and it gives a deterministic result for every trust store you point it at, including the system CA bundle. Add the system bundle path to the list below to cover the paths that fall back to it (tiered storage, Iceberg, OIDC, and any listener or client with no explicit trust store set).

Input (edit the file list to match your configuration):

  # SHA-256 fingerprints of the known-compromised eMudhra CAs
  FPS='42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
  432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
  98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
  5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
  7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
  84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD'

  # Edit this list to match the trust stores YOUR cluster uses (see the table above).
  # The three paths below are the Kubernetes operator defaults. Add your system
  # CA bundle (for example /etc/ssl/certs/ca-certificates.crt on Debian/Ubuntu,
  # or /etc/pki/tls/certs/ca-bundle.crt on RHEL) to cover the fallback paths.
  for f in /etc/tls/certs/ca/ca.crt /etc/tls/certs/pandaproxy/ca/ca.crt /etc/tls/certs/schema-registry/ca/ca.crt; do
    [ -r "$f" ] || { echo "SKIP $f"; continue; }
    echo "### $f  ($(grep -c 'BEGIN CERT' "$f") cert(s))"
    d=$(mktemp -d); hit=0
    awk -v d="$d" '/BEGIN CERT/{n++} n{print>d"/c"n}' "$f"
    for c in "$d"/c*; do
      [ -s "$c" ] || continue
      fp=$(openssl x509 -in "$c" -noout -fingerprint -sha256 2>/dev/null | sed 's/.*=//;s/://g')
      s=$(openssl x509 -in "$c" -noout -subject -nameopt rfc2253 2>/dev/null | sed 's/^subject= *//')
      if printf '%s' "$FPS" | tr ' ' '\n' | grep -qixF "$fp"; then
        echo "  CRITICAL: LEAKED $s [$fp]"; hit=1
      elif printf '%s' "$s" | grep -qiE 'EM (DV|OV|EV) TLS CA - G3|EM OV CS CA - G3|emSign.*Root.*CA - G3|AAA Certificate Services'; then
        echo "  WARNING: anchors leaked chain: $s"; hit=1
      else
        echo "  ok: $s"
      fi
    done
    rm -rf "$d"
    [ "$hit" = 0 ] && echo "  => OK (no eMudhra-leak CA)"
  done

Expected output (clean cluster shown):

### /etc/tls/certs/ca/ca.crt  (5 cert(s))
    ok: CN=OneClickTLS CA,OU=Certificate Authority,O=OneClickTLS,L=San Francisco,ST=California,C=US
    ok: CN=rp-cuthulu-selfsigned-ca
    ok: CN=rp-cuthulu-kafka-root-certificate
    ok: CN=YR1,O=Let's Encrypt,C=US
    ok: CN=Root YR,O=ISRG,C=US
    => OK (no eMudhra-leak CA)
  ### /etc/tls/certs/pandaproxy/ca/ca.crt  (4 cert(s))
    ok: CN=OneClickTLS CA,OU=Certificate Authority,O=OneClickTLS,L=San Francisco,ST=California,C=US
    ok: CN=rp-cuthulu-proxy-root-certificate
    ok: CN=YR1,O=Let's Encrypt,C=US
    ok: CN=Root YR,O=ISRG,C=US
    => OK (no eMudhra-leak CA)
  ### /etc/tls/certs/schema-registry/ca/ca.crt  (4 cert(s))
    ok: CN=OneClickTLS CA,OU=Certificate Authority,O=OneClickTLS,L=San Francisco,ST=California,C=US
    ok: CN=rp-cuthulu-schema-registry-root-certificate
    ok: CN=YR1,O=Let's Encrypt,C=US
    ok: CN=Root YR,O=ISRG,C=US
    => OK (no eMudhra-leak CA)

How to read the result:

• CRITICAL: LEAKED ... means the trust store contains a certificate whose fingerprint matches a known compromised eMudhra CA. That store is affected. Remediate it.

• WARNING: anchors leaked chain: ... means the store trusts a root or intermediate that the compromised chain anchors to, so a forged certificate could validate against it. Treat the store as affected.

• ok: on every certificate, followed by => OK (no eMudhra-leak CA), means that store is clean.

Method 2 (optional, live): connectivity check against a public probe site

NOTE: This check connects outbound from the host you run it on to a probe site that Redpanda does not own or operate. This is generally expected to be a safe step, however as with any security critical system, you should not run it from a production or restricted environment without approval from your security team and/or your own comfort that the 3rd party site referenced is safe.

Additionally, a failed or blocked connection does not guarantee you are safe, it may only mean this test could not run.

What it does. A successful connection means the trust store used for that connection trusts the leaked CA. The probe covers both compromised anchors, so run both hostnames.

Input (system CA bundle):

  curl https://dv-g3b-emudhra.we-have-a-problem.com/

  curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Input (a specific trust store, when a path uses its own):

  curl --cacert /etc/tls/certs/ca/ca.crt https://dv-g3b-emudhra.we-have-a-problem.com/

  curl --cacert /etc/tls/certs/ca/ca.crt https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Output that indicates a problem:

  Your client successfully connected to the site. That's bad!

A connection that succeeds means the trust store trusts the leaked CA. A connection that is refused or fails to validate is the result you want, subject to the caveat above.

Impact: 

Condition. The residual exposure applies where a Redpanda component establishes an outbound TLS connection as the client and the trust store used for that connection still trusts a compromised eMudhra certification authority.

Description. Redpanda outbound TLS connections validate the peer against the configured trust store for that connection, or the system CA bundle when no trust store is configured. The Redpanda container image's bundle (ca-certificates 20250419, as shipped in v26.2.3 and confirmed by inspection) continues to trust emSign ECC Root CA - G3 and AAA Certificate Services, both of which anchor the compromised intermediate chain. Under these conditions an attacker in an on-path (man-in-the-middle) network position can present a forged server certificate, signed with the now-public private key of a leaked intermediate, for the targeted endpoint, and the broker will complete the TLS handshake and accept the connection as trusted.

Secondary surface. Any Kafka, HTTP Proxy, or Schema Registry client whose own trust store still trusts a compromised certification authority is subject to the same risk in the reverse direction: an on-path attacker may impersonate the Redpanda broker to that client and capture SASL credentials or intercept data in transit. This exposure is governed by the client's trust configuration and is outside the broker's control.

Inbound authentication surface. Where a listener is configured for mutual TLS (require_client_auth), Redpanda validates client certificates against that listener's configured trust store. If the trust store trusts a compromised eMudhra certification authority, an attacker can present a client certificate signed with the leaked intermediate's now-public private key and authenticate as a legitimate client, bypassing the mutual TLS control. This applies to any listener whose trust store is affected (Kafka API, Admin API, HTTP Proxy, Schema Registry, or internal RPC). In many deployments these trust stores reference a private certification authority and are unaffected. The risk applies only where a compromised public authority is present.

Redpanda Cloud

Redpanda has reviewed and confirmed that Redpanda Cloud and its associated applications are not at risk of CVE-2026-111943.

Action required: 

If you determine that you are impacted the following steps can be taken to remediate the underlying vulnerabilities:

1. For container and Kubernetes deployments: upgrade to Redpanda 25.3.18, 26.1.19, or 26.2.6 (or later). These images ship updated ca-certificates which remove the affected roots. Brokers must restart on the new image.

2. For bare-metal and VM deployments: update the host's ca-certificates package, or disable the affected roots and rebuild the bundle. Then restart each broker. Redpanda reads the OS bundle at startup.

3. If explicit trust stores were set: if any truststore_file, cloud_storage_trust_file, or iceberg_rest_catalog_trust_file contains an affected CA, remove it and replace the file. Listener truststores reload automatically. Restart brokers for the others.

Redpanda Cloud

No action is needed from Redpanda Cloud users.

Questions? If you have any questions on this TSB, or need further guidance, please contact Redpanda Support