Conversation
…1/update-golang-1.25
|
@ncaak: This pull request references DVO-411 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target either version "4.22." or "openshift-4.22.", but it targets "0.7.15" instead. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ncaak The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
📝 WalkthroughWalkthroughUpdated Go toolchain from 1.24.0 to 1.25.0, upgraded golangci-lint from v1 to v2, reorganized linting configuration to match the new version, updated numerous direct and indirect dependencies, and refactored a switch statement for improved code clarity. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@ncaak: This pull request references DVO-411 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target either version "4.22." or "openshift-4.22.", but it targets "0.7.15" instead. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
ci/golangci-lint.sh (1)
9-12: Verify the existence check path aligns with the intended behavior.The script checks for
bin/golangci-lint(local path) but installs to$(go env GOPATH)/bin. This means the binary will always be reinstalled unless a local./bin/golangci-lintexists. If this is intentional (to allow local binary overrides), consider adding a clarifying comment. Otherwise, consider aligning the check with the actual install location.The version bump to v2.10.1 correctly aligns with the v2 configuration format in
.golangci.yml.💡 Option A: Check GOPATH location instead
export BINARY=bin/golangci-lint -if [ ! -f "$BINARY" ]; then +if ! command -v golangci-lint &> /dev/null; then curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/HEAD/install.sh | sh -s -- -b "$(go env GOPATH)/bin" v2.10.1 fi💡 Option B: Add clarifying comment for current behavior
+# Check for local binary override; if not present, install to GOPATH/bin export BINARY=bin/golangci-lint if [ ! -f "$BINARY" ]; then curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/HEAD/install.sh | sh -s -- -b "$(go env GOPATH)/bin" v2.10.1 fi🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci/golangci-lint.sh` around lines 9 - 12, The existence check uses BINARY=bin/golangci-lint but the installer places the binary into $(go env GOPATH)/bin, so the script will reinstall unless a local ./bin/golangci-lint exists; either change the check to test "$(go env GOPATH)/bin/golangci-lint" (so it matches the actual install target) or keep the current local-path check and add a clarifying comment above BINARY explaining that a local ./bin/golangci-lint is preferred and will override the GOPATH install; update references to BINARY and the curl install command accordingly (look for BINARY, "$BINARY", and the install target "$(go env GOPATH)/bin") so the behavior and intent are consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.golangci.yml:
- Around line 19-25: The revive linter config uses the deprecated
skip-package-name-checks option in the var-naming rule (see var-naming and
skip-package-name-checks), so remove the third nested argument that sets
skip-package-name-checks and instead add/configure the separate package-naming
rule (e.g., add a rule entry for package-naming and set disabled: true or
configure it as needed); update the revive.rules list to keep var-naming with
only its first two argument lists and add package-naming for package name
control.
In `@go.mod`:
- Around line 3-5: The toolchain version in go.mod currently uses "toolchain
go1.25.7"; update this to the latest patch "toolchain go1.25.8" so the project
builds with the March 5, 2026 security/stability fixes—edit the go.mod entry
that contains the toolchain declaration and replace go1.25.7 with go1.25.8
(leave the "go 1.25.0" directive unchanged unless you intend to bump the
language version as well).
- Line 36: The go.mod currently pulls vulnerable transitive modules (e.g.,
github.com/containerd/containerd v1.7.11) via golang.stackrox.io/kube-linter;
fix by upgrading the kube-linter dependency to a version that vendors patched
transitives and, if an immediate upgrade isn't available, add go.mod replace
directives for the critical transitive modules (at minimum replace
google.golang.org/grpc to a patched semver and likewise replace
github.com/containerd/containerd, github.com/docker/docker,
github.com/antonmedv/expr or expr-lang/expr, kedacore/keda/v2, and
helm.sh/helm/v3) to secure versions, then run go mod tidy && go mod vendor (or
re-run your build) to ensure the updated transitive graph is used and CI
verifies no vulnerable versions remain.
---
Nitpick comments:
In `@ci/golangci-lint.sh`:
- Around line 9-12: The existence check uses BINARY=bin/golangci-lint but the
installer places the binary into $(go env GOPATH)/bin, so the script will
reinstall unless a local ./bin/golangci-lint exists; either change the check to
test "$(go env GOPATH)/bin/golangci-lint" (so it matches the actual install
target) or keep the current local-path check and add a clarifying comment above
BINARY explaining that a local ./bin/golangci-lint is preferred and will
override the GOPATH install; update references to BINARY and the curl install
command accordingly (look for BINARY, "$BINARY", and the install target "$(go
env GOPATH)/bin") so the behavior and intent are consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d0b18424-f4a1-4319-b362-094f3c0506c7
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (4)
.golangci.ymlci/golangci-lint.shgo.modpkg/utils/selector.go
| revive: | ||
| rules: | ||
| - name: var-naming | ||
| arguments: | ||
| - [] | ||
| - [] | ||
| - - skip-package-name-checks: true |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
golangci-lint v2 revive var-naming rule configuration
💡 Result:
In golangci-lint v2, the revive linter's var-naming rule is configured in the .golangci.yml file under linters-settings.revive.rules. The var-naming rule takes two arguments: a list of allowed initialisms (lowercase accepted) and a list of blocked initialisms (uppercase required). Example configuration: linters: enable: - revive linters-settings: revive: rules: - name: var-naming arguments: [ ["id", "json"], ["ID", "JSON"] ] This allows "id" and "json" in lowercase but requires "ID" and "JSON" in uppercase where specified. By default, revive behaves like golint with common initialisms like ID, HTTP. Note: Not all revive TOML options (e.g. upperCaseConst) are directly supported via golangci-lint YAML; only the two initialism lists are exposed for var-naming. For full revive config, run revive standalone with revive.toml.
Citations:
- 1: var-naming: allow disabling flags on common initial mgechev/revive#1414
- 2: https://linkedin.com/company/v2-music-group-limited
- 3: How to configure
upperCaseConstfor thevar-namingrule withingolangci-lintfor revive? mgechev/revive#893 - 4: https://revive.run/docs/
- 5: https://pkg.go.dev/github.com/mgechev/revive
- 6: https://github.com/golangci/golangci-lint/blob/master/.golangci.reference.yml
- 7: var-naming rule to check that plural vars with ID are capitalised mgechev/revive#947
🌐 Web query:
revive var-naming rule skip-package-name-checks option golangci-lint
💡 Result:
Yes, there is a skip-package-name-checks option for the var-naming rule in the revive linter, which is integrated with golangci-lint. This option was added via merged PR #941 in November 2023 to allow skipping package name checks while keeping variable naming checks enabled. In recent versions (post-2025 updates), the var-naming rule documentation notes that legacy package-related options like skip-package-name-checks are deprecated and treated as no-ops (ignored), with package naming checks moved to a separate package-naming rule. To configure in golangci-lint's .golangci.yml: linters-settings: revive: rules: - name: var-naming arguments: - true # or {skipPackageNameChecks: true} depending on config format; check exact syntax in revive docs For up-to-date usage as of 2026, disable package-naming rule instead: linters: enable: - revive linters-settings: revive: rules: - name: package-naming disabled: true
Citations:
- 1: variable to skip package name checks mgechev/revive#941
- 2: https://github.com/mgechev/revive/blob/master/RULES_DESCRIPTIONS.md
- 3: var-naming: detect meaningless package names mgechev/revive#1312
🌐 Web query:
golangci-lint revive var-naming arguments three parameters options
💡 Result:
The revive var-naming rule in golangci-lint takes two main arguments: an allowlist of initialisms (slice of strings) and a blocklist of initialisms (another slice of strings). These are passed as an array containing two arrays in the .golangci.yml configuration. Example configuration: linters-settings: revive: rules: - name: var-naming arguments: - - ID - HTTP - - VM This allows acronyms like ID and HTTP to be treated specially (e.g., userId instead of userID), while blocking VM (e.g., requires customVM). The golangci-lint documentation notes only 2 arguments for var-naming. There is an open question about configuring a third parameter like upperCaseConst (to allow ALL_CAPS constants), but the standard configuration uses exactly two parameters: the allow and block lists. No confirmed support for three parameters was found in official docs or recent issues; attempts to add {upperCaseConst=true} as a third argument failed. For full details, see revive docs: var-naming accepts two slices of strings for allowlist/blocklist initialisms.
Citations:
- 1: How to configure
upperCaseConstfor thevar-namingrule withingolangci-lintfor revive? mgechev/revive#893 - 2: https://pkg.go.dev/github.com/mgechev/revive
- 3: var-naming: allow disabling flags on common initial mgechev/revive#1414
🏁 Script executed:
# Let's also check if there's a golangci-lint reference configuration available
curl -s https://raw.githubusercontent.com/golangci/golangci-lint/master/.golangci.reference.yml | grep -A 20 "var-naming" | head -30Repository: app-sre/deployment-validation-operator
Length of output: 768
The var-naming rule argument format is correct; however, the skip-package-name-checks option is deprecated.
The nested list structure arguments: [[], [], [- skip-package-name-checks: true]] is actually the documented format for var-naming's third parameter (options) in golangci-lint. However, according to current revive documentation (post-2025), the skip-package-name-checks option has been deprecated and is treated as a no-op. Use the separate package-naming rule instead to control package name checks:
revive:
rules:
- name: var-naming
arguments:
- []
- []
- name: package-naming
disabled: true # or configure as needed🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.golangci.yml around lines 19 - 25, The revive linter config uses the
deprecated skip-package-name-checks option in the var-naming rule (see
var-naming and skip-package-name-checks), so remove the third nested argument
that sets skip-package-name-checks and instead add/configure the separate
package-naming rule (e.g., add a rule entry for package-naming and set disabled:
true or configure it as needed); update the revive.rules list to keep var-naming
with only its first two argument lists and add package-naming for package name
control.
| go 1.25.0 | ||
|
|
||
| toolchain go1.24.13 | ||
| toolchain go1.25.7 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Go 1.25 release date and latest patch version
💡 Result:
Go 1.25.0 was released on August 12, 2025. As of March 25, 2026, the latest patch version is Go 1.25.8, released on March 5, 2026.
Citations:
- 1: https://go.dev/doc/go1.25
- 2: http://weekly.golang.org/blog/go1.25
- 3: https://blog.golang.org/go1.25
- 4: https://go.dev/doc/devel/release
- 5: https://go.dev/dl/?target=_blank
- 6: https://golang.org/dl/
Update toolchain to the latest Go 1.25 patch version.
Go 1.25.0 is a valid release and toolchain go1.25.7 is stable. However, Go 1.25.8 was released on March 5, 2026, and should replace go1.25.7 to benefit from the latest security patches and stability improvements.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` around lines 3 - 5, The toolchain version in go.mod currently uses
"toolchain go1.25.7"; update this to the latest patch "toolchain go1.25.8" so
the project builds with the March 5, 2026 security/stability fixes—edit the
go.mod entry that contains the toolchain declaration and replace go1.25.7 with
go1.25.8 (leave the "go 1.25.0" directive unchanged unless you intend to bump
the language version as well).
| github.com/chai2010/gettext-go v1.0.2 // indirect | ||
| github.com/containerd/containerd v1.7.29 // indirect | ||
| github.com/containerd/errdefs v0.3.0 // indirect | ||
| github.com/containerd/containerd v1.7.11 // indirect |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check which direct dependency pulls in vulnerable transitive deps
echo "=== Checking dependency graph for vulnerable packages ==="
# Check what requires containerd
echo "--- containerd required by:"
go mod graph | grep containerd/containerd | head -10
# Check what requires docker
echo "--- docker required by:"
go mod graph | grep "docker/docker " | head -10
# Check what requires helm
echo "--- helm required by:"
go mod graph | grep "helm.sh/helm" | head -10
# Check what requires grpc
echo "--- grpc required by:"
go mod graph | grep "google.golang.org/grpc " | head -10
# Check latest kube-linter version
echo "--- Current kube-linter version:"
grep kube-linter go.modRepository: app-sre/deployment-validation-operator
Length of output: 1875
🏁 Script executed:
cat -n go.modRepository: app-sre/deployment-validation-operator
Length of output: 8836
🌐 Web query:
containerd v1.7.11 security vulnerability CVE integer overflow privilege escalation
💡 Result:
Yes, containerd v1.7.11 is affected by CVE-2024-40635, a security vulnerability involving an integer overflow in User ID handling that can lead to privilege escalation by allowing containers to run as root (UID 0). CVE-2024-40635 affects containerd versions prior to 1.6.38, from 1.7.0 (including) up to but excluding 1.7.27, and from 2.0.0 up to but excluding 2.0.4. Since v1.7.11 falls within the 1.7.0 to <1.7.27 range, it is vulnerable. The vulnerability occurs when containers are launched with a User set as a UID:GID larger than the maximum 32-bit signed integer (MaxInt32), causing an overflow that results in the container running as root. This can lead to unexpected behavior in environments requiring non-root users. CVSS v3.1 score: 7.8 (HIGH), with vector AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N. CWE-190 (Integer Overflow or Wraparound). Official containerd security advisory: GHSA-265r-hfxg-fhmg. Fixed in v1.7.27 (commit 05044ec). Workarounds: Use only trusted images and restrict permissions for importing images to trusted users. No evidence of a separate integer overflow privilege escalation vulnerability specific to v1.7.11 beyond CVE-2024-40635. Another recent containerd vuln, CVE-2024-25621 (directory permissions LPE), affects up to v1.7.28 and is fixed in v1.7.29, so v1.7.11 is also vulnerable to that, but it is not an integer overflow.
Citations:
- 1: https://cvefeed.io/vuln/detail/CVE-2024-40635
- 2: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMCONTAINERDCONTAINERDOCI-9479986
- 3: https://repology.org/project/containerd/cves?version=1.7.9
- 4: GHSA-265r-hfxg-fhmg
- 5: https://vulert.com/vuln-db/CVE-2024-40635
- 6: GHSA-265r-hfxg-fhmg
- 7: https://www.tenable.com/cve/CVE-2024-40635
- 8: https://nvd.nist.gov/vuln/detail/CVE-2024-40635
- 9: https://avd.aquasec.com/nvd/2024/cve-2024-40635/
🌐 Web query:
docker v24.0.7 CVE cache poisoning authorization bypass firewalld
💡 Result:
Docker v24.0.7 is vulnerable to CVE-2024-24557, a cache poisoning vulnerability in the classic builder (non-BuildKit) that allows attackers with Dockerfile knowledge to poison the cache by pulling specially crafted images, potentially altering build outcomes. Patched in v24.0.9. It is also vulnerable to CVE-2024-41110, an authorization plugin (AuthZ) bypass regression allowing specially crafted API requests (Content-Length: 0) to skip body inspection, enabling unauthorized actions if AuthZ plugins are used. Patched in later versions beyond v24.0.9. No vulnerability directly matches "cache poisoning authorization bypass firewalld" as a single CVE. However, recent firewalld-related issues include CVE-2025-54388 (published ~July 2025), where firewalld reload on Moby/Docker v28.2.0-28.3.2 fails to recreate iptables rules, exposing localhost-published container ports to remote hosts with bridge network routing (CVSS 5.1 Medium). Patched in v28.3.3. Docker v24.0.7 (older branch) predates this and uses different versioning, so unaffected by CVE-2025-54388. Docker v24.0.7 release notes mention no firewalld-specific security fixes; it focuses on bug fixes and component upgrades. Firewalld issues appear in much newer Moby releases (v28.x). No evidence of cache poisoning combined with auth bypass or firewalld in v24.0.7.
Citations:
- 1: GHSA-xw73-rw38-6vjc
- 2: https://nvd.nist.gov/vuln/detail/cve-2024-24557
- 3: https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin
- 4: GHSA-v23v-6jw2-98fq
- 5: https://scout.docker.com/vulnerabilities/id/CVE-2025-54388
- 6: https://nvd.nist.gov/vuln/detail/cve-2025-54388
- 7: https://docs.docker.com/engine/release-notes/24.0
🌐 Web query:
google.golang.org/grpc v1.65.0 CVE authorization bypass leading slash
💡 Result:
Yes, google.golang.org/grpc v1.65.0 is vulnerable to CVE-2026-33186, an authorization bypass vulnerability due to improper validation of the HTTP/2 :path pseudo-header lacking a leading slash (e.g., "Service/Method" instead of "/Service/Method"). The gRPC-Go server routes such malformed requests correctly but authorization interceptors like grpc/authz evaluate the raw non-canonical path, causing "deny" rules for canonical paths to fail to match. If a fallback "allow" rule exists, this bypasses authorization. This affects servers using path-based authorization with specific deny rules for canonical paths and a default allow. CVSS v3.1: 9.1 (Critical), AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Affected: All versions < v1.79.3. Patched in v1.79.3 (released March 17, 2026), which rejects non-canonical paths with codes.Unimplemented. v1.65.0 (released July 2024) predates the patch and is explicitly listed as affected in vulnerability databases. Workarounds: Add a unary interceptor to reject if info.FullMethod[0] != '/'; use proxies to enforce strict HTTP/2; harden policies to default-deny unknown paths.
Citations:
- 1: GHSA-p77j-4mvh-x3m3
- 2: https://vulert.com/vuln-db/CVE-2026-33186
- 3: https://advisories.gitlab.com/pkg/golang/google.golang.org/grpc/CVE-2026-33186/
- 4: https://security.snyk.io/vuln/SNYK-GOLANG-GOOGLEGOLANGORGGRPC-15691172
- 5: https://nvd.nist.gov/vuln/detail/CVE-2026-33186
- 6: https://github.com/grpc/grpc-go/releases
🌐 Web query:
helm v3.14.1 security vulnerability CVE panic OOM code injection
💡 Result:
Helm v3.14.1 has one directly associated security vulnerability: CVE-2024-26147, a moderate-severity issue (CVSS 7.5) causing application panic due to uninitialized variable when parsing malformed index.yaml or plugin.yaml files missing metadata. This affects Helm <=3.14.1 and is fixed in v3.14.2. It matches the "panic" keyword. No CVEs directly match "OOM" (out-of-memory) or "code injection" for v3.14.1. Related but distinct issues in later versions include: - OOM: CVE-2025-32386 (Helm <3.17.3), specially crafted chart archive causes memory exhaustion. - Code injection: CVE-2025-53547 (Helm <3.18.4), local code execution via symlinked Chart.lock from malicious Chart.yaml during dependency updates. "OOM" references in sources are operational issues (e.g., Flux CD helm-controller memory limits), not security CVEs. No single CVE combines all terms for v3.14.1. Upgrade beyond v3.14.1 to address the panic vulnerability and monitor Helm's GitHub security advisories for latest issues.
Citations:
- 1: https://www.cvedetails.com/version/1881806/Helm-Helm-3.14.1.html
- 2: https://nvd.nist.gov/vuln/detail/cve-2024-25620
- 3: GHSA-r53h-jv2g-vpx6
- 4: [release-1.14] upgrade Helm to fix CVE-2024-26147 cert-manager/cert-manager#6834
- 5: https://vulert.com/vuln-db/go-helm-sh-helm-v3-137574
- 6: GHSA-4hfp-h4cw-hj8p
- 7: https://vulert.com/vuln-db/go-helm-sh-helm-v3-196450
- 8: https://www.tenable.com/cve/CVE-2025-53547
- 9: https://vulert.com/vuln-db/CVE-2025-32386
🌐 Web query:
expr-lang/expr v1.15.8 CVE memory exhaustion DoS recursion
💡 Result:
There is no CVE specifically assigned to expr-lang/expr version 1.15.8 for a memory exhaustion DoS vulnerability involving recursion. Version 1.15.8, released January 2024, predates relevant security fixes. The closest vulnerability is CVE-2025-29786 (GHSA-93mq-9ffx-83m2), a memory exhaustion DoS in the parser from unbounded input strings causing excessive AST node creation and OOM crashes. Affected: <1.17.0. Patched in v1.17.0 (March 2025) via PR #762 adding compile-time node budget and memory limits. CVSS 7.5 High. Workaround: limit input string length. A separate recursion-related DoS is CVE-2025-68156 (GHSA-cfpf-hrx2-8rv6), unbounded recursion in builtins like flatten/min/max/mean/median on deep/cyclic data causing stack overflow. Affected: <1.17.7. Patched in v1.17.7 (December 2025) via PR #870 adding recursion depth limits. Both affect v1.15.8, but neither matches "recursion" in the parser context of the query. Upgrade to latest v1.17.8 (February 2026).
Citations:
- 1: https://nvd.nist.gov/vuln/detail/CVE-2025-29786
- 2: https://github.com/expr-lang/expr/security/advisories
- 3: GHSA-93mq-9ffx-83m2
- 4: GHSA-93mq-9ffx-83m2
- 5: https://newreleases.io/project/github/expr-lang/expr/release/v1.17.0
- 6: https://github.com/expr-lang/expr/releases
- 7: feat: add node budget and memory limits expr-lang/expr#762
🌐 Web query:
docker/cli v24.0.7 CVE Windows privilege escalation
💡 Result:
No, there is no known CVE for Docker CLI v24.0.7 that causes Windows privilege escalation. Docker CLI v24.0.7, released in October 2023, has no security vulnerabilities listed in official Docker release notes or security advisories. The only relevant privilege escalation vulnerability found is CVE-2025-15558 (disclosed March 2026), which affects Docker CLI versions through v29.1.5 on Windows due to an uncontrolled search path in CLI plugins (C:\ProgramData\Docker\cli-plugins). This allows low-privileged attackers to place malicious plugin binaries for execution by privileged users. v24.0.7 predates this issue and uses an earlier version of the cli-plugins/manager code not listed as affected in CVE details. Other CVEs mentioned (e.g., CVE-2024-24557, CVE-2023-44487) relate to Docker Engine/BuildKit or dependencies, not CLI privilege escalation on Windows.
Citations:
- 1: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMDOCKERCLICLIPLUGINSMANAGER-15435878
- 2: https://www.sentinelone.com/vulnerability-database/cve-2025-15558/
- 3: GHSA-p436-gjf2-799p
- 4: https://nvd.nist.gov/vuln/detail/cve-2025-15558
- 5: https://docs.docker.com/engine/release-notes/24.0
- 6: https://github.com/docker/cli/releases
- 7: http://docs.docker.com/engine/release-notes
🌐 Web query:
kedacore keda v2.13.0 CVE HashiCorp Vault arbitrary file read
💡 Result:
Yes, KEDA v2.13.0 is vulnerable to CVE-2025-68476, an arbitrary file read vulnerability in the HashiCorp Vault TriggerAuthentication handler due to insufficient path validation when loading the service account token from spec.hashiCorpVault.credential.serviceAccount. CVE ID: CVE-2025-68476 (published Dec 22, 2025) Severity: High (CVSS 4.0: 8.2 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N) Affected: KEDA Operator versions <=2.17.2 and <=2.18.2 (Metrics Server <2.9.0 also noted); v2.13.0 (released Jan 2024) falls in affected range. Patched: v2.17.3, v2.18.3, >=v2.19.0 Patch commit: kedacore/keda@15c5677 Exploitation requires permissions to create/modify TriggerAuthentication resources. Attacker can read any file from the KEDA pod's node filesystem (e.g., /etc/passwd, secrets) via path traversal, exfiltrated during Vault auth request. Check version: kubectl get deploy keda-operator -n keda -o jsonpath='{.spec.template.spec.containers[0].image}' Mitigation: Upgrade to patched version; restrict TriggerAuthentication RBAC; avoid Vault serviceAccount credential if possible. Official advisory: GHSA-c4p6-qg4m-9jmr NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-68476
Citations:
- 1: GHSA-c4p6-qg4m-9jmr
- 2: https://nvd.nist.gov/vuln/detail/CVE-2025-68476
- 3: https://advisories.gitlab.com/pkg/golang/github.com/kedacore/keda/v2/CVE-2025-68476/
- 4: https://www.tenable.com/cve/CVE-2025-68476
- 5: https://vulert.com/vuln-db/keda-has-arbitrary-file-read-via-insufficient-path-validation-in-hashicorp-vault-service-account-cre---
- 6: https://github.com/kedacore/keda/releases
High and critical security vulnerabilities in indirect dependencies require action.
The following indirect dependencies have confirmed security issues:
| Dependency | Version | Severity | CVE(s) |
|---|---|---|---|
containerd/containerd |
1.7.11 | HIGH | CVE-2024-40635 (integer overflow, privilege escalation) |
docker/docker |
24.0.7 | HIGH | CVE-2024-24557 (cache poisoning), CVE-2024-41110 (authz bypass) |
expr-lang/expr |
1.15.8 | HIGH | CVE-2025-29786 (memory exhaustion), CVE-2025-68156 (recursion DoS) |
kedacore/keda/v2 |
2.13.0 | HIGH | CVE-2025-68476 (arbitrary file read via Vault) |
google.golang.org/grpc |
1.65.0 | CRITICAL | CVE-2026-33186 (authorization bypass via missing leading slash) |
helm.sh/helm/v3 |
3.14.1 | MODERATE | CVE-2024-26147 (panic on malformed YAML) |
These are transitive dependencies pulled in by golang.stackrox.io/kube-linter. Recommended actions:
- Upgrade
kube-linterto a version using patched dependencies - Add
replacedirectives for critical vulnerabilities (especially gRPC) if direct kube-linter upgrades are insufficient - Evaluate actual code paths to confirm whether all dependencies are in use
🧰 Tools
🪛 OSV Scanner (2.3.3)
[HIGH] 36-36: github.com/containerd/containerd 1.7.11: containerd has an integer overflow in User ID handling in github.com/containerd/containerd
(GO-2025-3528)
[HIGH] 36-36: github.com/containerd/containerd 1.7.11: containerd affected by a local privilege escalation via wide permissions on CRI directory in github.com/containerd/containerd
(GO-2025-4100)
[HIGH] 36-36: github.com/containerd/containerd 1.7.11: containerd CRI server: Host memory exhaustion through Attach goroutine leak in github.com/containerd/containerd
(GO-2025-4108)
[HIGH] 36-36: github.com/containerd/containerd 1.7.11: containerd has an integer overflow in User ID handling
[HIGH] 36-36: github.com/containerd/containerd 1.7.11: containerd CRI server: Host memory exhaustion through Attach goroutine leak
[HIGH] 36-36: github.com/containerd/containerd 1.7.11: containerd affected by a local privilege escalation via wide permissions on CRI directory
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` at line 36, The go.mod currently pulls vulnerable transitive modules
(e.g., github.com/containerd/containerd v1.7.11) via
golang.stackrox.io/kube-linter; fix by upgrading the kube-linter dependency to a
version that vendors patched transitives and, if an immediate upgrade isn't
available, add go.mod replace directives for the critical transitive modules (at
minimum replace google.golang.org/grpc to a patched semver and likewise replace
github.com/containerd/containerd, github.com/docker/docker,
github.com/antonmedv/expr or expr-lang/expr, kedacore/keda/v2, and
helm.sh/helm/v3) to secure versions, then run go mod tidy && go mod vendor (or
re-run your build) to ensure the updated transitive graph is used and CI
verifies no vulnerable versions remain.
|
/retest |
|
/test lint |
|
@ncaak: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
3 participants
summary
Upgrade to Go 1.25, the most recent supported version on the
go-toolsetimage.Current linting tool is not compatible with 1.25 so it was needed to upgrade.
misc
Summary by CodeRabbit
Release Notes