CVE-2024-1817 is a high severity (CVSS 7.3) improper authentication flaw in the Demososo DM Enterprise Website Building System, up to version 2022.8. A value in a cookie decides whether a visitor is treated as an administrator. The vendor did not respond, so retire the product or lock it down.
What's affected
Demososo DM Enterprise Website Building System, up to and including 2022.8. The record lists no fixed version.
The description places the flaw in the function dmlogin of the file indexDM_load.php, in the cookie handler component. The weakness is CWE-287, improper authentication. In plain terms, the application lets a client supplied cookie value, named is_admin, influence whether the login check passes. A server must never take a client's word for who the client is.
The description says the attack can be launched remotely, that the exploit has been disclosed publicly, and that the vendor was contacted early but did not respond in any way.
Severity conflict. The description text calls the issue critical. NVD's CVSS 3.1 score is 7.3, which is High, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. Both ratings are published.
How to check if you're exposed
This product has no package manager entry, so check your own deployment. Find the install and the file named in the record:
find / -type f -name "indexDM_load.php" 2>/dev/null
If the file exists, you run an affected product, as long as the version is 2022.8 or earlier. Look at the admin panel footer or the product documentation for the version.
Then check access logs. Requests to the admin area that arrive without a normal login sequence beforehand, or from addresses outside your staff, deserve a closer look. Compare admin actions in the site's own history against what your editors actually did.
What to do now
- Confirm whether you run the product and which version.
- Check the vendor site for a release newer than 2022.8. The record says the vendor never replied, so a fix may not exist.
- Restrict the administrative area to a VPN or allowlisted addresses at the web server or firewall, so the cookie check is not the only barrier.
- Review recent admin actions and accounts for anything unexpected, and rotate admin passwords.
- Plan a migration to a supported site platform if no patch arrives.
Why it matters
Authentication has to be decided on the server, from data the server controls, such as a session record it created after verifying a password. Treating a cookie that the browser sends as proof of administrator status breaks that rule, because the client can set cookie values to anything.
The impact ratings are low in the vector, which explains why NVD lands at 7.3 and not higher. For a website builder, though, an admin session is a strong position. An admin can change content, which can mean planting malicious scripts on pages that your visitors load.
The record's Known Exploited Vulnerabilities flag is false. The exploit is described as public.
Quick check
Is there a fix?
The record names none and says the vendor did not respond. Check the vendor site, and if nothing exists, move off the product.
Does an attacker need a password?
The vector lists no privilege requirement, and the weakness is about the login check trusting a cookie value.
Sources
- NVD record for CVE-2024-1817
- VulDB entry 254605 (listed in the record, not retrievable when reviewed)
- Write-up listed in the record (not retrievable when reviewed)
Last reviewed: 19 October 2026.
