Add ffmpeg package to n8n Docker image for media processing

[SashkoMarchuk]

Click Up Task: https://app.clickup.com/t/86c7xzdpc

Summary by CodeRabbit

• Chores
  • Added a system-level media processing tool to the runtime image to enable improved audio/video/image handling; no other runtime behavior or public APIs were changed.

Usage in Production

While N8N_BLOCKED_NODES blocks the Execute Command node in production,
ffmpeg is accessible through:

• Community FFmpeg nodes (e.g., n8n-nodes-mediafx, @raisaroj/n8n-nodes-ffmpeg)
  installed via Settings > Community Nodes in the n8n UI
• Code/Function nodes that invoke ffmpeg programmatically

The ffmpeg binary must be present at the system level for any of these
integration methods to work.

[github-actions]

CodeRabbit

🤖 CodeRabbit AI Review Available

To request a code review from CodeRabbit AI, add [coderabbit-ai-review] to your PR title.

CodeRabbit will analyze your code and provide feedback on:

• Logic and correctness
• Security issues
• Performance optimizations
• Code quality and best practices
• Error handling
• Maintainability

Note: Reviews are only performed when [coderabbit-ai-review] is present in the PR title.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: 98118be6-43fe-48cf-b5cd-32fa4616bab8

📥 Commits

Reviewing files that changed from the base of the PR and between 313a127 and 7df4012.

📒 Files selected for processing (1)

• Dockerfile.n8n

✅ Files skipped from review due to trivial changes (1)

• Dockerfile.n8n

---

📝 Walkthrough

Walkthrough

The Dockerfile.n8n apk install line was updated to add ffmpeg=6.1.2-r2 alongside the existing pinned git=2.49.1-r0, modifying the image's system dependencies during build.

Changes

Cohort / File(s)	Summary
Docker Configuration Dockerfile.n8n	Added ffmpeg=6.1.2-r2 to the apk add command alongside the already pinned git=2.49.1-r0; change is limited to system-level package installation in the image build.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Suggested reviewers

• killev
• anatolyshipitz

Poem

🐰 I hopped through layers, light and spry,
Found ffmpeg nestled where packages lie,
A tiny tweak, a crunchy bite,
Containers hum a bit more bright,
Build on, friends—let media fly! 🎬✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately describes the main change: adding ffmpeg package to the n8n Docker image, which aligns with the file modification in Dockerfile.n8n.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/add-ffmpeg-to-n8n

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

🧹 Nitpick comments (1)

Dockerfile.n8n (1)

13-13: Pin ffmpeg to a specific version for reproducible builds.

git is pinned to 2.49.1-r0, but ffmpeg is unpinned. This inconsistency means the image isn't fully reproducible — a rebuild could pull a different ffmpeg version with breaking changes or vulnerabilities.

Proposed fix

First, find the current version available in the base image's Alpine release:

#!/bin/bash
# Check which Alpine version the base image uses and the available ffmpeg package version
docker run --rm n8nio/n8n:1.109.2 sh -c "cat /etc/alpine-release && apk info ffmpeg 2>/dev/null || apk list ffmpeg 2>/dev/null || apk search -e ffmpeg"

Then pin accordingly, e.g.:

-  apk add --no-cache git=2.49.1-r0 ffmpeg && \
+  apk add --no-cache git=2.49.1-r0 ffmpeg=<version> && \

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🔍 Vulnerabilities of temporal-test:latest

📦 Image Reference temporal-test:latest

digest	sha256:17e54ff5e9a181d1bdbf7334ce9637f9c3934d54a65427ae36a5743f46487f15
vulnerabilities
platform	linux/amd64
size	218 MB
packages	358

📦 Base Image alpine:3

also known as	3.21 3.21.3 latest
digest	sha256:1c4eef651f65e2f7daee7ee785882ac164b02b78fb74503052a26dc061c90474
vulnerabilities

stdlib 1.23.2 (golang) pkg:golang/stdlib@1.23.2 Affected range <1.24.13 Fixed version 1.24.13 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.23.8 Fixed version 1.23.8 EPSS Score 0.127% EPSS Percentile 32nd percentile Description The net/http package improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. This can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext. 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.24.11 Fixed version 1.24.11 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.24.12 Fixed version 1.24.12 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. Affected range <1.24.8 Fixed version 1.24.8 EPSS Score 0.028% EPSS Percentile 8th percentile Description The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption. Affected range <1.24.8 Fixed version 1.24.8 EPSS Score 0.027% EPSS Percentile 8th percentile Description The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs. Affected range <1.24.8 Fixed version 1.24.8 EPSS Score 0.006% EPSS Percentile 0th percentile Description Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains. Affected range <1.24.9 Fixed version 1.24.9 EPSS Score 0.013% EPSS Percentile 2nd percentile Description Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains.

stdlib 1.23.6 (golang) pkg:golang/stdlib@1.23.6 Affected range <1.24.13 Fixed version 1.24.13 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.23.8 Fixed version 1.23.8 EPSS Score 0.127% EPSS Percentile 32nd percentile Description The net/http package improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. This can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext. 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.24.11 Fixed version 1.24.11 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.24.12 Fixed version 1.24.12 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. Affected range <1.24.8 Fixed version 1.24.8 EPSS Score 0.028% EPSS Percentile 8th percentile Description The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption. Affected range <1.24.8 Fixed version 1.24.8 EPSS Score 0.027% EPSS Percentile 8th percentile Description The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input. This affects programs which parse untrusted PEM inputs. Affected range <1.24.8 Fixed version 1.24.8 EPSS Score 0.006% EPSS Percentile 0th percentile Description Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method. This affects programs which validate arbitrary certificate chains. Affected range <1.24.9 Fixed version 1.24.9 EPSS Score 0.013% EPSS Percentile 2nd percentile Description Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains.

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

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

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

