To be fair, it would be a lot of work to fix the backend.  The SQL is dynamically generated for every request, and the code that does so is thousands of lines long, with nested subroutines that construct sub-portions of the query, so there is no easy way to check where things need to be parameterized.  Also there is some injection from unusual places (like a search options object separate from the search criteria object which includes the ASC&#x2F;DESC which, you guessed it, is directly injected).<p>Realistically, to be safe, you&#x27;d have to gut the whole thing and replace it.  You can be a &quot;little safe&quot; by doing something silly like replacing &#x27; with &#x27;&#x27; but that doesn&#x27;t protect in non-string cases, etc, and I wouldn&#x27;t propose a solution like that because it could give a false sense of security.<p>I understand the push-back.  The backend is maintained by others and it would add to their workload to secure it.  That&#x27;s a real and actual cost.<p>As for the business impact, you are right.  I just wanted it to be &quot;on the table&quot; that I informed people of the situation, so that if there is an exploit in the future, I don&#x27;t get the &quot;why didn&#x27;t you tell anyone this was vulnerable?&quot; or something like that.