CVE-2025-8220 is a high severity (CVSS 7.3) SQL injection in Engeman Web up to 12.0.0.2. It sits on the password recovery page and is reached through a cookie value. The record says version 12.0.0.3 fixes it, but the public write-up disagrees on which versions are affected.
What's affected
The record lists Engeman Web up to 12.0.0.2, with the flaw in /Login/RecoveryPass, the password recovery page. The manipulated input is the LanguageCombobox value sent as part of a cookie. The record says upgrading to 12.0.0.3 is sufficient to fix the issue.
The public proof of concept repository does not match that range. Its title says 12.0.0.2 and earlier, but its body says the issue was confirmed up to 12.0.0.1 and that a newer version is likely also vulnerable. It names no fixed version. So the two sources disagree about the top of the affected range, and I could not confirm 12.0.0.3 from the repository.
The record also says the vendor was contacted early and did not respond. Check the vendor's own channel for a release note on 12.0.0.3 before relying on that number.
On severity, the record scores the flaw 7.3 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. The write-up gives no score of its own. It describes high potential impact, including reading and changing database content, and notes that the injection is blind and that the database account is highly privileged.
How to check if you're exposed
Look up your installed Engeman Web version in the application's about or administration screen. Treat 12.0.0.2 and below as affected, and 12.0.0.3 as unconfirmed until the vendor says otherwise.
Next, check whether the login and recovery pages are reachable from the internet. From a machine outside your network, see whether the login page loads. If it does, the recovery page is probably reachable too.
Review your web server logs for requests to the recovery path with cookie values that look unusual, such as long strings or characters that do not belong in a language selector.
grep "/Login/RecoveryPass" /var/log/iis/u_ex*.log | tail -n 50
Adjust the command to your server. IIS logs do not record cookies by default, so you may need to enable cookie logging to see them.
What to do now
- Identify every Engeman Web instance and its exact version.
- Contact the vendor for the fixed build and confirm 12.0.0.3 or a later release.
- Put the application behind a VPN or an allowlist so the login and recovery pages are not open to the internet.
- Check that the database account used by the application has the least privilege it needs.
- Review logs and the database for unexpected reads or changes on tables behind the login.
Why it matters
The weakness is CWE-89 (SQL Injection), under CWE-74 (Injection). A cookie value is trusted and placed into a database query. Developers often treat cookies as harmless settings such as language choice, but a cookie is client input like any other and can be altered freely.
The page needs no login, which is the point of a recovery screen, so the usual barrier is missing. The record does not flag this CVE as CISA KEV, and it makes no claim of exploitation in the wild, though it does say the exploit has been disclosed to the public.
Quick check
Which Engeman Web version is safe?
The record says 12.0.0.3. The public write-up names no fixed version and says versions newer than 12.0.0.1 may also be affected, so confirm with the vendor.
Why would a language cookie matter?
Because any value the browser sends can be changed by the sender. If the server puts that value into a database query without binding it as a parameter, it becomes an injection point.
Sources
- CVE-2025-8220 on Safeguard Gold
- Public write-up repository
- NVD record for CVE-2025-8220, published 2025-07-27
Last reviewed: 18 October 2026.
