CVE-2026-31954
CSRF Vulnerability in Emlog 2.6.6 Delete_Async Action
Publication date: 2026-03-11
Last updated on: 2026-03-17
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| emlog | emlog | to 2.6.6 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-352 | The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-31954 is a vulnerability in the emlog PHP package version 2.6.6 and earlier, specifically in the asynchronous media file deletion feature. The asynchronous delete action (delete_async) does not perform a check for a CSRF (Cross-Site Request Forgery) token, which means it lacks protection against CSRF attacks.'}, {'type': 'paragraph', 'content': "This flaw allows an attacker to craft a malicious webpage that sends unauthorized POST requests to delete media files without the authenticated user's consent. When an admin user visits this malicious page, the attacker can delete media files asynchronously without proper authorization checks."}] [1]
How can this vulnerability impact me? :
The vulnerability allows an attacker to delete media files on an emlog website without proper authorization if an authenticated admin visits a malicious webpage. This can lead to unauthorized deletion of media content.
However, the CVSS v3.1 base score is 0.0, indicating that the vulnerability does not impact confidentiality, integrity, or availability directly, and requires low privileges and no user interaction.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unauthorized POST requests to the endpoint `/admin/media.php?action=delete_async` that delete media files without proper CSRF token validation.'}, {'type': 'paragraph', 'content': 'One way to detect exploitation attempts is to look for POST requests to this URL with the parameter `aid` (media ID) being sent without a valid CSRF token.'}, {'type': 'paragraph', 'content': 'Suggested commands to detect such activity include using web server logs or network monitoring tools to filter for these requests.'}, {'type': 'list_item', 'content': 'Using grep on web server access logs to find suspicious POST requests: `grep "POST /admin/media.php?action=delete_async" /var/log/apache2/access.log`'}, {'type': 'list_item', 'content': "Using tcpdump or similar to capture HTTP POST requests to the vulnerable endpoint: `tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep 'POST /admin/media.php?action=delete_async'`"}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to ensure that the asynchronous delete action (`delete_async`) in `emlog/admin/media.php` includes CSRF token validation by calling `LoginAuth::checkToken()`.
Since no patched versions are available at the time of the advisory, you should manually apply the recommended fix by modifying the code as follows:
- Add `LoginAuth::checkToken();` at the beginning of the `delete_async` action handler to enforce CSRF protection.
Additionally, restrict access to the `/admin/media.php` endpoint to trusted users and consider monitoring for suspicious POST requests as a temporary measure.