GHSA-PJ6Q-4VQ4-R8CG: Unauthenticated Resource Exhaustion and State Manipulation in Ech0 API

The lin-snow/Ech0 project is an open-source, lightweight publishing platform written in Go. The application relies on caching mechanisms to optimize content delivery and mitigate the performance penalties associated with disk-backed database queries. The system exposes an API endpoint, PUT /api/echo/like/:id, designed to increment the favorite count metric associated with individual posts.

This specific endpoint functions without any authentication verification, operating natively within the application's unauthenticated routing group. It also entirely lacks authorization boundaries, rate limiting constraints, and idempotency checks in the vulnerable versions. Consequently, the application blindly processes any incoming request that contains a properly formatted request payload and a valid post UUID.

The absence of basic input throttling allows an external entity to submit an unlimited sequence of modification requests. Each processed request successfully increments the internal metric counter. More critically, the system design tightly couples this metric modification with expensive backend operations.

Every time the like counter increments, the application opens a database transaction to record the new integer value. Immediately following this database write, the handler systematically purges four separate application cache layers to ensure consistency. This architectural pattern transforms a simple state manipulation flaw into a highly effective vector for application-layer resource exhaustion.

The primary vulnerability class is Missing Authentication for Critical Function (CWE-306), compounded by systemic Resource Exhaustion (CWE-400) mechanics. The developer explicitly placed the target route into a public router group, intentionally bypassing the standard authentication middleware used elsewhere in the application. This decision relies on the assumption that metric increments are low-risk operations.

The secondary root cause lies in the application's data management architecture. When the LikeEcho() handler processes a request, it performs a synchronous SQLite UPDATE query. SQLite uses file-level locking during write operations. Under high concurrency, frequent write requests force database lock contention, rapidly saturating disk I/O capabilities and creating a hard bottleneck for the entire application.

Following the database commit, the handler immediately invalidates the Page Cache, Today Cache, RSS Cache, and Echo Cache. The application leverages these cache layers to serve standard read requests without querying the database. By constantly dropping these caches, the handler ensures the application operates in a perpetual state of cache-miss.

This behavior guarantees a cache stampede effect. Subsequent legitimate requests arriving during an attack must synchronously rebuild the rendering logic, aggregation metrics, and internal data models. The combination of SQLite lock contention and CPU-intensive cache reconstruction completely exhausts available server resources.

The vulnerability stems from the specific route registration implementation located within internal/router/echo.go. The application initializes a PublicRouterGroup specifically intended for unauthenticated, read-only content delivery. The developer attached the modifying PUT request directly to this group.

// Vulnerable Implementation
appRouterGroup.PublicRouterGroup.PUT("/echo/like/:id", h.EchoHandler.LikeEcho())

This implementation executes the LikeEcho() handler immediately upon matching the route path. No intermediate middleware intervenes to assess the frequency of requests originating from the client IP, nor does any logic evaluate whether the specified client has previously interacted with the target UUID.

The maintainer addressed this flaw in commit cecc2c19b590df85d79ea98457faa143130cd620 by introducing a custom RateLimitWithIdempotency middleware. This function resides in internal/middleware/ratelimit.go and wraps the vulnerable handler before it attaches to the router block.

// Patched Implementation
appRouterGroup.PublicRouterGroup.PUT(
    "/echo/like/:id",
    middleware.RateLimitWithIdempotency(2, 5, time.Hour, "id", func(c *gin.Context) {
        c.JSON(http.StatusOK, commonModel.OK[any](nil, commonModel.LIKE_ECHO_SUCCESS))
    }),
    h.EchoHandler.LikeEcho(),
)

This patched implementation enforces strict rules before yielding execution to the handler. It applies a token-bucket rate limit restricting clients to two requests per second with a maximum burst capacity of five. Additionally, it implements a one-hour idempotency window keyed to a composite of the client IP and the requested UUID, returning a silent success response if duplicate requests occur.

Exploitation requires minimal prerequisites. An attacker only needs network access to the exposed Ech0 API and the UUID of a target post. The post UUID is deterministic and routinely exposed via standard content URLs or API enumeration. No authenticated session tokens or specialized privileges are necessary.

The attack methodology centers on generating asynchronous HTTP PUT requests targeting the vulnerable endpoint. By looping these requests continuously, the attacker saturates the application's connection queue. The application attempts to process each request sequentially, unaware that the data state is being artificially inflated.

The following bash script demonstrates a basic exploitation sequence using standard command-line tools. This loops a curl request 1,000 times against a specific UUID.

# Exploitation payload generating rapid database write contention
for i in {1..1000}; do
  curl -X PUT "https://<ech0-instance>/api/echo/like/<target-uuid>"
done

Upon execution, this simple loop forces the target server to execute 1,000 localized SQLite write locks. It additionally triggers 4,000 independent cache invalidation events (1,000 requests multiplied by four specific cache layers). The resulting I/O wait times induce severe latency across all standard platform operations, effectively achieving an application-layer Denial of Service.

Security analysis of commit cecc2c19b590df85d79ea98457faa143130cd620 reveals several architectural limitations in the deployed patch. The RateLimitWithIdempotency middleware derives its primary defensive context from the origin client IP address. This design relies on an assumption that individual clients operate from static, uniquely identifiable network locations.

Attackers utilizing distributed botnets or automated IP-rotation services easily bypass this control. Because a proxy pool presents a distinct origin IP for subsequent requests, the server allocates a new token bucket and instantiates a new deduplication state for each incoming connection. This negates the one-hour idempotency window entirely.

Furthermore, the application stores the idempotency state within local instance memory. In horizontally scaled deployment environments involving multiple Ech0 nodes behind a load balancer, the state does not synchronize across the cluster. An attacker cycling requests across different cluster nodes circumvents the local memory deduplication constraints.

Finally, the core privacy bypass mechanism remains unresolved. The endpoint still resides inside the PublicRouterGroup. If an attacker obtains the hidden UUID of an unpublished or private post, they can successfully increment its metrics. The patch addresses the Denial of Service volume but fails to enforce proper authorization constraints on private content interactions.

Administrators operating Ech0 instances must ensure they deploy a version incorporating commit cecc2c19b590df85d79ea98457faa143130cd620 or newer. This commit integrates the RateLimitWithIdempotency middleware, which fundamentally disrupts single-source brute-force attacks and limits trivial cache exhaustion loops. Verifying the routing configuration in internal/router/echo.go confirms the presence of this mitigation.

To address the persistent threat of distributed IP-rotation attacks, organizations must implement robust external rate limiting. Deploying a Web Application Firewall (WAF) or configuring edge reverse proxies (such as Nginx or HAProxy) provides necessary defense-in-depth. These tools can enforce global request thresholds for the /api/echo/like/* URI space, irrespective of individual client IP derivations.

Production environments experiencing high concurrent traffic should evaluate migrating from the default SQLite data store to PostgreSQL or MySQL. Relational database systems utilizing row-level locking handle concurrent write-heavy attacks significantly better than SQLite's file-locking mechanism, reducing the severity of database contention during an attack.

Developers maintaining the Ech0 codebase should decouple the cache invalidation logic from synchronous API request handling. Implementing an asynchronous message queue or an event-driven architecture ensures that rapid database updates do not force immediate, blocking cache purges. Additionally, implementing strict authorization checks on the endpoint to verify read access to private UUIDs resolves the outstanding privacy violation.