CVE-2026-79661 in Ech0
Summary
by MITRE • 08/25/2026
Ech0 through 4.5.6 registers the PUT /api/echo/like/:id endpoint on the public router group without authentication or rate limiting. Unauthenticated attackers can increment the fav_count counter of any echo (including private echoes) by supplying its UUID, which can be harvested from the public GET /api/echo/page feed. Repeated requests are accepted without deduplication, each triggering a database write and a four-key cache invalidation, allowing attackers to inflate popularity metrics and amplify load on the database and cache. Fixed in 4.7.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified involves an authentication bypass and lack of rate limiting within the Ech0 application versions through 4.5.6, specifically affecting the PUT /api/echo/like/:id endpoint which is registered on a public router group. This architectural misconfiguration allows unauthenticated actors to interact with functionality that should be restricted to verified users or limited by usage policies. The core technical flaw lies in the absence of access control checks and input validation mechanisms for this specific API route, enabling any external entity to send HTTP PUT requests containing a target echo UUID without providing valid session tokens or credentials. This design oversight effectively exposes internal state modification capabilities to the public internet, violating fundamental principles of secure application development regarding privilege management and resource protection.
The operational impact is twofold, encompassing both data integrity issues and denial-of-service potential. Attackers can harvest valid echo identifiers from the publicly accessible GET /api/echo/page feed endpoint, which serves as a discovery mechanism for target selection. By supplying these UUIDs in subsequent PUT requests to the like endpoint, adversaries can artificially inflate the fav_count counter associated with any echo entry, including those marked as private or restricted. This manipulation compromises the integrity of popularity metrics and user engagement statistics, potentially influencing social proof mechanisms within the application. Furthermore, because each request triggers a database write operation along with four cache invalidation events, there is no deduplication logic to prevent repeated submissions from the same source for the same target. Consequently, an attacker can execute rapid-fire requests to generate significant backend load, leading to resource exhaustion and potential service degradation or denial of service conditions due to excessive I/O operations and memory pressure on the caching layer.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to adequately verify identity before granting access to sensitive functionality. It also relates to CWE-354 Improper Validation of Integrity for Critical Data, since the popularity metrics are altered without proper authorization checks ensuring data consistency and trustworthiness. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving resource hijacking or impact through denial of service via application layer exhaustion, specifically leveraging API abuse patterns that exploit missing rate limiting controls often categorized under T1496 Resource Hijacking or related availability attack vectors. The lack of deduplication further exacerbates the risk by allowing volumetric attacks to scale linearly with request volume rather than being capped by logical constraints.
Mitigation strategies must address both the immediate exposure and the underlying architectural weaknesses. The primary fix, as implemented in version 4.7.3, involves restricting access to the like endpoint by enforcing authentication requirements so that only authenticated users can increment counters. Additionally, rate limiting policies should be applied at the API gateway or application level to throttle requests per user IP address or session identifier, preventing rapid-fire abuse even if other controls fail. Implementing idempotency checks on the backend would also prevent duplicate counts from being processed for identical actions within a reasonable time window, thereby reducing unnecessary database writes and cache invalidations. Regular security audits of public-facing endpoints are recommended to ensure that no critical state-changing operations remain exposed without proper authorization guards or throttling mechanisms in place.