chore(deps): update eksctl-anywhere to v0.25.2

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
eksctl-anywhere	patch	0.25.1 → 0.25.2

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

aws/eks-anywhere (eksctl-anywhere)

v0.25.2

Compare Source

Planned updates to supported kubernetes versions

• Kubernetes 1.32 reaches end of standard support on April 30, 2026
  • Extended support continues until April 30, 2027 for clusters with valid license tokens
  • Clusters will continue to function but will not receive CVE patches or bug fixes after standard support ends
• Kubernetes 1.29 reaches end of extended support on April 30, 2026
  • No further patches will be available after this date
  • Existing clusters will continue to function but upgrading is strongly recommended

For complete version support details, see the Kubernetes version support table.

Supported OS version details

	vSphere	Bare Metal	Nutanix	CloudStack	Snow
Ubuntu 20.04	✔	✔	✔	—	✔
Ubuntu 22.04	✔	✔	✔	—	—
Ubuntu 24.04	✔	✔	✔	—	—
Bottlerocket 1.56.0	✔	—	—	—	—
RHEL 8.x	✔	✔	✔	✔	—
RHEL 9.x	✔	✔	✔	✔	—

* Starting with EKS-A minor release v0.25.0, the bundled Kubernetes Image Builder will no longer support Ubuntu 20.04 LTS builds, as Ubuntu 20.04 LTS Standard Support has ended, and the upstream Kubernetes Image Builder no longer supports Ubuntu 20.04 LTS.
* RHEL 8's kernel version (4.18) is not supported by kubeadm for Kubernetes versions 1.32 and above (see Kubernetes GitHub issue #​129462). As a result, EKS Anywhere does not support using RHEL 8 as the node operating system for Kubernetes versions 1.32 and above.

Changed

• EKS Distro:
  • v1-35-eks-8
  • v1-34-eks-17
  • v1-33-eks-26
  • v1-32-eks-36
  • v1-31-eks-43
  • v1-30-eks-54
• New EKS-Distro base images
• cloud-provider-vsphere 1-35: v1.35.0 to v1.35.1
• Helm: v4.1.3 to v4.1.4

Fixed

• Update BMCLib to latest commit that includes critical Gofish fixes (#​5319)

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

• 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.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

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

---

This PR has been generated by Renovate Bot.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/eksctl-anywhere:0.25.2

📦 Image Reference ghcr.io/uniget-org/tools/eksctl-anywhere:0.25.2

digest	sha256:ff5eadd8bd15eec52c295070a7c9c88599867e7a21de967e7e97b9c30e64eb97
vulnerabilities
platform	linux/amd64
size	27 MB
packages	191

google.golang.org/grpc 1.72.3 (golang) pkg:golang/google.golang.org/grpc@1.72.3 Improper Authorization Affected range <1.79.3 Fixed version 1.79.3 CVSS Score 9.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N EPSS Score 0.016% EPSS Percentile 3rd percentile Description Impact What kind of vulnerability is it? Who is impacted? It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. Who is impacted? This affects gRPC-Go servers that meet both of the following criteria: They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx). Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server. Patches Has the problem been patched? What versions should users upgrade to? Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. Users should upgrade to the following versions (or newer): v1.79.3 The latest master branch. It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: 1. Use a Validating Interceptor (Recommended Mitigation) Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs: func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) { if info.FullMethod == "" || info.FullMethod[0] != '/' { return nil, status.Errorf(codes.Unimplemented, "malformed method name") } return handler(ctx, req) } // Ensure this is the FIRST interceptor in your chain s := grpc.NewServer( grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor), ) 2. Infrastructure-Level Normalization If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash. 3. Policy Hardening Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

stdlib 1.25.8 (golang) pkg:golang/stdlib@1.25.8 Affected range <1.25.9 Fixed version 1.25.9 EPSS Score 0.015% EPSS Percentile 3rd percentile Description If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3. Affected range <1.25.9 Fixed version 1.25.9 EPSS Score 0.018% EPSS Percentile 4th percentile Description Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service. This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool. Affected range <1.25.9 Fixed version 1.25.9 EPSS Score 0.017% EPSS Percentile 4th percentile Description During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls. Affected range <1.25.9 Fixed version 1.25.9 EPSS Score 0.008% EPSS Percentile 1st percentile Description On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root. The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation. Affected range <1.25.9 Fixed version 1.25.9 EPSS Score 0.010% EPSS Percentile 1st percentile Description Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied. These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities. Affected range <1.25.9 Fixed version 1.25.9 EPSS Score 0.004% EPSS Percentile 0th percentile Description tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.

