Retest Verdict: Fixed Endpoint, Unfixed Vulnerability Class
Two weeks ago you delivered a report containing a Critical SQL injection in GET /api/v2/reports?id=, proven with a boolean-based payload that returned other tenants' report metadata. The developers rewrote that endpoint to use a parameterized query. Their manager emails: 'Fixed - please retest and issue a clean pass so we can close the compliance ticket before Friday.'
During the retest the original parameter is genuinely fixed: the boolean payload now returns identical responses. However, the same reporting module exposes GET /api/v2/reports/export?filter=, built by string concatenation in the same Java class. A single quote produces a 500, and a two-condition boolean payload produces different row counts. No data beyond row counts has been retrieved. The compliance ticket requires a statement that the original finding is remediated, and the client has hinted that a 'partially remediated' verdict will be escalated to your account manager. The retest window closes in 36 hours.
1. What verdict do you issue, and in exactly what words?
Read the worked answer
The verdict is scoped to the instance, not the class: remediated at the reported endpoint, with a new instance of the same root cause identified during retest.
Suggested wording: 'Finding F-07 (SQL injection, GET /api/v2/reports?id=) is remediated. The parameterized query was verified using the original boolean-based payload and a time-based control; responses are now identical for true and false conditions. During retest, a separate instance of the same weakness (CWE-89) was identified at GET /api/v2/reports/export?filter=, where user input is concatenated into the query in the same code path. It is reported as new finding F-19. The compliance statement above covers only the originally reported endpoint.'
Why not 'clean pass': the phrase asserts the risk described in the original finding is gone. The risk was untrusted input reaching a SQL interpreter in the reporting module. That remains true one URL away, and a reader who relies on the pass will not look for it. Why not 'not remediated': the developers did fix what was reported, and saying otherwise damages credibility and encourages arguments about semantics instead of fixes.
2. Is the export endpoint a new finding or a reopened one? Justify the severity and the CVSS vector.
Read the worked answer
Report it as a new finding that is linked to F-07 as a recurrence of the same root cause. A new finding ID keeps the retest record honest (F-07 was fixed), while the link tells the reader this is a systemic pattern rather than an unrelated bug.
Severity: High by default, Critical if cross-tenant data is confirmed. Boolean-based blind injection gives confirmed query control but only one bit of output per request.
Vector reasoning: AV:N (remote HTTP), AC:L (no special conditions), PR:L (a normal authenticated user can call the endpoint), UI:N, S:U, C:H, I:N, A:N - 6.5 base. If the export module reads across tenants and the injection can be used to infer other tenants' rows, scope changes to S:C and the score rises toward 7.7–8.0 depending on privileges. Do not inflate integrity or availability: you have seen neither.
Root cause statement for the report: the defect is per-parameter string construction in a shared data-access layer. Fixing endpoints one at a time will keep producing recurrences. Recommend a single fix at the DAO/repository layer plus a static-analysis rule that fails the build on string concatenation into query objects. That is the finding the client's engineering leadership needs to read, and it is what makes the 'partially remediated' verdict useful rather than punitive.
3. Your account manager forwards the client's escalation and asks whether the report can 'soften the wording'. How do you respond?
Read the worked answer
Treat it as a QA and liability question, not a commercial one.
To the account manager: explain that a compliance attestation is a factual statement, not a customer-service gesture. A 'clean pass' followed by a breach traced to the export endpoint would expose the client's auditor, the client, and the firm; the retest evidence would show the injection was found and described as fixed. Offer alternatives that unblock the ticket without falsifying it: an interim mitigation letter stating that the original endpoint is fixed and that the export endpoint is disabled or WAF-blocked pending a code fix, with a re-retest slot within 48 hours of the patch.
To the client: restate the remediation evidence for F-07, provide the exact reproduction for F-19 so their developers can act immediately, and offer to join a 15-minute call with the compliance owner to explain why the two statements are compatible. Most compliance owners accept 'original item closed, new item opened' once it is spelled out; the conflict is usually wording, not substance.
Process: if pressure continues, route it through your technical QA lead rather than negotiating the verdict over email. Record the request and your response in the engagement file.