CVE-2025-64171

Executive Summary

CVE-2025-64171 is a critical authorization bypass vulnerability in the Marin3r project, a lightweight, CRD-based Envoy control plane for Kubernetes. The flaw resides in the DiscoveryServiceCertificate resource, allowing authenticated users to bypass Role-Based Access Control (RBAC) and read secrets from namespaces they are not authorized to access. This vulnerability affects all versions up to and including 0.13.3. The issue has been patched in version 0.13.4. The vulnerability has a CVSS score of 8.6 (High) due to its low attack complexity, network-based attack vector, and potential for significant confidentiality impact across namespaces.

Supply Chain & Package Security

Marin3r is distributed as a Go binary and container image. The vulnerability is in the core control plane logic, not in a package dependency. However, organizations using Marin3r should verify their deployment version and ensure the container image is sourced from a trusted registry. The patch (0.13.4) is available on the official GitHub repository.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) - An attacker needs valid Kubernetes credentials but can be a low-privileged user.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Changed (C) - The vulnerability allows access to resources (secrets) in other security contexts (namespaces).
• Confidentiality (C): High (H) - Complete disclosure of secret data is possible.
• Integrity (I): None (N) - No data modification is possible.
• Availability (A): None (N) - No impact on system availability.

CVSS Score: 8.6 (High)

Threat Level: High. The vulnerability allows lateral movement and privilege escalation within a Kubernetes cluster by exposing secrets across namespaces.

Deep Dive & Mechanics

The Marin3r control plane uses Custom Resource Definitions (CRDs) to manage Envoy configurations. The DiscoveryServiceCertificate CRD is used to define TLS certificates for the xDS (Discovery Service) connections between Envoy proxies and the control plane.

