Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

CVE-2026-53624 — fiber

MEDIUMFix: gofiber/fiber@04dd4e7

CVE-2026-53624 is a medium-severity (CVSS 4.8) CWE-319 vulnerability in github.com/gofiber/fiber. A fix is available for github.com/gofiber/fiber — see the affected versions and patch details below.

Fiber: HSTS header never set in helmet middleware due to incorrect protocol check

Also known asGHSA-gv83-gqw6-9j2cGO-2026-5912
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-53624.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs11th percentile — riskier than 11% of all scored CVEsHighest risk
0.00%0.24%0.47%0.71%0.2%0.2%0.2%0.2%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-53624 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/gofiber/fiber

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The helmet middleware in gofiber/fiber never sets the Strict-Transport-Security (HSTS) response header, even when HSTSMaxAge is explicitly configured, because the condition check at helmet.go:67 uses c.Protocol() — which returns the HTTP protocol version string (e.g., "HTTP/1.1", "HTTP/2.0") — instead of c.Scheme() — which returns the URL scheme ("http" or "https"). Since c.Protocol() never equals "https" in any real deployment, the HSTS header is permanently disabled, defeating the security protection.

Details

Root cause: middleware/helmet/helmet.go, line 67:

if c.Protocol() == "https" && cfg.HSTSMaxAge != 0 {

c.Protocol() (defined at req.go:865-867) delegates to fasthttp.Request.Header.Protocol(), which returns the HTTP protocol version:

  • "HTTP/1.1" for HTTP/1.1 connections
  • "HTTP/2.0" for HTTP/2 connections

The correct method is c.Scheme() (defined at req.go:844-862), which returns:

  • "http" for plain HTTP connections
  • "https" for TLS connections

Since "HTTP/1.1" != "https" always evaluates to true, the entire HSTS block (lines 67-76) is dead code.

Note on test coverage: The existing helmet test (helmet_test.go) passes because it uses ctx.Request.Header.SetProtocol("https") to artificially force Protocol() to return "https". However, fasthttp.Request.Header.SetProtocol() sets the HTTP version field, and real HTTP requests never have protocol "https" — they have "HTTP/1.1" or "HTTP/2.0". The test is validating the wrong thing.

PoC

Clean-checkout maintainer-runnable recipe:

  1. Save the following as middleware/helmet/poc_hsts_test.go:
package helmet

import (
    "crypto/tls"
    "net/http/httptest"
    "testing"

    "github.com/gofiber/fiber/v3"
)

func Test_PoC_HSTS_NeverSet(t *testing.T) {
    app := fiber.New()
    app.Use(New(Config{
        HSTSMaxAge: 31536000,
    }))
    app.Get("/", func(c fiber.Ctx) error {
        return c.SendString("ok")
    })

    // Simulate HTTPS connection
    req := httptest.NewRequest(fiber.MethodGet, "/", nil)
    req.TLS = &tls.ConnectionState{}

    resp, _ := app.Test(req)
    hsts := resp.Header.Get("Strict-Transport-Security")

    if hsts == "" {
        t.Log("BUG CONFIRMED: HSTS header not set. c.Protocol() returns 'HTTP/1.1', not 'https'")
        t.Log("Fix: change c.Protocol() == 'https' to c.Scheme() == 'https' on line 67")
    }
}
  1. Run: go test -run Test_PoC_HSTS_NeverSet -v ./middleware/helmet/

Expected vulnerable output:

=== RUN   Test_PoC_HSTS_NeverSet
    BUG CONFIRMED: HSTS header not set. c.Protocol() returns 'HTTP/1.1', not 'https'
    Fix: change c.Protocol() == 'https' to c.Scheme() == 'https' on line 67
--- PASS: Test_PoC_HSTS_NeverSet

Expected output after fix:

=== RUN   Test_PoC_HSTS_NeverSet
--- PASS: Test_PoC_HSTS_NeverSet
    (HSTS header is set: "max-age=31536000; includeSubDomains")

Observed output from this environment (commit ee98695f):

=== RUN   Test_PoC_HSTS_NeverSet
    poc_hsts_test.go:39: HSTS header value: ""
    poc_hsts_test.go:42: BUG CONFIRMED: HSTS header is NOT set even over TLS
    poc_hsts_test.go:43: Root cause: helmet.go:67 uses c.Protocol() which returns HTTP version
    poc_hsts_test.go:44: c.Protocol() returns 'HTTP/1.1' not 'https'
    poc_hsts_test.go:45: Fix: use c.Scheme() == 'https' instead of c.Protocol() == 'https'
--- PASS: Test_PoC_HSTS_NeverSet

Negative/control case: With HSTSMaxAge: 0 (default), HSTS is correctly not set (this is expected behavior, not a bug).

Cleanup: Remove poc_hsts_test.go after verification.

Impact

The HSTS header is never applied in production, leaving all users vulnerable to:

  • SSL stripping attacks: An active network attacker can downgrade HTTPS connections to HTTP, intercepting traffic between the client and server.
  • Protocol downgrade: Without HSTS, browsers will silently accept HTTP connections to the site, even if the site supports HTTPS.
  • Cookie theft over HTTP: Session cookies without the Secure flag will be sent over HTTP if the user is tricked into an HTTP connection.

This affects any application that:

  1. Uses the helmet middleware
  2. Configures HSTSMaxAge > 0 expecting HSTS protection
  3. Serves traffic over HTTPS

The vulnerability requires an active MITM attacker on the network path, which is realistic in public Wi-Fi, corporate networks, and ISP-level scenarios.

Suggested remediation

In middleware/helmet/helmet.go, line 67, replace c.Protocol() with c.Scheme():

// Before (broken):
if c.Protocol() == "https" && cfg.HSTSMaxAge != 0 {

// After (fixed):
if c.Scheme() == "https" && cfg.HSTSMaxAge != 0 {

Additionally, update the existing test to use a realistic TLS simulation instead of SetProtocol("https"):

// Before (artificial - sets HTTP version to "https" which never happens in practice):
ctx.Request.Header.SetProtocol("https")

// After (realistic - simulates TLS connection):
ctx.RequestCtx().Request.Header.SetProtocol("HTTP/1.1")
ctx.RequestCtx().TLS = &tls.ConnectionState{}

Regression test: Add a test case that verifies HSTS is set when req.TLS is non-nil and HSTSMaxAge > 0, without using SetProtocol.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/gofiber/fiberall versions3.4.0go get github.com/gofiber/fiber@v3.4.0

Affected Products

1 product · 1 configurations
Application
fibergofiber
< 3.4.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gofiber/fiber, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/gofiber/fiber to 3.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-53624 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Summary The `helmet` middleware in gofiber/fiber never sets the `Strict-Transport-Security` (HSTS) response header, even when `HSTSMaxAge` is explicitly configured, because the condition check at `helmet.go:67` uses `c.Protocol()` — which returns the HTTP protocol version string (e.g., `"HTTP/1.1"`, `"HTTP/2.0"`) — instead of `c.Scheme()` — which returns the URL scheme (`"http"` or `"https"`). Since `c.Protocol()` never equals `"https"` in any real deployment, the HSTS header is permanently disabled, defeating the security protection. ### Details **Root cause:** `middleware/helmet/helme
O3 Security · Impact-Aware SCA

Is CVE-2026-53624 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-53624: fiber — Fixed in 3.4.0