github.com/docker/cli 27.0.3+incompatible (golang) pkg:golang/github.com/docker/cli@27.0.3%2Bincompatible Uncontrolled Search Path Element Affected range >=19.03.0 <29.2.0 Fixed version 29.2.0 CVSS Score 7 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.023% EPSS Percentile 6th percentile Description This issue affects Docker CLI through 29.1.5 Impact Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user. This issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the [github.com/docker/cli/cli-plugins/manager](https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager) package, which is consumed by downstream projects such as Docker Compose. Docker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see docker/compose#12300), and is fixed in v5.1.0. This issue does not impact non-Windows binaries or projects that do not use the plugin manager code. Patches Fixed version starts with 29.2.0 This issue was fixed in docker/cli@1375933 (docker/cli#6713), which removed %PROGRAMDATA%\Docker\cli-plugins from the list of paths used for plugin-discovery on Windows. Workarounds None Resources Pull request: "cli-plugins/manager: remove legacy system-wide cli-plugin path" (cli-plugins/manager: remove legacy system-wide cli-plugin path docker/cli#6713) Patch: https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa.patch Credits Nitesh Surana (niteshsurana.com) of Trend Research of TrendAI

github.com/go-git/go-git/v5 5.16.5 (golang) pkg:golang/github.com/go-git/go-git@5.16.5#v5 Integer Underflow (Wrap or Wraparound) Affected range >=5.0.0 <=5.17.0 Fixed version 5.17.1 CVSS Score 5 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H EPSS Score 0.013% EPSS Percentile 2nd percentile Description Impact A vulnerability has been identified in which a maliciously crafted .idx file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a Denial of Service (DoS) condition. Exploitation requires write access to the local repository's .git directory, it order to create or alter existing .idx files. Patches Users should upgrade to v5.17.1, or the latest v6 pseudo-version, in order to mitigate this vulnerability. Credit The go-git maintainers thank @kq5y for finding and reporting this issue privately to the go-git project. Insufficiently Protected Credentials Affected range <=5.17.2 Fixed version 5.18.0 CVSS Score 4.7 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N Description Impact go-git may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations. If a remote repository responds to the initial /info/refs request with a redirect to a different host, go-git updates the session endpoint to the redirected location and reuses the original authentication for subsequent requests. This can result in the credentials (e.g. Authorization headers) being sent to an unintended host. An attacker controlling or influencing the redirect target can capture these credentials and potentially reuse them to access the victim’s repositories or other resources, depending on the scope of the credential. Clients using go-git exclusively with trusted remotes (for example, GitHub or GitLab), and over a secure HTTPS connection, are not affected by this issue. The risk arises when interacting with untrusted or misconfigured Git servers, or when using unsecured HTTP connections, which is not recommended. Such configurations also expose clients to a broader class of security risks beyond this issue, including credential interception and tampering of repository data. Patches Users should upgrade to v5.18.0, or v6.0.0-alpha.2, in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported go-git version. The patched versions add support for configuring followRedirects. In line with upstream behaviour, the default is now initial, while users can opt into FollowRedirects or NoFollowRedirects programmatically. Credit Thanks to the 3 separate reports from @celinke97, @N0zoM1z0 and @AyushParkara. Thanks for finding and reporting this issue privately to the go-git project. 🙇 Improper Validation of Array Index Affected range <=5.17.0 Fixed version 5.17.1 CVSS Score 2.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L EPSS Score 0.014% EPSS Percentile 2nd percentile Description Impact go-git’s index decoder for format version 4 fails to validate the path name prefix length before applying it to the previously decoded path name. A maliciously crafted index file can trigger an out-of-bounds slice operation, resulting in a runtime panic during normal index parsing. This issue only affects Git index format version 4. Earlier formats (go-git supports only v2 and v3) are not vulnerable to this issue. An attacker able to supply a crafted .git/index file can cause applications using go-git to panic while reading the index. If the application does not recover from panics, this results in process termination, leading to a denial-of-service (DoS) condition. Exploitation requires the ability to modify or inject a Git index file within the local repository in disk. This typically implies write access to the .git directory. Patches Users should upgrade to v5.17.1, or the latest v6 pseudo-version, in order to mitigate this vulnerability. Credit go-git maintainers thank @kq5y for finding and reporting this issue privately to the go-git project.

helm.sh/helm/v3 3.18.5 (golang) pkg:golang/helm.sh/helm/v3@3.18.5 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=3.20.1 Fixed version 3.20.2 CVSS Score 4.8 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N EPSS Score 0.009% EPSS Percentile 1st percentile Description Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=4.1.3, a specially crafted Chart will cause helm pull --untar [chart URL | repo/chartname] to write the Chart's contents to the immediate output directory (as defaulted to the current working directory; or as given by the --destination and --untardir flags), rather than the expected output directory suffixed by the chart's name. Impact The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory <output dir>/, instead of the expected <output dir>/<chart name>/, potentially overwriting the contents of the targeted directory. Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed. Patches This issue has been resolved in Helm v3.20.2 and v4.1.3 A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected. Workarounds Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). In addition, ensuring that the pull --untar flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory. Credits Oleh Konko @1seal

[github-actions]

Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/24703026563.

[github-actions]

PR is clean and can be merged. See https://github.com/uniget-org/tools/actions/runs/24703026563.