Imagine a stranger walking into your office, sitting down at your desk, and reading every contract, budget, and client file you've ever created — and you'd have no idea it was happening.

Who Is at Risk — and Why It Matters Right Now

Construction firms are not the first industry that comes to mind when people think about cybersecurity disasters. But they should be. The construction sector manages some of the most sensitive data in existence: multi-million dollar bids, subcontractor agreements, property records, client payment details, and government infrastructure plans. A breach in any of these systems doesn't just hurt a company's bottom line — it can expose municipal contracts, delay public projects, and hand competitors a roadmap to underbid on future work.

The affected software, itsourcecode Construction Management System version 1.0, is a web-based project management platform used by small-to-medium construction businesses to track projects, manage documents, and handle operational workflows. The platform is cross-platform, meaning it runs on Windows, Linux, and macOS server environments alike — no single operating system is safe. Security researchers have confirmed that a proof-of-concept exploit for this vulnerability has already been made publicly available, meaning the barrier for an attacker is now essentially zero. You don't need to be a sophisticated hacker. You need a browser and a search engine.

"The exploit has been disclosed to the public and may be used." — Official CVE Advisory

What Can an Attacker Actually Do? (Plain English Version)

Think of the software's database as a filing cabinet and the web application as the front-desk receptionist. Normally, when you ask the receptionist for a file, they check your ID, find the right folder, and hand it to you. This vulnerability is the equivalent of discovering that if you phrase your request in a very specific, strange way, the receptionist completely bypasses all the ID checks and hands you the entire filing cabinet — and then lets you rearrange or delete everything inside it.

The attack enters through a file called execute1.php, which is accessible over the internet without any login. An attacker crafts a malicious web request that smuggles hidden database commands inside what looks like normal traffic. The server, unable to tell the difference between a real user and an attacker, obediently executes those commands. From there, the attacker can read every record in the database — usernames, hashed passwords, client data, financial records — or in more dangerous configurations, begin executing commands directly on the server itself, turning a data breach into a full system takeover.

What makes this especially dangerous is the unauthenticated nature of the attack. There is no lock on the door to pick. The attacker does not need to steal credentials first, or trick an employee into clicking a link, or wait for someone to make a mistake. They find the server, send the malicious request, and they're in. The entire attack can be automated and scaled to target every exposed instance of this software simultaneously.

The Technical Detail Security Researchers Need to Know

The CVSS score of 7.3 HIGH is not the ceiling here — security teams should treat this as closer to critical given that a public exploit exists, no authentication is needed, and the attack surface is any internet-connected deployment. In penetration testing contexts, this vulnerability class — unauthenticated SQL injection on a publicly reachable endpoint — is considered one of the most straightforward paths to full database compromise and, depending on database configuration, operating system command execution via functions like xp_cmdshell (MSSQL) or INTO OUTFILE (MySQL).

How Was This Found? Has Anyone Been Hit Yet?

The vulnerability was discovered and responsibly disclosed by independent security researchers who identified the flaw through source code analysis and manual testing of the application's input handling. The findings were reported through standard CVE channels and assigned the identifier CVE-2026-7074.

As of publication, no active exploitation campaigns have been confirmed in the wild. There are no known ransomware groups or threat actors who have publicly claimed attacks leveraging this specific CVE. However, that window is closing fast. Security history is unambiguous on this point: once a proof-of-concept exploit for a web application vulnerability goes public, automated scanners operated by opportunistic attackers typically begin probing for vulnerable installations within 24 to 72 hours. This is not speculation — it is the documented pattern for vulnerabilities of this class, from early-era phpMyAdmin flaws to more recent attacks on unpatched content management systems.

The fact that this is a publicly available, open-source-adjacent application — commonly deployed by businesses without dedicated IT security staff — makes it an attractive target. Attackers don't always go after the biggest fish. They go after the easiest ones.

What You Should Do Right Now: 3 Specific Steps

1. Identify and isolate every instance of itsourcecode Construction Management System 1.0 immediately.
   Search your infrastructure for any deployment of this application. If your version number is 1.0, assume it is vulnerable. If the application is internet-facing (accessible from outside your company network), take it offline or place it behind a VPN or IP allowlist as an emergency measure until a patch is available or the software is replaced. Do not wait for vendor confirmation before restricting access.
2. Audit your logs for signs of malicious SQL injection attempts against /execute1.php.
   Search your web server access logs (Apache: access.log, Nginx: access.log) for any requests to /execute1.php that contain SQL keywords such as UNION, SELECT, --, OR 1=1, or unusual encoding patterns like %27 (URL-encoded single quote). If you find anomalous requests, treat your database as potentially compromised and begin incident response procedures, including credential rotation for all accounts stored in the database.
3. If you must keep the application running, deploy a Web Application Firewall (WAF) rule targeting SQL injection on the code parameter immediately.
   Solutions like ModSecurity with the OWASP Core Rule Set (CRS version 3.3.5 or later), Cloudflare WAF, or AWS WAF can be configured to block SQL injection patterns in transit. This is a temporary mitigation only — WAF rules can be bypassed by determined attackers and are not a substitute for patching the underlying code with parameterized queries. Contact the software vendor for an emergency patch and escalate if one is not provided on an urgent timeline.