GHSA-gv83-gqw6-9j2c
MEDIUMGHSA-gv83-gqw6-9j2c is a medium-severity (CVSS 4.8) CWE-319 vulnerability in github.com/gofiber/fiber. O3 Security confirms whether GHSA-gv83-gqw6-9j2c is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
GoFiber never set HSTS header in helmet middleware due to incorrect protocol check
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 GHSA-gv83-gqw6-9j2c.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-gv83-gqw6-9j2c plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/gofiber/fiberReal-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:
- 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
Secureflag will be sent over HTTP if the user is tricked into an HTTP connection.
This affects any application that:
- Uses the
helmetmiddleware - Configures
HSTSMaxAge > 0expecting 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gofiber/fiber | all versions | 3.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gofiber/fiber. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-gv83-gqw6-9j2c is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-gv83-gqw6-9j2c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gv83-gqw6-9j2c. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gv83-gqw6-9j2c in your dependencies?
O3 detects GHSA-gv83-gqw6-9j2c across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.