The vulnerability arises because the controller logic that processes DiscoveryServiceCertificate resources does not properly validate the namespace of the referenced Kubernetes Secret. When a user creates a DiscoveryServiceCertificate resource, they can specify a secretRef pointing to a Secret in any namespace. The controller then reads that Secret and uses it to serve the xDS connection. Due to the missing namespace authorization check, a user with permissions to create DiscoveryServiceCertificate resources in their own namespace can reference a Secret from a different namespace (e.g., kube-system or another tenant's namespace) and exfiltrate its contents.

The core issue is a Missing Authorization (CWE-862) in the controller's reconciliation loop. The controller does not verify that the user who created or updated the DiscoveryServiceCertificate has RBAC permissions to read the referenced Secret in the target namespace.

Vulnerable vs. Patched Code

Vulnerable Code (<= 0.13.3):

The controller's reconciliation logic directly reads the Secret from the namespace specified in the secretRef without checking the user's permissions.

// Vulnerable: No namespace authorization check
func (r *DiscoveryServiceCertificateReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // ... fetch DiscoveryServiceCertificate ...
    secretRef := dsc.Spec.SecretRef
    // Directly reads the secret from the referenced namespace
    secret := &corev1.Secret{}
    err := r.Get(ctx, types.NamespacedName{Name: secretRef.Name, Namespace: secretRef.Namespace}, secret)
    // ... use secret ...
}

Patched Code (0.13.4):

The patched version adds an authorization check before reading the Secret. It verifies that the user (or the service account associated with the request) has get and list permissions on Secrets in the target namespace.

// Patched: Authorization check added
func (r *DiscoveryServiceCertificateReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // ... fetch DiscoveryServiceCertificate ...
    secretRef := dsc.Spec.SecretRef

    // Authorization check: Verify the user can access the secret in the target namespace
    userInfo, _ := r.UserInfoFromContext(ctx)
    if !r.Authorizer.Authorize(ctx, userInfo, &authorizer.AttributesRecord{
        User:            userInfo,
        Verb:            "get",
        Resource:        "secrets",
        Namespace:       secretRef.Namespace,
        ResourceRequest: true,
    }) {
        return ctrl.Result{}, errors.New("unauthorized: cannot access secret in namespace " + secretRef.Namespace)
    }

    secret := &corev1.Secret{}
    err := r.Get(ctx, types.NamespacedName{Name: secretRef.Name, Namespace: secretRef.Namespace}, secret)
    // ... use secret ...
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Kubernetes cluster with Marin3r <= 0.13.3 installed.
• A Kubernetes user or service account with permissions to create DiscoveryServiceCertificate resources in at least one namespace.

Exploitation Steps:

1. Identify a target secret: For example, a secret named my-cluster-secret in the kube-system namespace.

2. Create a malicious DiscoveryServiceCertificate resource that references the target secret.

   apiVersion: marin3r.3scale.net/v1alpha1
   kind: DiscoveryServiceCertificate
   metadata:
     name: malicious-cert
     namespace: attacker-namespace
   spec:
     secretRef:
       name: my-cluster-secret
       namespace: kube-system
     # Other required fields (e.g., commonName, dnsNames) can be arbitrary
     commonName: "example.com"
   

3. Apply the resource:

   kubectl apply -f malicious-cert.yaml
   

4. Exfiltrate the secret: The Marin3r controller will read the secret from kube-system and use it to serve the xDS connection. The attacker can then connect to the xDS endpoint and retrieve the certificate data, which contains the secret's contents (e.g., TLS private key, tokens, etc.).

Blue Team

Detection:

• Monitor for DiscoveryServiceCertificate resources that reference secrets in namespaces different from the resource's own namespace.
• Audit RBAC permissions for users creating DiscoveryServiceCertificate resources.
• Enable Kubernetes audit logging and look for get or list operations on secrets in unexpected namespaces by the Marin3r controller's service account.

Mitigation:

• Immediately upgrade to Marin3r version 0.13.4 or later.
• If upgrade is not possible, implement a mutating admission webhook that rejects DiscoveryServiceCertificate resources where spec.secretRef.namespace does not match the resource's metadata.namespace.
• Restrict permissions to create DiscoveryServiceCertificate resources to only trusted users/service accounts.

Indicators of Compromise (IOCs)

• Kubernetes Audit Logs:

  • user.username: The user who created the malicious DiscoveryServiceCertificate.
  • objectRef.resource: discoveryservicecertificates
  • objectRef.namespace: The attacker's namespace.
  • responseStatus.code: 201 (Created)
  • Subsequent get or list operations on secrets in a different namespace by the Marin3r controller's service account.

• Network IOCs:

  • Unusual xDS connections from an Envoy proxy to the Marin3r control plane, especially if the proxy is not expected to be part of the mesh.

• File System IOCs:

  • The Marin3r controller logs may show errors or warnings about unauthorized secret access attempts (if logging is enabled).

Detection Engineering

YARA Rule

rule CVE_2025_64171_Marin3r_Secret_Access {
    meta:
        description = "Detects Marin3r DiscoveryServiceCertificate resources that reference secrets in a different namespace"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-64171"
        severity = "high"
    strings:
        $api_version = "marin3r.3scale.net/v1alpha1"
        $kind = "DiscoveryServiceCertificate"
        $secret_ref = "secretRef"
        $namespace_field = "namespace"
    condition:
        $api_version and $kind and $secret_ref and $namespace_field
}

Sigma Rule

title: CVE-2025-64171 - Marin3r Cross-Namespace Secret Access
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects creation of DiscoveryServiceCertificate resources referencing secrets in a different namespace
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-64171
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        objectRef.resource: "discoveryservicecertificates"
        objectRef.namespace: "*"
        responseStatus.code: 201
    filter:
        - objectRef.namespace: "kube-system"  # Exclude if same namespace (adjust as needed)
    condition: selection and not filter
falsepositives:
    - Legitimate use of cross-namespace secret references (if allowed by policy)
level: high

Suricata Rule

alert tcp any any -> any 18000 (msg:"CVE-2025-64171 Marin3r xDS Secret Exfiltration"; flow:to_server,established; content:"|48 45 4c 4c 4f|"; depth:5; content:"|77 6f 72 6c 64|"; within:10; sid:1000001; rev:1;)

Note: The Suricata rule above is a placeholder. Actual detection would require deep packet inspection of the xDS protocol (protobuf) which is complex. The rule above is a generic example and should be replaced with a more specific signature based on the actual xDS data being exfiltrated.

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Upgrade Marin3r to version 0.13.4 or later. This is the only complete fix.

   # Example upgrade command (adjust based on your deployment method)
   kubectl set image deployment/marin3r-controller-manager marin3r-controller=quay.io/3scale/marin3r:v0.13.4
   

2. Admission Webhook: If upgrade is delayed, deploy a mutating admission webhook to enforce namespace matching.
3. RBAC Review: Audit and restrict permissions for creating DiscoveryServiceCertificate resources.

Long-Term Mitigations:

• Implement network policies to restrict egress from the Marin3r controller.
• Use a secrets management solution (e.g., HashiCorp Vault) instead of Kubernetes Secrets for sensitive data.
• Regularly scan Kubernetes audit logs for anomalous cross-namespace access patterns.

Valters IT

This report is generated for educational and defensive purposes. Unauthorized exploitation of this vulnerability is illegal.