CVE-2026-66751 in lets-chatinfo

Summary

by MITRE • 07/28/2026

Let's Chat 0.3.0 through 0.4.8 contains an improper authorization vulnerability that allows any authenticated user to archive any room on the server by sending a DELETE request to the rooms handler without ownership verification. Attackers can enumerate room IDs via the rooms listing endpoint and permanently archive private or password-protected rooms they cannot access, with no application-level recovery path requiring direct database intervention to restore.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 07/28/2026

This vulnerability exists within the Let's Chat messaging platform version 0.3.0 through 0.4.8 where the authorization mechanism fails to properly validate user permissions before allowing room archival operations. The flaw resides in the rooms handler component which accepts DELETE requests without verifying whether the authenticated user possesses sufficient privileges to archive the targeted room. This represents a classic improper authorization vulnerability classified as CWE-285, where the application fails to correctly enforce access controls for privileged operations.

The technical implementation allows any authenticated user to exploit this weakness by first enumerating available room IDs through the public rooms listing endpoint, which does not restrict access based on user permissions or room visibility settings. Once a target room ID is identified, the attacker can construct a DELETE request directly to the rooms handler endpoint with the appropriate room identifier. The vulnerability stems from the absence of ownership verification logic that should validate whether the requesting user has administrative rights or ownership over the specific room they attempt to archive.

The operational impact of this vulnerability extends beyond simple data manipulation as it enables attackers to permanently remove private and password-protected rooms from the system without any application-level recovery mechanism. This creates a persistent data loss condition where archived rooms cannot be restored through normal application interfaces, forcing administrators to perform direct database interventions to recover the affected resources. The attack vector aligns with ATT&CK technique T1485 which covers data manipulation and data destruction activities through unauthorized access to system resources.

The severity of this vulnerability increases significantly when considering that authenticated users typically have limited privileges within collaborative environments, yet this flaw allows them to perform destructive operations on rooms they should not be able to modify. The lack of recovery paths means that even if a room was accidentally archived, administrators must manually intervene in the database layer to restore it, creating operational overhead and potential service disruption. This vulnerability particularly affects organizations relying on Let's Chat for secure communication channels where private rooms contain sensitive information that should remain accessible only to authorized participants.

Recommended mitigations include implementing proper ownership verification checks before allowing room archival operations, enforcing access control lists that validate user permissions against specific room resources, and establishing audit logging of all room archival activities. The fix should ensure that users can only archive rooms they own or have explicit administrative privileges for, while also providing application-level recovery mechanisms to restore accidentally archived rooms without requiring database-level intervention. Additionally, implementing rate limiting on room enumeration endpoints could help reduce the attack surface by making it more difficult for attackers to discover valid room identifiers through automated enumeration techniques.

This vulnerability demonstrates the critical importance of proper access control implementation in collaborative platforms where users may have varying levels of permission within shared environments. The weakness exposes fundamental flaws in the application's authorization model and highlights the need for comprehensive security testing that validates privilege boundaries and access control enforcement mechanisms. Organizations using affected versions should immediately implement patches or workarounds to prevent unauthorized room archival operations while considering the broader implications for data integrity and recovery procedures within their messaging infrastructure.

Responsible

VulnCheck

Reservation

07/27/2026

Disclosure

07/28/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!