A `\:` route and a `:param` route at the same position make `ServeHTTP` panic or return 404

[DRMacIver]

Issue Description

Registering a route with an escaped colon (/name\:verb/x) together with a route that has a
parameter at the same position (/name:id) makes one of them unreachable, depending on the order:
registered in that order, GET /name:verb/x panics inside ServeHTTP with index out of range [-1] and GET /name1 is a 404; registered the other way round, GET /name:verb/x is a 404. Each
route on its own is served as expected.

Working code to debug

package main

import (
	"fmt"
	"net/http"
	"net/http/httptest"
	"strings"

	"github.com/labstack/echo/v5"
)

func get(e *echo.Echo, path string) (out string) {
	defer func() {
		if r := recover(); r != nil {
			out = fmt.Sprintf("panic: %v", r)
		}
	}()
	rec := httptest.NewRecorder()
	e.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, path, nil))
	return fmt.Sprintf("%d %s", rec.Code, strings.TrimSpace(rec.Body.String()))
}

func main() {
	handler := func(c *echo.Context) error {
		return c.String(http.StatusOK, "route "+c.RouteInfo().Path+" id="+c.Param("id"))
	}
	for _, routes := range [][]string{
		{`/name\:verb/x`},
		{`/name\:verb/x`, `/name:id`},
		{`/name:id`, `/name\:verb/x`},
	} {
		e := echo.New()
		for _, p := range routes {
			e.GET(p, handler)
		}
		fmt.Printf("routes %s\n", routes)
		for _, path := range []string{"/name:verb/x", "/name1"} {
			fmt.Printf("  GET %-13s -> %s\n", path, get(e, path))
		}
	}
}

Output:

routes [/name\:verb/x]
  GET /name:verb/x  -> 200 route /name\:verb/x id=
  GET /name1        -> 404 {"message":"Not Found"}
routes [/name\:verb/x /name:id]
  GET /name:verb/x  -> panic: runtime error: index out of range [-1]
  GET /name1        -> 404 {"message":"Not Found"}
routes [/name:id /name\:verb/x]
  GET /name:verb/x  -> 404 {"message":"Not Found"}
  GET /name1        -> 200 route /name:id id=1

The recover in get is only there to keep the program going: without it the panic propagates
out of e.ServeHTTP, and with a real server the client gets a closed connection instead of a
response. I expected both routes to be served in either order of registration, as each is when
registered alone: GET /name:verb/x by /name\:verb/x and GET /name1 by /name:id with
id=1.

Version/commit

echo v5.3.1 and current master (3d084be), Go 1.27.1.

BTW, this was found by an automated program that writes property-based tests for various open source projects using hegel (but it has been reviewed by hand before reporting). We've also potentially found (but not yet hand validated) 12 other bugs in echo. You can see the tests at https://github.com/hegeldev/hegel-zoo/tree/main/targets/go/echo. Let us know if you would like us to file the other bugs found and/or contribute the tests. NB the tests are currently LLM generated and probably not yet suitable for inclusion as is, but we're happy to help get them into a better state if you want them.

[sosuke-t]

2026年9月22日(火) 19:28 David R. MacIver ***@***.***>:

…

*DRMacIver* created an issue (labstack/echo#3111) <#3111> Issue Description Registering a route with an escaped colon (/name\:verb/x) together with a route that has a parameter at the same position (/name:id) makes one of them unreachable, depending on the order: registered in that order, GET /name:verb/x panics inside ServeHTTP with index out of range [-1] and GET /name1 is a 404; registered the other way round, GET /name:verb/x is a 404. Each route on its own is served as expected. Working code to debug package main import ( "fmt" "net/http" "net/http/httptest" "strings" "github.com/labstack/echo/v5" ) func get(e *echo.Echo, path string) (out string) { defer func() { if r := recover(); r != nil { out = fmt.Sprintf("panic: %v", r) } }() rec := httptest.NewRecorder() e.ServeHTTP(rec, httptest.NewRequest(http.MethodGet, path, nil)) return fmt.Sprintf("%d %s", rec.Code, strings.TrimSpace(rec.Body.String())) } func main() { handler := func(c *echo.Context) error { return c.String(http.StatusOK, "route "+c.RouteInfo().Path+" id="+c.Param("id")) } for _, routes := range [][]string{ {`/name\:verb/x`}, {`/name\:verb/x`, `/name:id`}, {`/name:id`, `/name\:verb/x`}, } { e := echo.New() for _, p := range routes { e.GET(p, handler) } fmt.Printf("routes %s\n", routes) for _, path := range []string{"/name:verb/x", "/name1"} { fmt.Printf(" GET %-13s -> %s\n", path, get(e, path)) } } } Output: routes [/name\:verb/x] GET /name:verb/x -> 200 route /name\:verb/x id= GET /name1 -> 404 {"message":"Not Found"} routes [/name\:verb/x /name:id] GET /name:verb/x -> panic: runtime error: index out of range [-1] GET /name1 -> 404 {"message":"Not Found"} routes [/name:id /name\:verb/x] GET /name:verb/x -> 404 {"message":"Not Found"} GET /name1 -> 200 route /name:id id=1 The recover in get is only there to keep the program going: without it the panic propagates out of e.ServeHTTP, and with a real server the client gets a closed connection instead of a response. I expected both routes to be served in either order of registration, as each is when registered alone: GET /name:verb/x by /name\:verb/x and GET /name1 by /name:id with id=1. Version/commit echo v5.3.1 and current master (3d084be <3d084be>), Go 1.27.1. BTW, this was found by an automated program that writes property-based tests for various open source projects using hegel <https://github.com/hegeldev/hegel-go> (but it has been reviewed by hand before reporting). We've also potentially found (but not yet hand validated) 12 other bugs in echo. You can see the tests at https://github.com/hegeldev/hegel-zoo/tree/main/targets/go/echo. Let us know if you would like us to file the other bugs found and/or contribute the tests. NB the tests are currently LLM generated and probably not yet suitable for inclusion as is, but we're happy to help get them into a better state if you want them. — Reply to this email directly, view it on GitHub <#3111?email_source=notifications&email_token=A5GBKBE3XVWDIQXOPYAQOYL5QJH6DA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJVGM4DEOBVGI4TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5GBKBBJEAU22JJUDPT6IG35QJH6DAVCNFSNUABEKJSXA33TNF2G64TZHMZTCNJQGQ2DSMJ3JFZXG5LFHM2TKMZYGI4DKMRZGCQXMAQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>