fix(oauth2-proxy): migrate domains to gluzdov.com

[SashkoMarchuk]

Summary

• Update OAuth2 proxy domain references from speedandfunction.com to gluzdov.com in docker-compose.prod.yml
• Aligns the git-tracked config with the production ALB/DNS setup (*.gluzdov.com wildcard cert)
• EMAIL_DOMAINS intentionally kept as speedandfunction.com — that's the corporate Google Workspace domain for authentication

Changed lines (5 total)

Setting	Old	New
COOKIE_DOMAINS	.temporal.speedandfunction.com	.temporal.gluzdov.com
WHITELIST_DOMAINS	.temporal.speedandfunction.com	.temporal.gluzdov.com
REDIRECT_URL default	https://temporal.speedandfunction.com/...	https://temporal.gluzdov.com/...
CSRF_COOKIE_DOMAIN	.temporal.speedandfunction.com	.temporal.gluzdov.com
SIGN_OUT_URL	https://temporal.speedandfunction.com/...	https://temporal.gluzdov.com/...

Context

The production server already has these changes applied manually (uncommitted). This PR commits them to git to eliminate configuration drift. After merge, run git stash && git pull && git stash drop on the EC2 server.

Test plan

• Verify temporal.gluzdov.com resolves to ALB IPs
• Verify Google Cloud Console has https://temporal.gluzdov.com/oauth2/callback as authorized redirect URI
• After deploy: confirm OAuth2 login flow works end-to-end
• Confirm old speedandfunction.com cookies are cleared on first new login

Summary by CodeRabbit

• Chores
  • Switched authentication proxy settings to use the temporal.gluzdov.com host for cookie domains, whitelist domains, and CSRF domain.
  • Updated the default OAuth redirect URL to the new temporal.gluzdov.com host.
  • Made the sign-out endpoint configurable via environment variable, with a new default pointing to the temporal.gluzdov.com sign-out path.

[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: 44be61a8-397e-4a96-b404-2758e5434b92

📥 Commits

Reviewing files that changed from the base of the PR and between f63f289 and 15ec022.

📒 Files selected for processing (1)

• docker-compose.prod.yml

🚧 Files skipped from review as they are similar to previous changes (1)

• docker-compose.prod.yml

---

📝 Walkthrough

Walkthrough

Replaced domain references in docker-compose.prod.yml: updated OAuth2 proxy environment variable defaults and values from .temporal.speedandfunction.com to .temporal.gluzdov.com, and made the sign-out URL configurable via an environment-variable fallback.

Changes

Cohort / File(s)	Summary
OAuth2 Proxy Domain Migration docker-compose.prod.yml	Replaced .temporal.speedandfunction.com with .temporal.gluzdov.com for OAUTH2_PROXY_COOKIE_DOMAINS, OAUTH2_PROXY_WHITELIST_DOMAINS, and OAUTH2_PROXY_CSRF_COOKIE_DOMAIN; updated default OAUTH2_PROXY_REDIRECT_URL to https://temporal.gluzdov.com/oauth2/callback; changed OAUTH2_PROXY_SIGN_OUT_URL to use an env-var fallback ${OAUTH2_PROXY_SIGN_OUT_URL:-https://temporal.gluzdov.com/oauth2/sign_out}.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐇 I nibble bytes and tweak a line,

domains hop from old to fine.
Cookies, redirects, sign-out too—
a little swap, a fresher view.
Hooray, the proxy wears new shoes!

🚥 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 title accurately reflects the main change: migrating OAuth2 proxy domain configurations from speedandfunction.com to gluzdov.com in the docker-compose configuration.
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 fix/oauth2-proxy-domain-migration

---

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

[coderabbitai]

🧹 Nitpick comments (1)

docker-compose.prod.yml (1)

114-114: Consider using environment variable pattern for consistency.

The sign-out URL is hardcoded while OAUTH2_PROXY_REDIRECT_URL on line 92 uses an environment variable with a default fallback. For consistency and flexibility:

-      - OAUTH2_PROXY_SIGN_OUT_URL=https://temporal.gluzdov.com/oauth2/sign_out
+      - OAUTH2_PROXY_SIGN_OUT_URL=${OAUTH2_PROXY_SIGN_OUT_URL:-https://temporal.gluzdov.com/oauth2/sign_out}

Not blocking—the current change is functionally correct.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docker-compose.prod.yml` at line 114, The OAUTH2_PROXY_SIGN_OUT_URL is
hardcoded while OAUTH2_PROXY_REDIRECT_URL uses an env-var with a default; change
OAUTH2_PROXY_SIGN_OUT_URL to follow the same pattern by reading an environment
variable with a sensible default (e.g.,
${OAUTH2_PROXY_SIGN_OUT_URL:-https://temporal.gluzdov.com/oauth2/sign_out}) so
both OAUTH2_PROXY_SIGN_OUT_URL and OAUTH2_PROXY_REDIRECT_URL use consistent
environment-variable-with-default semantics.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@docker-compose.prod.yml`:
- Line 114: The OAUTH2_PROXY_SIGN_OUT_URL is hardcoded while
OAUTH2_PROXY_REDIRECT_URL uses an env-var with a default; change
OAUTH2_PROXY_SIGN_OUT_URL to follow the same pattern by reading an environment
variable with a sensible default (e.g.,
${OAUTH2_PROXY_SIGN_OUT_URL:-https://temporal.gluzdov.com/oauth2/sign_out}) so
both OAUTH2_PROXY_SIGN_OUT_URL and OAUTH2_PROXY_REDIRECT_URL use consistent
environment-variable-with-default semantics.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: 243faa9e-e44d-489c-a3f5-2a6274f71c2e

📥 Commits

Reviewing files that changed from the base of the PR and between 90f3fd2 and 07f0c49.

📒 Files selected for processing (1)

• docker-compose.prod.yml

[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.023% 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.023% 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.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.

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

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.486% EPSS Percentile 65th 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/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.

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

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.

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

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.

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

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.

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/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

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

[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