Skip to content

← Public intelligence

Go package

github.com/gofiber/fiber

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 4.8GoPublished

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

    CVE-2026-53624 · GHSA-gv83-gqw6-9j2c

    Affected
    • Go github.com/gofiber/fiber <= 3.3.0
    Fixed in
    3.4.0· Vendor fix available
    Issue
    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: 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…

    Recommended action: Upgrade to 3.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. Critical, CVSS 10.0GoPublished

    Session Middleware Token Injection Vulnerability

    CVE-2024-38513 · GHSA-98j2-3j3p-fw2v

    Affected
    • Go github.com/gofiber/fiber <= 2.52.4
    Fixed in
    2.52.5· Vendor fix available
    Issue
    A security vulnerability has been identified in the Fiber session middleware where a user can supply their own sessionid value, leading to the creation of a session with that key. Impact The identified vulnerability is a session middleware issue in GoFiber versions 2 and above. This vulnerability allows users to supply their own sessionid value, resulting in the creation of a session with that key. If a website relies on the mere presence of a session for security purposes, this can lead to significant security risks, including unauthorized access and session fixation attacks. All users utilizing GoFiber's session middleware in the affected versions are impacted. Patches The issue has been addressed in the latest patch. Users are strongly encouraged to upgrade to version 2.52.5 or higher to mitigate this vulnerability. Workarounds Users who are unable to upgrade immediately can apply the following workarounds to reduce the risk: 1. Validate Session IDs: Implement additional…

    Recommended action: Upgrade to 2.52.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. Medium, CVSS 4.2GoPublished

    CRLF vulnerability in Fiber

    CVE-2020-15111 · GHSA-9cx9-x2gp-9qvh

    Affected
    • Go github.com/gofiber/fiber < 1.12.6
    Fixed in
    1.12.6· Vendor fix available
    Issue
    Impact The filename that is given in c.Attachment() is not escaped, and therefore vulnerable for a CRLF injection attack. I.e. an attacker could upload a custom filename and then give the link to the victim. With this filename, the attacker can change the name of the downloaded file, redirect to another site, change the authorization header, etc. Steps to reproduce Patches This issue has been patched in v1.12.6 with commit 579 escaping the filename by default. Workarounds You could of course serialize the input yourself before passing it to ctx.Attachment(), this is actually a good practice by default. But in case you forget, we got you covered 👍 References A CRLF injection attack is one of several types of injection attacks. It can be used to escalate to more malicious attacks such as Cross-site Scripting (XSS), page injection, web cache poisoning, cache-based defacement, and more. A CRLF injection vulnerability exists if an attacker can inject the CRLF characters into a web…

    Recommended action: Upgrade to 1.12.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →