Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-09-01 11:17
Modified
2026-09-02 06:39
Summary
Security fixes in step-ca 0.27.5-r0
Details
Package step-ca version 0.27.5-r0 fixes 14 vulnerabilities: CVE-2026-33186, CVE-2025-27144, CVE-2026-34986, CVE-2025-22868, CVE-2026-25793...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "step-ca"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.27.5-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.27.5-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package step-ca version 0.27.5-r0 fixes 14 vulnerabilities: CVE-2026-33186, CVE-2025-27144, CVE-2026-34986, CVE-2025-22868, CVE-2026-25793...",
"id": "CLEANSTART-2026-SL17084",
"modified": "2026-09-02T06:39:10Z",
"published": "2026-09-01T11:17:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/smallstep/certificates"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in step-ca 0.27.5-r0",
"upstream": [
"CVE-2026-33186",
"CVE-2025-27144",
"CVE-2026-34986",
"CVE-2025-22868",
"CVE-2026-25793",
"CVE-2025-62820",
"CVE-2024-45339",
"CVE-2026-26958",
"CVE-2025-30204",
"ghsa-vrw8-fxc6-2r93",
"ghsa-9g5q-2w5x-hmxf",
"ghsa-rjr7-jggh-pgcp",
"ghsa-259r-337f-4rfw",
"ghsa-hrxh-6v49-42gf"
]
}
GHSA-9G5Q-2W5X-HMXF
Vulnerability from github – Published: 2026-06-25 18:18 – Updated: 2026-06-25 18:18
VLAI
Summary
chi Middleware Vulnerable to Potential IP Spoofing via `X-Forwarded-For` Header in `Request.RemoteAddr` Resolution
Details
Summary
The vulnerability allows the Request.RemoteAddr to be spoofed when determining the request source IP via the X-Forwarded-For header. This could result in misidentification of the request source and potentially compromise access control and logging integrity.
Details
Currently, the RealIP() implementation splits the X-Forwarded-For header by , and uses the first IP.
https://github.com/go-chi/chi/blob/v5.1.0/middleware/realip.go#L50-L54
However, relying on the first IP in the X-Forwarded-For header is insecure because it can be manipulated by attackers to falsify the source IP.
Malicious Case:
1. A malicious client sends a request with a forged IP in the X-Forwarded-For header: X-Forwarded-For: <forged-ip>
2. The proxy appends the actual client’s IP and forwards the request: X-Forwarded-For: <forged-ip>,<client-ip>
3. If the server always uses the first IP, it becomes vulnerable to IP spoofing.
Ideally, the implementation should verify IPs starting from the end of the X-Forwarded-For header value, skipping trusted IPs within the system, and using the first untrusted IP as the actual client IP.
For example, the labstack/echo web framework processes the X-Forwarded-For header by checking IPs from the end, skipping trusted IPs, and using the first untrusted IP as the client's ip.
https://github.com/labstack/echo/blob/v4.13.2/ip.go#L261-L273
PoC
1. Run the Go application with the following code:
package main
import (
"fmt"
"log"
"net/http"
"github.com/go-chi/chi/v5/middleware"
)
func main() {
// Set handler to print the remote address
handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(
w,
fmt.Sprintf("remote addr: %s (want 192.0.2.1)", r.RemoteAddr),
)
})
// Use RealIP middleware
log.Fatal(http.ListenAndServe(":8080", middleware.RealIP(handler)))
}
2. Send a request to the server using curl with a manipulated X-Forwarded-For header:
$ curl localhost:8080 -H 'X-Forwarded-For: 192.0.2.2, 192.0.2.1'
remote addr: 192.0.2.2 (want 192.0.2.1)
Impact
This vulnerability can lead to a request source IP spoofing issue, which may allow attackers to bypass access controls or falsify request logs. It primarily affects systems that rely on X-Forwarded-For to determine the actual client IP, particularly in scenarios where intermediary proxies or load balancers are involved.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"last_affected": "1.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v2/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v3/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.3.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v4/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v5/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T18:18:56Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nThe vulnerability allows the `Request.RemoteAddr` to be spoofed when determining the request source IP via the `X-Forwarded-For` header. This could result in misidentification of the request source and potentially compromise access control and logging integrity.\n\n### Details\nCurrently, the `RealIP()` implementation splits the `X-Forwarded-For` header by `,` and uses the first IP.\nhttps://github.com/go-chi/chi/blob/v5.1.0/middleware/realip.go#L50-L54\n\nHowever, relying on the first IP in the `X-Forwarded-For` header is insecure because it can be manipulated by attackers to falsify the source IP.\n\nMalicious Case:\n1. A malicious client sends a request with a forged IP in the X-Forwarded-For header: `X-Forwarded-For: \u003cforged-ip\u003e`\n2. The proxy appends the actual client\u2019s IP and forwards the request: `X-Forwarded-For: \u003cforged-ip\u003e,\u003cclient-ip\u003e`\n3. If the server always uses the first IP, it becomes vulnerable to IP spoofing.\n\nIdeally, the implementation should verify IPs starting from the end of the `X-Forwarded-For` header value, skipping trusted IPs within the system, and using the first untrusted IP as the actual client IP.\n\nFor example, the `labstack/echo` web framework processes the `X-Forwarded-For` header by checking IPs from the end, skipping trusted IPs, and using the first untrusted IP as the client\u0027s ip.\nhttps://github.com/labstack/echo/blob/v4.13.2/ip.go#L261-L273\n\n### PoC\n#### 1. Run the Go application with the following code:\n```go\npackage main\n\nimport (\n \"fmt\"\n \"log\"\n \"net/http\"\n\n \"github.com/go-chi/chi/v5/middleware\"\n)\n\nfunc main() {\n // Set handler to print the remote address\n handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n fmt.Fprintln(\n w,\n fmt.Sprintf(\"remote addr: %s (want 192.0.2.1)\", r.RemoteAddr),\n )\n })\n // Use RealIP middleware\n log.Fatal(http.ListenAndServe(\":8080\", middleware.RealIP(handler)))\n}\n```\n#### 2. Send a request to the server using curl with a manipulated X-Forwarded-For header:\n```\n$ curl localhost:8080 -H \u0027X-Forwarded-For: 192.0.2.2, 192.0.2.1\u0027\nremote addr: 192.0.2.2 (want 192.0.2.1)\n```\n\n### Impact\nThis vulnerability can lead to a request source IP spoofing issue, which may allow attackers to bypass access controls or falsify request logs. It primarily affects systems that rely on X-Forwarded-For to determine the actual client IP, particularly in scenarios where intermediary proxies or load balancers are involved.",
"id": "GHSA-9g5q-2w5x-hmxf",
"modified": "2026-06-25T18:18:56Z",
"published": "2026-06-25T18:18:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-chi/chi/security/advisories/GHSA-9g5q-2w5x-hmxf"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-chi/chi"
},
{
"type": "WEB",
"url": "https://github.com/go-chi/chi/releases/tag/v5.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "chi Middleware Vulnerable to Potential IP Spoofing via `X-Forwarded-For` Header in `Request.RemoteAddr` Resolution"
}
GHSA-HRXH-6V49-42GF
Vulnerability from github – Published: 2026-07-21 22:03 – Updated: 2026-07-21 22:03
VLAI
Summary
gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities
Details
Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:
- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing
MetadataorRequestedServerNamefields. - Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing
NOTrules around unsupported fields.
Impact
What kind of vulnerability is it? Who is impacted?
xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers
- Affected Component: xDS RBAC
- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported
permissionandprincipalrules (specificallyMetadataandRequestedServerName) were silently ignored and treated as no-ops. - If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
- If these unsupported rules were nested inside logical
NOTrules (Permission_NotRule/Principal_NotId) or multi-conditionOR/ANDrules, silently dropping them changed the boolean logic flow of the authorization engine.
As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.
HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
- Affected Component: HTTP/2 transport
- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as
SETTINGSACKs or server-initiatedRST_STREAMs.
When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).
Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
- Affected Component: xDS RBAC
- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a
NOTrule wrapped an unsupported or unhandled field (such asSourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.
An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).
Patches
Has the problem been patched? What versions should users upgrade to?
All three issues have been fixed in master and will be released in 1.82.1 shortly.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:
- For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing
Metadata,RequestedServerName, orNOTrules wrapping unsupported fields (such asSourcedMetadata) to grpc-go servers. - For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2
max_concurrent_streamslimits and active rate limiting onRST_STREAMfrequency per connection.
Severity
| Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |
|---|---|---|---|
| xDS RBAC Authorization Bypass | High | 8.2 |
Unauthorized Access / Fail-Open |
| HTTP/2 Rapid Reset DOS Bypass | High | 7.5 |
High CPU Consumption / Denial of Service |
| xDS RBAC Engine Server Panic | Medium | 5.9 |
Process Crash / Denial of Service |
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "google.golang.org/grpc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.82.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-770",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T22:03:55Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:\n\n- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing `Metadata` or `RequestedServerName` fields.\n- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.\n- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing `NOT` rules around unsupported fields.\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\n#### xDS RBAC Authorization Bypass via `Metadata` \u0026 `RequestedServerName` matchers\n\n- Affected Component: xDS RBAC \n- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported `permission` and `principal` rules (specifically `Metadata` and `RequestedServerName`) were silently ignored and treated as no-ops.\n - If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.\n- If these unsupported rules were nested inside logical `NOT` rules (`Permission_NotRule` / `Principal_NotId`) or multi-condition `OR/AND` rules, silently dropping them changed the boolean logic flow of the authorization engine.\n\nAs a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.\n\n#### HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts\n\n- Affected Component: HTTP/2 transport\n- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as `SETTINGS` ACKs or server-initiated `RST_STREAM`s.\n\nWhen a client initiated a rapid flood of stream creation (`HEADERS`) immediately followed by stream termination `RST_STREAM`, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).\n\n#### Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules\n\n- Affected Component: xDS RBAC \n- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a `NOT` rule wrapped an unsupported or unhandled field (such as `SourcedMetadata`), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.\n\nAn attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a `NOT` rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nAll three issues have been fixed in `master` and will be released in 1.82.1 shortly.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:\n\n* For xDS RBAC Vulnerabilities \u0026 Panics: Ensure that upstream xDS management servers do not push RBAC policies containing `Metadata`, `RequestedServerName`, or `NOT` rules wrapping unsupported fields (such as `SourcedMetadata`) to grpc-go servers.\n* For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 `max_concurrent_streams` limits and active rate limiting on `RST_STREAM` frequency per connection.\n\n### Severity\n\n | Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |\n | :--- | :--- | :--- | :--- |\n | **xDS RBAC Authorization Bypass** | **High** | `8.2` | Unauthorized Access / Fail-Open |\n | **HTTP/2 Rapid Reset DOS Bypass** | **High** | `7.5` | High CPU Consumption / Denial of Service |\n | **xDS RBAC Engine Server Panic** | **Medium** | `5.9` | Process Crash / Denial of Service |",
"id": "GHSA-hrxh-6v49-42gf",
"modified": "2026-07-21T22:03:56Z",
"published": "2026-07-21T22:03:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-hrxh-6v49-42gf"
},
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/pull/9236"
},
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/commit/4ea465d4ab98013f72a142fe0fc89c19770b2935"
},
{
"type": "PACKAGE",
"url": "https://github.com/grpc/grpc-go"
},
{
"type": "WEB",
"url": "https://github.com/grpc/grpc-go/releases/tag/v1.82.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities"
}
GHSA-RJR7-JGGH-PGCP
Vulnerability from github – Published: 2026-06-25 18:19 – Updated: 2026-06-25 18:19
VLAI
Summary
chi's RealIP Middleware allows IP spoofing via unvalidated X-Forwarded-For header
Details
Summary
realip middleware in go-chi/chi trusts headers like x-forwarded-for without checking them, so attackers can fake their ip and bypass rate limits or access controls
Details
the vuln is in middleware/realip.go , the realIP() function pulls IPs straight from client headers and replaces r.RemoteAddr without checking if the request came from a trusted proxy
func realIP(r *http.Request) string {
var ip string
if tcip := r.Header.Get(trueClientIP); tcip != "" {
ip = tcip // controlled by attacker
} else if xrip := r.Header.Get(xRealIP); xrip != "" {
ip = xrip // controlled by attacker
} else if xff := r.Header.Get(xForwardedFor); xff != "" {
ip, _, _ = strings.Cut(xff, ",") // controlled by attacker
}
// ...
return ip
}
no trusted proxy cidr check in place, any client can send these headers
PoC
create a server with chi and use realip middleware
package main
import (
"fmt"
"net/http"
"github.com/go-chi/chi/v5"
"github.com/go-chi/chi/v5/middleware"
)
func main() {
r := chi.NewRouter()
r.Use(middleware.RealIP)
r.Get("/admin", func(w http.ResponseWriter, r *http.Request) {
// ip-based access control got bypassed
if r.RemoteAddr == "127.0.0.1" {
w.Write([]byte("SECRET ADMIN DATA"))
return
}
http.Error(w, "Forbidden", 403)
})
http.ListenAndServe(":8080", r)
}
spoofed the ip to bypass access control
curl -H "X-Forwarded-For: 127.0.0.1" http://localhost:8080/admin
Impact
- ip-based access control bypass lets attackers reach restricted endpoints
- rate limiting bypass lets attackers avoid limits by rotating spoofed ips
- audit logs show fake ips picked by attacker instead of real ones
- attackers can get around geo ip restrictions
Remediation Recommendation
validate proxy cidr first before trusting forwarded ip headers
// add your reverse proxy ip addresses here
var trustedProxies = []net.IPNet{
{IP: net.ParseIP("10.0.0.0"), Mask: net.CIDRMask(8, 32)},
{IP: net.ParseIP("172.16.0.0"), Mask: net.CIDRMask(12, 32)},
{IP: net.ParseIP("192.168.0.0"), Mask: net.CIDRMask(16, 32)},
}
func isTrustedProxy(ip net.IP) bool {
for _, cidr := range trustedProxies {
if cidr.Contains(ip) {
return true
}
}
return false
}
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v2/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v3/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.3.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v4/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v5/middleware"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-348"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T18:19:15Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nrealip middleware in go-chi/chi trusts headers like x-forwarded-for without checking them, so attackers can fake their ip and bypass rate limits or access controls\n\n### Details\n\nthe vuln is in middleware/realip.go , the realIP() function pulls IPs straight from client headers and replaces r.RemoteAddr without checking if the request came from a trusted proxy\n\n```go\nfunc realIP(r *http.Request) string {\n var ip string\n if tcip := r.Header.Get(trueClientIP); tcip != \"\" {\n ip = tcip // controlled by attacker\n } else if xrip := r.Header.Get(xRealIP); xrip != \"\" {\n ip = xrip // controlled by attacker\n } else if xff := r.Header.Get(xForwardedFor); xff != \"\" {\n ip, _, _ = strings.Cut(xff, \",\") // controlled by attacker\n }\n // ...\n return ip\n}\n```\n\nno trusted proxy cidr check in place, any client can send these headers\n\n### PoC\n\ncreate a server with chi and use realip middleware\n\n```go\npackage main\n\nimport (\n \"fmt\"\n \"net/http\"\n \"github.com/go-chi/chi/v5\"\n \"github.com/go-chi/chi/v5/middleware\"\n)\n\nfunc main() {\n r := chi.NewRouter()\n r.Use(middleware.RealIP)\n\n r.Get(\"/admin\", func(w http.ResponseWriter, r *http.Request) {\n // ip-based access control got bypassed\n if r.RemoteAddr == \"127.0.0.1\" {\n w.Write([]byte(\"SECRET ADMIN DATA\"))\n return\n }\n http.Error(w, \"Forbidden\", 403)\n })\n\n http.ListenAndServe(\":8080\", r)\n}\n```\n\nspoofed the ip to bypass access control\n\n```bash\ncurl -H \"X-Forwarded-For: 127.0.0.1\" http://localhost:8080/admin\n```\n\n\n### Impact\n\n- ip-based access control bypass lets attackers reach restricted endpoints\n- rate limiting bypass lets attackers avoid limits by rotating spoofed ips\n- audit logs show fake ips picked by attacker instead of real ones\n- attackers can get around geo ip restrictions\n\n## Remediation Recommendation\n\nvalidate proxy cidr first before trusting forwarded ip headers\n\n```go\n// add your reverse proxy ip addresses here\nvar trustedProxies = []net.IPNet{\n {IP: net.ParseIP(\"10.0.0.0\"), Mask: net.CIDRMask(8, 32)},\n {IP: net.ParseIP(\"172.16.0.0\"), Mask: net.CIDRMask(12, 32)},\n {IP: net.ParseIP(\"192.168.0.0\"), Mask: net.CIDRMask(16, 32)},\n}\n\nfunc isTrustedProxy(ip net.IP) bool {\n for _, cidr := range trustedProxies {\n if cidr.Contains(ip) {\n return true\n }\n }\n return false\n}\n```",
"id": "GHSA-rjr7-jggh-pgcp",
"modified": "2026-06-25T18:19:15Z",
"published": "2026-06-25T18:19:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-chi/chi/security/advisories/GHSA-rjr7-jggh-pgcp"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-chi/chi"
},
{
"type": "WEB",
"url": "https://github.com/go-chi/chi/releases/tag/v5.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "chi\u0027s RealIP Middleware allows IP spoofing via unvalidated X-Forwarded-For header"
}
GHSA-VRW8-FXC6-2R93
Vulnerability from github – Published: 2025-06-20 16:37 – Updated: 2025-10-13 15:41
VLAI
Summary
chi Allows Host Header Injection which Leads to Open Redirect in RedirectSlashes
Details
Summary
The RedirectSlashes function in middleware/strip.go is vulnerable to host header injection which leads to open redirect.
We consider this a lower-severity open redirect, as it can't be exploited from browsers or email clients (requires manipulation of a Host header).
Details
The RedirectSlashes method uses the Host header to construct the redirectURL at this line https://github.com/go-chi/chi/blob/master/middleware/strip.go#L55
The Host header can be manipulated by a user to be any arbitrary host. This leads to open redirect when using the RedirectSlashes middleware
PoC
Create a simple server which uses the RedirectSlashes middleware
package main
import (
"fmt"
"net/http"
"github.com/go-chi/chi/v5"
"github.com/go-chi/chi/v5/middleware" // Import the middleware package
)
func main() {
// Create a new Chi router
r := chi.NewRouter()
// Use the built-in RedirectSlashes middleware
r.Use(middleware.RedirectSlashes) // Use middleware.RedirectSlashes
// Define a route handler
r.Get("/", func(w http.ResponseWriter, r *http.Request) {
// A simple response
w.Write([]byte("Hello, World!"))
})
// Start the server
fmt.Println("Starting server on :8080")
http.ListenAndServe(":8080", r)
}
Run the server go run main.go
Once the server is running, send a request that will trigger the RedirectSlashes function with an arbitrary Host header
curl -iL -H "Host: example.com" http://localhost:8080/test/
Observe that the request will be redirected to example.com
curl -L -H "Host: example.com" http://localhost:8080/test/
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
... snipped ...
Without the host header, the response is returned from the test server
curl -L http://localhost:8080/test/
404 page not found
Impact
An open redirect vulnerability allows attackers to trick users into visiting malicious sites. This can lead to phishing attacks, credential theft, and malware distribution, as users trust the application’s domain while being redirected to harmful sites.
Potential mitigation
It seems that the purpose of the RedirectSlashes function is to redirect within the same application. In that case r.RequestURI can be used instead of r.Host by default. If there is a use case to redirect to a different host, a flag can be added to use the Host header instead. As this flag will be controlled by the developer they will make the decision of allowing redirects to arbitrary hosts based on their judgement.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.2.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-chi/chi/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-20T16:37:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe RedirectSlashes function in middleware/strip.go is vulnerable to host header injection which leads to open redirect.\n\nWe consider this a **lower-severity** open redirect, as it can\u0027t be exploited from browsers or email clients (requires manipulation of a Host header).\n\n### Details\nThe RedirectSlashes method uses the Host header to construct the redirectURL at this line https://github.com/go-chi/chi/blob/master/middleware/strip.go#L55\n\nThe Host header can be manipulated by a user to be any arbitrary host. This leads to open redirect when using the RedirectSlashes middleware\n\n### PoC\nCreate a simple server which uses the RedirectSlashes middleware\n```\npackage main\n\nimport (\n\t\"fmt\"\n\t\"net/http\"\n\n\t\"github.com/go-chi/chi/v5\"\n\t\"github.com/go-chi/chi/v5/middleware\" // Import the middleware package\n)\n\nfunc main() {\n\t// Create a new Chi router\n\tr := chi.NewRouter()\n\n\t// Use the built-in RedirectSlashes middleware\n\tr.Use(middleware.RedirectSlashes) // Use middleware.RedirectSlashes\n\n\t// Define a route handler\n\tr.Get(\"/\", func(w http.ResponseWriter, r *http.Request) {\n\t\t// A simple response\n\t\tw.Write([]byte(\"Hello, World!\"))\n\t})\n\n\t// Start the server\n\tfmt.Println(\"Starting server on :8080\")\n\thttp.ListenAndServe(\":8080\", r)\n}\n```\nRun the server `go run main.go`\n\nOnce the server is running, send a request that will trigger the RedirectSlashes function with an arbitrary Host header\n`curl -iL -H \"Host: example.com\" http://localhost:8080/test/`\n\nObserve that the request will be redirected to example.com\n\n```\ncurl -L -H \"Host: example.com\" http://localhost:8080/test/\n\n\u003c!doctype html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n \u003ctitle\u003eExample Domain\u003c/title\u003e\n\n \u003cmeta charset=\"utf-8\" /\u003e\n \u003cmeta http-equiv=\"Content-type\" content=\"text/html; charset=utf-8\" /\u003e\n \u003cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1\" /\u003e\n \u003cstyle type=\"text/css\"\u003e\n body {\n background-color: #f0f0f2;\n margin: 0;\n padding: 0;\n font-family: -apple-system, system-ui, BlinkMacSystemFont, \"Segoe UI\", \"Open Sans\", \"Helvetica Neue\", Helvetica, Arial, sans-serif;\n... snipped ...\n```\nWithout the host header, the response is returned from the test server\n```\ncurl -L http://localhost:8080/test/\n\n404 page not found\n```\n\n### Impact\nAn open redirect vulnerability allows attackers to trick users into visiting malicious sites. This can lead to phishing attacks, credential theft, and malware distribution, as users trust the application\u2019s domain while being redirected to harmful sites.\n\n### Potential mitigation\nIt seems that the purpose of the RedirectSlashes function is to redirect within the same application. In that case r.RequestURI can be used instead of r.Host by default. If there is a use case to redirect to a different host, a flag can be added to use the Host header instead. As this flag will be controlled by the developer they will make the decision of allowing redirects to arbitrary hosts based on their judgement.",
"id": "GHSA-vrw8-fxc6-2r93",
"modified": "2025-10-13T15:41:17Z",
"published": "2025-06-20T16:37:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-chi/chi/security/advisories/GHSA-vrw8-fxc6-2r93"
},
{
"type": "WEB",
"url": "https://github.com/go-chi/chi/commit/1be7ad938cc9c5b39a9dea01a5c518848928ab65"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-chi/chi"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "chi Allows Host Header Injection which Leads to Open Redirect in RedirectSlashes"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…