CVE-2026-7118
SQL Injection in Employee Management System 1.0 Enables Remote Exploit
Publication date: 2026-04-27
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| code-projects | employee_management_system | 1.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-74 | The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component. |
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-7118 is a time-based blind SQL Injection vulnerability found in the Employee Management System 1.0, specifically in the file 370project/cancel.php.
The vulnerability arises because user-controlled parameters, namely 'id' and 'token', are directly concatenated into an SQL UPDATE statement without proper sanitization or parameterization.
This allows an attacker to inject malicious SQL code into the 'id' parameter, manipulating the database query executed by the system.
For example, an attacker can send a specially crafted GET request that causes the database to execute a time delay, confirming the injection and potentially allowing unauthorized actions.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized manipulation of employee leave request statuses and potential inference of database behavior or data through SQL injection. Such unauthorized access and manipulation of data can lead to violations of data protection regulations like GDPR and HIPAA, which mandate the protection of personal and sensitive information from unauthorized access and alteration.
Specifically, the ability to alter leave request statuses without permission and infer database contents could compromise data integrity and confidentiality, key requirements under these regulations.
How can this vulnerability impact me? :
This vulnerability can have several impacts on the affected system and its users.
- Unauthorized manipulation of leave-request statuses, such as cancelling leave requests without permission.
- Inference of database behavior or extraction of sensitive data through blind SQL injection techniques.
- Degradation of system availability by triggering time delays or expensive database operations, potentially leading to denial of service.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by sending specially crafted HTTP GET requests to the vulnerable endpoint and observing the response time for signs of SQL injection.
A common detection method is to inject a time-delay SQL payload into the `id` parameter and check if the server response is delayed accordingly.
For example, you can use the following curl command to test the vulnerability:
- curl -i "http://<target>/cancel.php?id=(select*from(select+sleep(10)union/**/select+1)a)&token=307"
If the response time increases by approximately 10 seconds compared to a baseline request without the payload, it confirms the presence of the SQL injection vulnerability.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include sanitizing and parameterizing user inputs to prevent SQL injection.
Specifically, the vulnerable code should be changed to use prepared statements or parameterized queries instead of directly concatenating user inputs into SQL statements.
Additionally, applying web application firewall (WAF) rules to block suspicious SQL injection patterns and restricting access to the vulnerable endpoint can help reduce risk.
If possible, update or patch the Employee Management System to a version where this vulnerability is fixed.