CVE-2026-21430 is a critical flaw (CVSS 9.3) in Emlog 2.5.23 where article creation lacks CSRF protection, and a stored cross-site scripting issue lets that chain end in account takeover. The advisory lists no patched version, so reduce admin exposure and watch the project.
What's affected
The record and the GitHub advisory name Emlog version 2.5.23 and state that no patched version is available. The weaknesses are CWE-352 (cross-site request forgery) and CWE-79 (cross-site scripting). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N, which needs a user to take an action, such as visiting a page, and changes scope.
The advisory rates the issue High, and the NVD score is higher at 9.3 critical. Both agree that no fix is available at the time of the advisory, published on 2 January 2026. Check the Emlog repository for later releases. The record does not mark the issue as exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
Find your Emlog version in the admin area or from the release you downloaded, and confirm whether it is 2.5.23.
find /var/www -type f -name "article_save.php" 2>/dev/null
Then check how admins reach the site. Do they log in from a browser they also use for general browsing? Check whether the admin area is open to the whole internet or restricted by address.
What to do now
- Restrict the Emlog admin area to a VPN or an address allowlist.
- Tell administrators to use a separate browser profile for admin work, and to log out when they are done. CSRF depends on an active session.
- Set session cookies to SameSite Lax or Strict if your server setup allows it.
- Add a content security policy that blocks inline scripts on the site, which limits what stored XSS can do.
- Watch the Emlog repository for a patched release and update when one appears. Review recently published articles for content you do not recognise.
Why it matters
CSRF means a site accepts a state changing request from a logged in user without checking that the user meant to send it. The usual defence is a token tied to the session that the attacker cannot guess. The advisory says some functions in Emlog do not use one.
Stored XSS means the application keeps attacker supplied content and later serves it as live script to other users. Each flaw alone is limited. Together they chain: the forged request creates the article, and the stored script then runs in the browser of whoever views it, including an administrator, which is how the record reaches account takeover.
Neither fix is hard in principle: add tokens to every state changing form and encode output. Until a release does so, controls around the admin area are the defence.
Quick check
Why is the score critical when a user must act?
Because the scope changes and the impact on confidentiality and integrity is high. The user action is one click on a page that the attacker controls, which is a low bar.
Sources
Last reviewed: 19 October 2026.
