CVE-2025-64171: MARIN3R Auth Bypass Vulnerability

CVE-2025-64171 Overview

MARIN3R is a lightweight, Custom Resource Definition (CRD) based Envoy control plane for Kubernetes. CVE-2025-64171 is a missing authorization flaw [CWE-862] in the DiscoveryServiceCertificate resource that allows users to bypass Kubernetes Role-Based Access Control (RBAC) and read Secret objects in namespaces they do not own. The vulnerability affects MARIN3R versions 0.13.3 and earlier and is fixed in version 0.13.4.

Critical Impact
Authenticated users with permission to create DiscoveryServiceCertificate resources can reference and read arbitrary Secret objects across the cluster, exposing TLS keys, service account tokens, and application credentials.

Affected Products

MARIN3R versions 0.13.3 and below
3scale-sre/marin3r operator deployments on Kubernetes
Envoy control planes provisioned through MARIN3R DiscoveryServiceCertificate CRs

Discovery Timeline

2025-11-06 - CVE-2025-64171 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-64171

Vulnerability Analysis

MARIN3R provisions certificates for Envoy discovery services through the DiscoveryServiceCertificate CRD. When the certificate signer is configured as CASigned, the controller fetches the issuing Certificate Authority (CA) from a SecretRef defined in the resource spec. The reconciler honored the Namespace field of that SecretRef without validating that it matched the namespace of the DiscoveryServiceCertificate itself.

Because the MARIN3R operator runs with cluster-wide permissions to read Secret resources, any tenant able to create a DiscoveryServiceCertificate could direct the controller to load a Secret from a foreign namespace. The controller acted as a confused deputy, performing the privileged read on behalf of an unauthorized caller and exposing CA material to a tenant who lacked direct RBAC access to that Secret.

Root Cause

The getIssuerCertificate function in internal/pkg/reconcilers/operator/discoveryservicecertificate/providers/marin3r/crud.go constructed a types.NamespacedName directly from cp.dsc.Spec.Signer.CASigned.SecretRef.Namespace without comparing it to the parent resource's namespace. The absence of this authorization check matches the [CWE-862] missing authorization pattern.

Attack Vector

An attacker with namespace-scoped permission to create DiscoveryServiceCertificate resources crafts a CR whose spec.signer.caSigned.secretRef.namespace points to a sensitive namespace such as kube-system or another tenant's workspace. The operator reconciles the CR, reads the referenced Secret using its elevated service account, and uses the data to issue or surface certificate material that the attacker can subsequently retrieve.

// Security patch in internal/pkg/reconcilers/operator/discoveryservicecertificate/providers/marin3r/crud.go
// Source: https://github.com/3scale-sre/marin3r/commit/859b14115fde1d67620e645cd1b62e90e30d9981

// getIssuerCertificate returns the issuer certificate for a DiscoveryServiceCertificate resource
func (cp *CertificateProvider) getIssuerCertificate(ctx context.Context) (*x509.Certificate, interface{}, error) {
    if cp.dsc.Spec.Signer.CASigned != nil {
        caNamespace := cp.dsc.Spec.Signer.CASigned.SecretRef.Namespace
        dscNamespace := cp.dsc.GetNamespace()

        // Default to current namespace if not specified
        if caNamespace == "" {
            caNamespace = dscNamespace
        }

        // Enforce same-namespace requirement for security
        if caNamespace != dscNamespace {
            return nil, nil, fmt.Errorf(
                "DiscoveryServiceCertificate cannot reference Secrets in other namespaces: "+
                    "caSecretRef is in namespace '%s' but DiscoveryServiceCertificate is in '%s'",
                caNamespace, dscNamespace)
        }

        secret := &corev1.Secret{}
        key := types.NamespacedName{
            Name:      cp.dsc.Spec.Signer.CASigned.SecretRef.Name,
            Namespace: caNamespace,
        }

        if err := cp.client.Get(ctx, key, secret); err != nil {

The patch enforces that caNamespace equals dscNamespace and returns an explicit error when they diverge.

Detection Methods for CVE-2025-64171

Indicators of Compromise

DiscoveryServiceCertificate resources whose spec.signer.caSigned.secretRef.namespace differs from the resource's own metadata.namespace.
MARIN3R controller logs showing successful Secret Get operations targeting namespaces outside the requesting tenant's scope.
Kubernetes audit log entries where the MARIN3R service account reads Secret objects in kube-system, cert-manager, or other privileged namespaces shortly after a tenant-created DiscoveryServiceCertificate is reconciled.

Detection Strategies

Query the Kubernetes API for all DiscoveryServiceCertificate resources and compare metadata.namespace against spec.signer.caSigned.secretRef.namespace to identify cross-namespace references.
Enable Kubernetes audit logging at the Metadata or Request level for secrets resources and correlate reads performed by the MARIN3R operator's service account with the CRs being reconciled.
Ingest cluster audit logs into Singularity Data Lake using OCSF normalization to hunt for the confused-deputy pattern across multi-tenant clusters.

Monitoring Recommendations

Alert when any DiscoveryServiceCertificate is created or updated with a non-empty, non-matching secretRef.namespace value.
Track MARIN3R controller error logs for the new cannot reference Secrets in other namespaces message, which indicates either remediation activity or attempted exploitation against a patched build.
Baseline the namespaces from which the MARIN3R service account legitimately reads Secret objects and alert on deviations.

How to Mitigate CVE-2025-64171

Immediate Actions Required

Upgrade MARIN3R to version 0.13.4 or later across all clusters running the operator.
Audit existing DiscoveryServiceCertificate resources for cross-namespace secretRef values and rotate any CA Secret that may have been exposed.
Rotate TLS material issued by potentially exposed CAs and invalidate downstream certificates derived from them.

Patch Information

The fix is delivered in MARIN3R 0.13.4 via commit 859b141, which adds a same-namespace check in getIssuerCertificate. Review the GitHub Security Advisory GHSA-gf93-xccm-5g6j and the GitHub Commit Details for the full change set.

Workarounds

Restrict create and update permissions on DiscoveryServiceCertificate resources to trusted cluster administrators until the operator is upgraded.
Deploy an admission controller policy (Kyverno or OPA Gatekeeper) that rejects any DiscoveryServiceCertificate whose spec.signer.caSigned.secretRef.namespace does not equal the resource's metadata.namespace.
Run MARIN3R in a single-tenant cluster or scope the operator to a limited set of namespaces using WATCH_NAMESPACE until patched binaries are deployed.

bash

# Kyverno ClusterPolicy enforcing same-namespace secretRef
cat <<'EOF' | kubectl apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: marin3r-dsc-same-namespace
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-cross-namespace-caSecretRef
      match:
        any:
          - resources:
              kinds:
                - operator.marin3r.3scale.net/DiscoveryServiceCertificate
      validate:
        message: "caSigned.secretRef.namespace must match the resource namespace"
        deny:
          conditions:
            any:
              - key: "{{ request.object.spec.signer.caSigned.secretRef.namespace }}"
                operator: NotEquals
                value: "{{ request.object.metadata.namespace }}"
EOF