CVE-2016-20097 is a SQL injection in Weaver E-cology that chains to arbitrary file read — and the vulnerability is almost certainly still active in production environments right now, despite being 'patched' since 2016. Here's why you need to treat this as urgent: the vendor disclosed the fix without specifying which version resolved it, leaving defenders unable to answer whether they're exposed. That's not a documentation gap — it's an operational failure that has kept this CVE dangerous for seven years.
The compound nature of this vulnerability is what makes it severe. A standalone SQL injection exposes database content — bad, but contained. This one feeds the injection output into the application's file-handling logic, letting attackers read arbitrary files from the server. Database credentials, configuration files, internal architecture diagrams, SSH keys, API tokens — all reachable through this chain. That's not two vulnerabilities adding together; it's a blast radius amplifier, where the second failure multiplies the impact of the first. One exploitation path becomes a dozen lateral movement options.
Shadowserver observed active exploitation in October 2023. The seven-year gap between disclosure and detected attacks isn't evidence that attackers ignored this — it's evidence of tradecraft discipline. Targeted attackers who understand enterprise middleware don't mass-scan for SQL injection; they acquire access through supply chain knowledge, extract credentials quietly, and maintain persistence through channels that survive the original vulnerability's remediation. The 'patched' status doesn't invalidate stolen credentials or reconfigure shared infrastructure that was mapped during that window.
This pattern isn't an outlier. SQL injection-to-file-read chains recur in Chinese-market enterprise middleware because these applications share an architectural genotype: they treat database-returned values as implicitly trusted inputs for filesystem operations. If your environment runs Weaver E-cology, assume this chain exists in forms other than the exact CVE vector until proven otherwise.
Actionable steps: First, identify every E-cology deployment in your environment including test systems, backups, and lateral installations — the CVE doesn't distinguish between production and non-production for attacker targeting. Second, treat the 'remediated' claim as unverified until you confirm the exact build version your deployment runs, which may require vendor liaison. Third, audit for persistent access artifacts: rotated credentials that existed between 2016 and now, configuration files that may have been exfiltrated, and shared infrastructure (middleware, logging platforms, admin panels) that could serve as secondary pivot points. Fourth, implement output validation between database query results and any filesystem operation — the architectural fix isn't just parameterized queries, it's treating database content as untrusted input for file handlers.