521 threats tracked across 12 launch stacks — sourced from NVD, GHSA, CISA KEV, OSV, npm Audit, and EPSS.
SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.
Description When using Fiber's Ctx.BodyParser to parse form data containing a large numeric key that represents a slice index (e.g., test.18446744073704), the application crashes due to an out-of-bounds slice allocation in the underlying schema decoder. The root cause is that the decoder attempts to allocate a slice of length idx + 1 without validating whether the index is within a safe or reasonable range. If idx is excessively large, this leads to an integer overflow or memory exhaustion, causing a panic or crash. Steps to Reproduce Create a POST request handler that accepts x-www-form-urlencoded data ``go package main import ( "fmt" "net/http" "github.com/gofiber/fiber/v2" ) type RequestBody struct { NestedContent []struct{} form:"test" } func main() { app := fiber.New() app.Post("/", func(c fiber.Ctx) error { formData := RequestBody{} if err := c.BodyParser(&formData); err != nil { fmt.Println(err) return c.SendStatus(http.StatusUnprocessableEntity) } return nil }) fmt.Println(app.Listen(":3000")) } ` Run the server and send a POST request with a large numeric key in form data, such as: `bash curl -v -X POST localhost:3000 --data-raw 'test.18446744073704' \ -H 'Content-Type: application/x-www-form-urlencoded' ` Relevant Code Snippet Within the decoder's decode method: `go idx := parts[0].index if v.IsNil() || v.Len() < idx+1 { value := reflect.MakeSlice(t, idx+1, idx+1) // <-- Panic/crash occurs here when idx is huge if v.Len() < idx+1 { reflect.Copy(value, v) } v.Set(value) } ` The idx` is not validated before use, leading to unsafe slice allocation for extremely large values. --- Impact Application panic or crash on malicious or malformed input. Potential denial of service (DoS) via memory exhaustion or server crash. Lack of defensive checks in the parsing code causes instability.
Summary When using the fiber.Ctx.BodyParser to parse into a struct with range values, a panic occurs when trying to parse a negative range index Details fiber.Ctx.BodyParser can map flat data to nested slices using key[idx]value syntax, however when idx is negative, it causes a panic instead of returning an error stating it cannot process the data. Since this data is user-provided, this could lead to denial of service for anyone relying on this fiber.Ctx.BodyParser functionality Reproducing Take a simple GoFiberV2 server which returns a JSON encoded version of the FormData ``go package main import ( "encoding/json" "fmt" "net/http" "github.com/gofiber/fiber/v2" ) type RequestBody struct { NestedContent []struct { Value string form:"value" } form:"nested-content" } func main() { app := fiber.New() app.Post("/", func(c fiber.Ctx) error { formData := RequestBody{} if err := c.BodyParser(&formData); err != nil { fmt.Println(err) return c.SendStatus(http.StatusUnprocessableEntity) } c.Set("Content-Type", "application/json") s, _ := json.Marshal(formData) return c.SendString(string(s)) }) fmt.Println(app.Listen(":3000")) } ` Correct Behaviour Send a valid request such as: `bash curl --location 'localhost:3000' \ --form 'nested-content[0].value="Foo"' \ --form 'nested-content[1].value="Bar"' ` You recieve valid JSON `json {"NestedContent":[{"Value":"Foo"},{"Value":"Bar"}]} ` Crashing behaviour Send an invalid request such as: `bash curl --location 'localhost:3000' \ --form 'nested-content[-1].value="Foo"' ` The server panics and crashes ` panic: reflect: slice index out of range goroutine 8 [running]: reflect.Value.Index({0x738000?, 0xc000010858?, 0x0?}, 0x738000?) /usr/lib/go-1.24/src/reflect/value.go:1418 +0x167 github.com/gofiber/fiber/v2/internal/schema.(*Decoder).decode(0xc00002c570, {0x75d420?, 0xc000010858?, 0x7ff424822108?}, {0xc00001c498, 0x17}, {0xc00014e2d0, 0x2, 0x2}, {0xc00002c710, ...}) [...] ` Impact Anyone using fiber.Ctx.BodyParser` can/will have their servers crashed when an invalid payload is sent
The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. <math>, <svg>, etc contexts).
SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.
Summary Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose _Authorization_ header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification) Details See parse.ParseUnverified Impact Excessive memory allocation
Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.
Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/crypto@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
A security vulnerability has been identified in the Fiber session middleware where a user can supply their own session_id 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 session_id 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 validation to ensure session IDs are not supplied by the user and are securely generated by the server. 2. Session Management: Regularly rotate session IDs and enforce strict session expiration policies. References For more information on session best practices: OWASP Session Management Cheat Sheet Users are encouraged to review these references and take immediate action to secure their applications.
parseWildcardRules in Gin-Gonic CORS middleware before 1.6.0 mishandles a wildcard at the end of an origin string, e.g., https://example.community/ is allowed when the intention is that only https://example.com/ should be allowed, and http://localhost.example.com/ is allowed when the intention is that only http://localhost/ should be allowed.
An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.
The CORS middleware allows for insecure configurations that could potentially expose the application to multiple CORS-related vulnerabilities. Specifically, it allows setting the Access-Control-Allow-Origin header to a wildcard ("") while also having the Access-Control-Allow-Credentials set to true, which goes against recommended security best practices. Impact The impact of this misconfiguration is high as it can lead to unauthorized access to sensitive user data and expose the system to various types of attacks listed in the PortSwigger article linked in the references. Proof of Concept The code in cors.go allows setting a wildcard in the AllowOrigins while having AllowCredentials set to true, which could lead to various vulnerabilities. Potential Solution Here is a potential solution to ensure the CORS configuration is secure: ``go func New(config ...Config) fiber.Handler { if cfg.AllowCredentials && cfg.AllowOrigins == "" { panic("[CORS] Insecure setup, 'AllowCredentials' is set to true, and 'AllowOrigins' is set to a wildcard.") } // Return new handler goes below } The middleware will not allow insecure configurations when using AllowCredentials and AllowOrigins. `` Workarounds For the meantime, users are advised to manually validate the CORS configurations in their implementation to ensure that they do not allow a wildcard origin when credentials are enabled. The browser fetch api, browsers and utilities that enforce CORS policies are not affected by this. References MDN Web Docs on CORS Errors CodeQL on CORS Misconfiguration PortSwigger on Exploiting CORS Misconfigurations WhatWG CORS protocol and credentials
Summary Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it. Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Warning: To take effect, both the client and server must support this countermeasure. As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. Details The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSH_MSG_EXT_INFO sent after the first message after SSH_MSG_NEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario. The attack works by an attacker injecting an arbitrary number of SSH_MSG_IGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSH_MSG_IGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange. In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers. For more details see https://terrapin-attack.com. Impact This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. Lack of Token Association: The CSRF token was validated against tokens in storage but was not tied to the original requestor that generated it, allowing for token reuse. Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. Update the Application: Upgrade the application to a fixed version with a patch for the vulnerability. 2. Implement Proper CSRF Protection: Review the updated documentation and ensure your application's CSRF protection mechanisms follow best practices. 4. Choose CSRF Protection Method: Select the appropriate CSRF protection method based on your application's requirements, either the Double Submit Cookie method or the Synchronizer Token Pattern using sessions. 5. Security Testing: Conduct a thorough security assessment, including penetration testing, to identify and address any other security vulnerabilities. Defence-in-depth Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Strict, and the Secure and HttpOnly attributes.
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. Token Injection: For 'safe' methods, the token was extracted from the cookie and saved to storage without further validation or sanitization. 2. Lack of Token Association: The CSRF token was validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse. Specific Go Packages Affected github.com/gofiber/fiber/v2/middleware/csrf Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. Update the Application: Upgrade the application to a fixed version with a patch for the vulnerability. 2. Implement Proper CSRF Protection: Review the updated documentation and ensure your application's CSRF protection mechanisms follow best practices. 4. Choose CSRF Protection Method: Select the appropriate CSRF protection method based on your application's requirements, either the Double Submit Cookie method or the Synchronizer Token Pattern using sessions. 5. Security Testing: Conduct a thorough security assessment, including penetration testing, to identify and address any other security vulnerabilities. Defence-in-depth Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Secure, and the Secure and HttpOnly attributes.
HTTP/2 server vulnerable to rapid stream reset attack causing denial of service.
HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RST_STREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RST_STREAM frame, before any other data from that TCP connection is processed. Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RST_STREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open. The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately. The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth. In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RST_STREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client. Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows. swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress. swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.
The html package (aka x/net/html) through 2018-09-25 in Go mishandles <table><math><select><mi><select></table>, leading to an infinite loop during an html.Parse call because inSelectIM and inSelectInTableIM do not comply with a specification.
Impact This vulnerability can be categorized as a security misconfiguration. It impacts users of our project who rely on the ctx.IsFromLocal() method to restrict access to localhost requests. If exploited, it could allow unauthorized access to resources intended only for localhost. In it's implementation it uses c.IPs(): ``go // IPs returns a string slice of IP addresses specified in the X-Forwarded-For request header. // When IP validation is enabled, only valid IPs are returned. func (c *Ctx) IPs() []string { return c.extractIPsFromHeader(HeaderXForwardedFor) } ` Thereby, setting X-Forwarded-For: 127.0.0.1 in a request from a foreign host, will result in true for ctx.IsFromLocal() Patches This issue has been patched in v2.49.2` with commit b8c9ede6efa231116c4bd8bb9d5e03eac1cb76dc Workarounds Currently, there are no known workarounds to remediate this vulnerability without upgrading to the patched version. We strongly advise users to apply the patch as soon as it is released. References For further information and context regarding this security issue, please refer to the following resources: Mozilla Developer Network - X-Forwarded-For
Text nodes not in the HTML namespace are incorrectly literally rendered, causing text which should be escaped to not be. This could lead to an XSS attack.
Showing 21–40 of 46 threats