Merge pull request #1031 from jasnow/ghsa-syncbot-2026-04-08-09_52_08

GHSA/SYNC: 2 brand new advisories

Author: flavorjones

gems/addressable/CVE-2026-35611.yml

@@ -0,0 +1,106 @@
+---
+gem: addressable
+cve: 2026-35611
+ghsa: h27x-rffw-24p4
+url: https://github.com/sporkmonger/addressable/security/advisories/GHSA-h27x-rffw-24p4
+title: Addressable has a Regular Expression Denial of Service in
+  Addressable templates
+date: 2026-04-08
+description: |
+  ### Impact
+
+  Within the URI template implementation in Addressable, two classes
+  of URI template generate regular expressions vulnerable to
+  catastrophic backtracking:
+
+  1. Templates using the `*` (explode) modifier with any expansion
+     operator (e.g., `{foo*}`, `{+var*}`, `{#var*}`, `{/var*}`,
+     `{.var*}`, `{;var*}`, `{?var*}`, `{&var*}`) generate patterns
+     with nested unbounded quantifiers that are O(2^n) when matched
+     against a maliciously crafted URI.
+
+  2. Templates using multiple variables with the `+` or `#` operators
+     (e.g., `{+v1,v2,v3}`) generate patterns with O(n^k) complexity
+     due to the comma separator being within the matched character
+     class, causing ambiguous backtracking across k variables.
+
+  When matched against a maliciously crafted URI, this can result
+  in catastrophic backtracking and uncontrolled resource consumption,
+  leading to denial of service. The first pattern was partially
+  addressed in 2.8.10 for certain operator combinations. Both patterns
+  are fully remediated in 2.9.0.
+
+  Users of the URI parsing capabilities in Addressable but not
+  the URI template matching capabilities are unaffected.
+
+  ### Affected Versions
+
+  This vulnerability affects Addressable >= 2.3.0 (note: 2.3.0 and
+  2.3.1 were yanked; the earliest installable release is 2.3.2).
+  It was partially fixed in version 2.8.10 and fully remediated in 2.9.0.
+
+  The vulnerability is more exploitable on MRI Ruby < 3.2 and on all
+  versions of JRuby and TruffleRuby. MRI Ruby 3.2 and later ship with
+  Onigmo 6.9, which introduces memoization that prevents catastrophic
+  backtracking for the first class of template. JRuby and TruffleRuby
+  do not implement equivalent memoization and remain vulnerable
+  to all patterns.
+
+  This has been confirmed on the following runtimes:
+
+  | Runtime      | Status |
+  |--------------|--------|
+  | MRI Ruby 2.6 | Vulnerable |
+  | MRI Ruby 2.7 | Vulnerable |
+  | MRI Ruby 3.0 | Vulnerable |
+  | MRI Ruby 3.1 | Vulnerable |
+  | MRI Ruby 3.2 | Partially vulnerable |
+  | MRI Ruby 3.3 | Partially vulnerable |
+  | MRI Ruby 3.4 | Partially vulnerable |
+  | MRI Ruby 4.0 | Partially vulnerable |
+  | JRuby 10.0   | Vulnerable |
+  | TruffleRuby 21.2 | Vulnerable |
+
+  ### Workarounds
+
+  - **Upgrade to MRI Ruby 3.2 or later**, if your application does
+    not use JRuby or TruffleRuby. The Onigmo memoization introduced
+    in MRI Ruby 3.2 prevents catastrophic backtracking from nested
+    unbounded quantifiers (pattern 1 above — templates using the `*`
+    modifier). It does not reliably mitigate the O(n^k) multi-variable
+    case (pattern 2), so upgrading Ruby alone may not be sufficient
+    if your templates use `{+v1,v2,...}` or `{#v1,v2,...}` syntax.
+
+  - **Avoid using vulnerable template patterns** when matching
+    user-supplied input on unpatched versions of the library:
+
+    - Templates using the `*` (explode) modifier: `{foo*}`, `{+var*}`,
+      `{#var*}`, `{.var*}`, `{/var*}`, `{;var*}`, `{?var*}`, `{&var*}`
+
+    - Templates using multiple variables with the `+` or `#`
+      operators: `{+v1,v2}`, `{#v1,v2,v3}`, etc.
+
+  - **Apply a short timeout** around any call to `Template#match`
+    or `Template#extract` that processes user-supplied data.
+
+  ### Credits
+
+  Discovered in collaboration with @jamfish.
+
+  ### For more information
+
+  If you have any questions or comments about this advisory:
+  * [Open an issue](https://github.com/sporkmonger/addressable/issues)
+cvss_v3: 7.5
+unaffected_versions:
+  - "< 2.3.0"
+patched_versions:
+  - ">= 2.9.0"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-35611
+    - https://github.com/sporkmonger/addressable/security/advisories/GHSA-h27x-rffw-24p4
+    - https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
+    - https://cwe.mitre.org/data/definitions/1333.html
+    - https://www.regular-expressions.info/catastrophic.html
+    - https://github.com/advisories/GHSA-h27x-rffw-24p4

gems/rack-session/CVE-2026-39324.yml

@@ -0,0 +1,75 @@
+---
+gem: rack-session
+cve: 2026-39324
+ghsa: 33qg-7wpp-89cq
+url: https://github.com/rack/rack-session/security/advisories/GHSA-33qg-7wpp-89cq
+title: 'Rack::Session::Cookie secrets: decrypt failure fallback
+  enables secretless session forgery and Marshal deserialization'
+date: 2026-04-08
+description: |
+  'Rack::Session::Cookie incorrectly handles decryption failures when
+  configured with `secrets:`. If cookie decryption fails, the
+  implementation falls back to a default decoder instead of rejecting
+  the cookie. This allows an unauthenticated attacker to supply a
+  crafted session cookie that is accepted as valid session data
+  without knowledge of any configured secret.
+
+  Because this mechanism is used to load session state, an attacker
+  can manipulate session contents and potentially gain unauthorized access.
+
+  ## Details
+
+  When `secrets:` is configured, `Rack::Session::Cookie` attempts to
+  decrypt incoming session cookies using one of the configured encryptors.
+  If all decrypt attempts fail, the implementation does not reject
+  the cookie. Instead, it falls back to decoding the cookie using
+  a default coder.
+
+  This fallback path processes attacker-controlled cookie data as
+  trusted session state. The behavior is implicit and occurs even
+  when encrypted cookies are expected.
+
+  The fallback decoder is applied automatically and does not require
+  the application to opt into a non-encrypted session format. As a
+  result, a client can send a specially crafted cookie value that
+  bypasses the intended integrity protections provided by `secrets:`.
+
+  This issue affects both default configurations and those using
+  alternative serializers for encrypted payloads.
+
+  ## Impact
+
+  Any Rack application using `Rack::Session::Cookie` with
+  `secrets:` may be affected.
+
+  > [!NOTE]
+  > Rails applications are typically not affected — Rails uses
+  > `ActionDispatch::Session::CookieStore`, which is a separate
+  > implementation backed by `ActiveSupport::MessageEncryptor`
+  > and does not share the vulnerable code path.
+
+  An unauthenticated attacker can supply a crafted session cookie
+  that is accepted as valid session data. This can lead to authentication
+  bypass or privilege escalation in applications that rely on session
+  values for identity or authorization decisions.
+
+  Depending on application behavior and available runtime components,
+  processing of untrusted session data may also expose additional risks.
+
+  ## Mitigation
+
+  * Update to a patched version of `rack-session` that rejects cookies
+    when decryption fails under the `secrets:` configuration.
+    * After updating, rotate session secrets to invalidate existing
+      session cookies, since attacker-supplied session data may have
+      been accepted and re-issued prior to the fix.'
+cvss_v4: 9.3
+unaffected_versions:
+  - "< 2.0.0"
+patched_versions:
+  - ">= 2.1.2"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-39324
+    - https://github.com/rack/rack-session/security/advisories/GHSA-33qg-7wpp-89cq
+    - https://github.com/advisories/GHSA-33qg-7wpp-89cq