CVE-2023-50693: Critical Request Handling Flaw in Nim Jester

CVE-2023-50693 is a critical flaw in Jester, a Nim web framework, in version 0.6.0 and earlier. NVD scores it 9.8 and says a crafted request is enough. The linked report calls it HTTP request smuggling. No fixed version is confirmed, so put Jester behind a reverse proxy and check the project for updates.

What's affected

The NVD record lists Jester 0.6.0 and before. It says only that a remote attacker can send a "malicious crafted request". The record carries no CWE and was published on 2024-01-19.

NVD scores it 9.8 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The record is vague, so the linked GitHub issue is the better guide. It is titled as an HTTP/1.1 request smuggling security issue, filed in December 2023 against the then latest versions of Jester and its HTTP server, HttpBeast.

The sources do not give a fixed version. The maintainer closed the report as completed on the same day and, in the linked HttpBeast discussion, said the library expects to sit behind a reverse proxy that protects against this class of problem, and that significant hardening would be needed before facing the open internet. The record also links pull request 327 on the Jester repository, which was not confirmed as a fix. Treat the maintainer's guidance as the advisory position and note it differs from the 9.8 score, which assumes direct exposure.

How to check if you're exposed

Check which Jester version your project resolves. In a Nimble project, look at the requires lines in your .nimble file and at the nimble.lock file if you use one:

nimble list -i

Any Jester at 0.6.0 or below matches the record. Also check how the service is deployed. A Jester app that listens directly on a public port is the case the report worries about. One that sits behind a reverse proxy that normalizes and validates requests is much less exposed.

Remember that Jester depends on HttpBeast, so check that library too. It has its own record, CVE-2023-50694.

What to do now

1. List every service built on Jester and the version each one uses.
2. Put each one behind a mature reverse proxy and do not expose the Jester port directly.
3. Configure the proxy to reject ambiguous requests, such as those with conflicting length headers, and to use a single HTTP version to the backend.
4. Watch the Jester repository and pull request 327 for a release that addresses the report, and upgrade when one is published.
5. If the service must face the internet directly, plan a move to a framework with active maintenance.

Why it matters

HTTP request smuggling happens when two systems in a chain disagree about where one request ends and the next begins. A front end sees one request, the back end sees two, and the second can be treated as if it came from a different user or skip checks done by the front end.

Frameworks with their own hand written HTTP parsers are prone to this because the rules around message length are subtle. The record gives no CWE for this entry, so the class here comes from the linked report, not from NVD.

The record shows no CISA Known Exploited Vulnerabilities listing, and the fetched pages do not report exploitation in the wild.

Quick check

Sources

• Jester GitHub issue 326, HTTP request smuggling report
• Jester pull request 327 (linked in the record, not confirmed as a fix)

Last reviewed: 19 October 2026.