deps(deps): update davidanson/markdownlint-cli2-action action to v23

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
DavidAnson/markdownlint-cli2-action	action	major	v20.0.0 → v23.0.0

---

Release Notes

DavidAnson/markdownlint-cli2-action (DavidAnson/markdownlint-cli2-action)

v23.0.0: Update markdownlint-cli2 version (markdownlint-cli2 v0.22.0, markdownlint v0.40.0), update Node.js dependency to 24.

Compare Source

v22.0.0: Update markdownlint version (markdownlint-cli2 v0.20.0, markdownlint v0.40.0).

Compare Source

v21.0.0: Update markdownlint version (markdownlint-cli2 v0.19.0, markdownlint v0.39.0).

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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 was generated by Mend Renovate. View the repository job log.

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Outdated

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

🔍 Vulnerabilities of moby/buildkit:buildx-stable-1

📦 Image Reference moby/buildkit:buildx-stable-1

digest	sha256:2b2263f26d9731b038ae85170379d194145e6fc4245e17d1e9dcf00dfd3218fa
vulnerabilities
platform	linux/amd64
size	117 MB
packages	313

📦 Base Image alpine:3

also known as	3.23 3.23.3 latest
digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
vulnerabilities

stdlib 1.25.4 (golang) pkg:golang/stdlib@1.25.4 Affected range >=1.25.0-0 <1.25.7 Fixed version 1.25.7 EPSS Score 0.017% EPSS Percentile 4th percentile Description During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake. Affected range <1.25.8 Fixed version 1.25.8 EPSS Score 0.031% EPSS Percentile 9th percentile Description url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. Affected range >=1.25.0 <1.25.5 Fixed version 1.25.5 EPSS Score 0.022% EPSS Percentile 6th percentile Description Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption. Affected range >=1.25.0 <1.25.6 Fixed version 1.25.6 EPSS Score 0.032% EPSS Percentile 9th percentile Description The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 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.011% EPSS Percentile 1st 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.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.008% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

[github-actions]

Outdated

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago

[github-actions]

Recommended fixes for image moby/buildkit:buildx-stable-1

Base image is alpine:3

Name	3.23.3
Digest	sha256:59855d3dceb3ae53991193bd03301e082b2a7faa56a514b03527ae0ec2ce3a95
Vulnerabilities
Pushed	1 month ago
Size	3.9 MB
Packages	20
OS	3.23.3

The base image is also available under the supported tag(s): 3.23, 3.23.3, latest

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

Tag	Details	Pushed	Vulnerabilities
3.21 Tag is preferred tag Also known as: 3.21.6	Benefits: Image is smaller by 213 KB Minor OS version update Image contains 1 fewer package Tag is preferred tag Tag was pushed more recently Image introduces no new vulnerability but removes 1 Image details: Size: 3.6 MB OS: 3.21.6	1 month ago