CVE-2026-53624

MEDIUMPre-NVD 4.84.8
EchelonGraph scoreLOW confidence

This medium-severity CVE scores 4.8 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m
4.8
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: CVSS: 4.8Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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

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:

  • 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") } }

  • 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:

  • Uses the helmet middleware
  • Configures HSTSMaxAge > 0 expecting HSTS protection
  • 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.

CVSS v3
4.8
EG Score
4.8(low)
EPSS
KEV
Not listed

Published

July 6, 2026

Last Modified

July 6, 2026

Vendor Advisories for CVE-2026-53624(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 1× in last 7d / 1× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-06 21:36 UTCEG score recompute

Frequently asked(4)

What is CVE-2026-53624?
CVE-2026-53624 is a medium vulnerability published on July 6, 2026. GoFiber never set HSTS header in helmet middleware due to incorrect protocol check 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…
When was CVE-2026-53624 disclosed?
CVE-2026-53624 was first published in the National Vulnerability Database on July 6, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
What is the CVSS score of CVE-2026-53624?
CVE-2026-53624 has a CVSS v4.0 base score of 4.8 (CNA self-assessment; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-53624?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-53624, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-53624

Explore →

Is Your Infrastructure Affected by CVE-2026-53624?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.