On June 9, 2023 — barely a week after disclosing CVE-2023-34362 and while organizations were still scrambling to patch and assess the Cl0p campaign's damage — Progress Software disclosed a second critical SQL injection vulnerability in MOVEit Transfer. Then a third. The security community's confidence in MOVEit's codebase collapsed.
The Timeline of Discoveries
CVE-2023-34362 (May 31, 2023)
The original SQL injection vulnerability exploited by Cl0p. CVSS 9.8. Actively exploited since at least May 27.
CVE-2023-35036 (June 9, 2023)
A new SQL injection vulnerability discovered during Progress Software's code review following the first CVE. This wasn't found by an external researcher — Progress found it while auditing their own code in response to the first vulnerability.
This second vulnerability was similar in nature to the first: a SQL injection that could allow unauthorized access to the MOVEit Transfer database. It was in a different code path but reflected the same underlying issue — insufficient input validation in the application's SQL handling.
CVE-2023-35708 (June 15, 2023)
A third SQL injection vulnerability. Again discovered during the ongoing code review. Again, a similar class of vulnerability in a different code path.
What Three Similar Vulnerabilities Tell Us
Finding three SQL injection vulnerabilities in the same product within three weeks isn't just bad luck. It indicates systemic issues:
Insufficient Input Validation
SQL injection has been a well-understood vulnerability class for over two decades. The fact that multiple SQL injection paths existed in a current, actively maintained product suggests that input validation wasn't applied consistently across the codebase.
Missing Security Testing
Automated tools (SAST/DAST) reliably detect SQL injection in most cases. The presence of multiple SQL injection vulnerabilities suggests that either:
- Security testing wasn't part of the development process
- Security testing tools weren't configured correctly
- Security testing findings weren't remediated
Code Review Gaps
SQL injection in a web application should be caught during code review. Multiple instances suggest that either code review wasn't happening, wasn't focused on security, or was insufficiently rigorous.
Architectural Issues
When SQL injection appears repeatedly in a codebase, it often points to an architectural problem — the application doesn't use parameterized queries consistently, or there's no data access layer that enforces safe query construction. Individual developers building SQL strings manually, repeatedly, is an architectural failure.
The Cascading Impact
The second and third vulnerabilities compounded the already massive impact of the first:
Patch Fatigue
Organizations that had just completed an emergency patching cycle for CVE-2023-34362 now needed to do it again. And again. Each patch required:
- Downloading the new version
- Testing in a staging environment
- Scheduling a maintenance window
- Deploying and verifying
Some organizations completed three patching cycles in three weeks — an enormous operational burden.
Trust Erosion
Each additional vulnerability eroded trust in the MOVEit product. If three SQL injections were found in three weeks, how many more existed? Organizations started questioning whether MOVEit Transfer should remain in their infrastructure at all.
Extended Exposure Windows
Organizations that were still deploying the first patch when the second was released faced difficult decisions. Patch the first vuln now and the second later? Wait for a cumulative patch? Take MOVEit offline entirely?
Insurance and Legal Implications
Each new vulnerability potentially expanded the scope of data exposure, complicating insurance claims and legal proceedings already underway from the first breach.
The Broader Product Security Question
The MOVEit vulnerability cluster raised uncomfortable questions about the security of managed file transfer products as a category:
MFT Products Handle the Most Sensitive Data
Organizations use MFT specifically for data that's too sensitive for other transfer methods. Personal health information, financial records, government documents, intellectual property — all flow through MFT systems.
MFT Products Are Internet-Facing by Design
Unlike internal applications that sit behind firewalls and VPNs, MFT products are designed to be accessible from the internet. They need to receive files from external partners. This internet exposure makes every vulnerability directly exploitable.
MFT Product Security Varies Widely
The MOVEit incident prompted security researchers to examine other MFT products. Vulnerabilities were subsequently found in other MFT solutions, suggesting the entire product category may need more rigorous security scrutiny.
Lessons for Software Buyers
Demand Security Evidence
Before purchasing any software that will be internet-facing and handle sensitive data, demand evidence of security practices:
- Has the vendor had a third-party security audit?
- Do they have a bug bounty program?
- What's their vulnerability response track record?
- Do they provide SBOMs?
Have a Rapid Response Plan
When a vendor discloses a critical vulnerability, you need to patch within hours, not days or weeks. This requires:
- A tested patching process
- Staging environments ready for testing
- Maintenance window policies that accommodate emergencies
- Communication templates for stakeholders
Evaluate Alternatives
Don't become dependent on a single product for critical data transfers. Evaluate whether the data needs of your organization can be met through alternative architectures — perhaps cloud-native solutions with different security models.
Monitor Beyond Your Perimeter
Many organizations affected by MOVEit weren't running it themselves — they were affected through vendors. Monitor your vendor ecosystem for incidents that could affect you.
The Vendor's Responsibility
Progress Software's response was mixed:
Positive: They proactively audited their codebase after the first vulnerability and disclosed additional findings transparently.
Concerning: The fact that multiple SQL injection vulnerabilities existed in a product designed for handling sensitive data raises fundamental questions about their SDL (Security Development Lifecycle) practices.
The incident demonstrates that a vendor's security incident response — while important — is secondary to prevention. No amount of good incident response undoes the damage of a breach caused by preventable vulnerabilities.
How Safeguard.sh Helps
Safeguard.sh provides the supply chain visibility to manage situations like the MOVEit cascade:
- Rapid Vulnerability Identification: When multiple CVEs are disclosed for a single product, Safeguard.sh immediately identifies all instances in your environment and your vendor ecosystem.
- Patch Status Tracking: Safeguard.sh tracks your remediation progress across all affected instances, ensuring nothing is missed during rapid-fire patching cycles.
- Vendor Risk Scoring: Safeguard.sh evaluates vendors based on their vulnerability history and response practices, helping you make informed decisions about vendor risk.
- Alternative Assessment: Safeguard.sh's supply chain visibility helps you evaluate the security posture of alternative products, supporting informed decisions about migration.
The MOVEit vulnerability cascade was a worst-case scenario for software buyers: a critical product with multiple critical vulnerabilities discovered in rapid succession while under active exploitation. The organizations that weathered it best were those with clear asset inventories, tested patch processes, and supply chain visibility. Those are exactly the capabilities that need to be in place before the next incident.