openssl 3.3.3-r0 (apk) pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.21 Affected range <3.3.6-r0 Fixed version 3.3.6-r0 EPSS Score 0.819% EPSS Percentile 74th percentile Description Affected range <3.3.5-r0 Fixed version 3.3.5-r0 EPSS Score 0.034% EPSS Percentile 10th percentile Description Affected range <3.3.6-r0 Fixed version 3.3.6-r0 EPSS Score 0.034% EPSS Percentile 10th percentile Description Affected range <3.3.6-r0 Fixed version 3.3.6-r0 EPSS Score 0.290% EPSS Percentile 52nd percentile Description Affected range <3.3.6-r0 Fixed version 3.3.6-r0 EPSS Score 0.060% EPSS Percentile 19th percentile Description

curl 8.12.1-r0 (apk) pkg:apk/alpine/curl@8.12.1-r0?os_name=alpine&os_version=3.21 Affected range <=8.14.0-r0 Fixed version Not Fixed EPSS Score 0.039% EPSS Percentile 12th percentile Description Affected range <8.14.1-r2 Fixed version 8.14.1-r2 EPSS Score 0.035% EPSS Percentile 10th percentile Description Affected range <8.14.1-r0 Fixed version 8.14.1-r0 EPSS Score 0.210% EPSS Percentile 43rd percentile Description

golang.org/x/crypto 0.32.0 (golang) pkg:golang/golang.org/x/crypto@0.32.0 Affected range <0.43.0 Fixed version 0.43.0 EPSS Score 0.039% EPSS Percentile 12th percentile Description SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process. Affected range <0.35.0 Fixed version 0.35.0 EPSS Score 0.215% EPSS Percentile 44th percentile Description SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

go.opentelemetry.io/otel/sdk 1.34.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.34.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.007% 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.com/golang-jwt/jwt 3.2.2+incompatible (golang) pkg:golang/github.com/golang-jwt/jwt@3.2.2%2Bincompatible Asymmetric Resource Consumption (Amplification) Affected range >=3.2.0 <=3.2.2 Fixed version Not Fixed CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.102% EPSS Percentile 28th percentile Description Summary Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification) Details See parse.ParseUnverified Impact Excessive memory allocation

go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc 0.36.4 (golang) pkg:golang/go.opentelemetry.io/contrib/instrumentation@0.36.4#google.golang.org/grpc/otelgrpc OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <0.46.0 Fixed version 0.46.0 EPSS Score 4.299% EPSS Percentile 89th percentile Description OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels net.peer.sock.addr and net.peer.sock.port that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passing otelgrpc.WithMeterProvider option with noop.NewMeterProvider.

golang.org/x/oauth2 0.7.0 (golang) pkg:golang/golang.org/x/oauth2@0.7.0 Improper Validation of Syntactic Correctness of Input Affected range <0.27.0 Fixed version 0.27.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.112% EPSS Percentile 30th percentile Description An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.

golang.org/x/crypto 0.36.0 (golang) pkg:golang/golang.org/x/crypto@0.36.0 Affected range <0.43.0 Fixed version 0.43.0 EPSS Score 0.039% EPSS Percentile 12th percentile Description SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

golang.org/x/oauth2 0.26.0 (golang) pkg:golang/golang.org/x/oauth2@0.26.0 Improper Validation of Syntactic Correctness of Input Affected range <0.27.0 Fixed version 0.27.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.112% EPSS Percentile 30th percentile Description An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.

nghttp2 1.64.0-r0 (apk) pkg:apk/alpine/nghttp2@1.64.0-r0?os_name=alpine&os_version=3.21 Affected range <=1.64.0-r0 Fixed version Not Fixed EPSS Score 0.017% EPSS Percentile 4th percentile Description

golang.org/x/crypto 0.35.0 (golang) pkg:golang/golang.org/x/crypto@0.35.0 Affected range <0.43.0 Fixed version 0.43.0 EPSS Score 0.039% EPSS Percentile 12th percentile Description SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

go.opentelemetry.io/otel/sdk 1.35.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.35.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.007% 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

c-ares 1.34.3-r0 (apk) pkg:apk/alpine/c-ares@1.34.3-r0?os_name=alpine&os_version=3.21 Affected range <1.34.5-r0 Fixed version 1.34.5-r0 EPSS Score 0.618% EPSS Percentile 70th percentile Description

github.com/go-jose/go-jose/v4 4.0.5 (golang) pkg:golang/github.com/go-jose/go-jose@4.0.5#v4 Uncaught Exception Affected range <4.1.4 Fixed version 4.1.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Impact Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. Fixed In 4.1.4 and v3.0.5 Workarounds If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected. If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .). Thanks Go JOSE thanks Datadog's Security team for finding this issue.

github.com/golang-jwt/jwt/v4 4.5.1 (golang) pkg:golang/github.com/golang-jwt/jwt@4.5.1#v4 Asymmetric Resource Consumption (Amplification) Affected range <4.5.2 Fixed version 4.5.2 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.102% EPSS Percentile 28th percentile Description Summary Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification) Details See parse.ParseUnverified Impact Excessive memory allocation