Why was a finding marked Fixed when I didn't change it?

Why this happens

Issues persist per target across scans. That is the key idea. After each scan, Cyberlop looks at the issues it already knows. If a re-scan no longer finds one, it marks that issue Fixed. Simple. A finding is only marked this way when the scan genuinely did not re-detect it.

A Fixed label means "not seen this time". It does not always mean that someone changed the code. Three common reasons explain most cases:

• Someone on your side changed the code, a config file or a setting, and that change closed the issue for real.
• The later scan was set up differently. A narrower list of classes, a different profile, or exploitation turned off can all mean the scan tested less than the first one did.
• The weakness depended on a state of the app that was not there during the later run. Rare, but possible.

How to fix it

1. Open the issue from Issues and read the Summary and Evidence tabs.
2. Open both scans and compare the profile used, the classes and the Run exploitation phase setting.
3. Ask your team whether the affected file or setting changed since the earlier scan.
4. If you are not sure, set the disposition to Open (reopen) and click Update status.
5. Run the original profile again. Open the Diff tab. If the issue returns, it shows under Regressed.

Still not working?

Our page on how a retest proves a patch in confirming fixes worked explains it. If a finding of yours still looks wrong, contact us with the finding ID and both scan dates. The fixed and regressed tutorial explains the whole life cycle.

Related questions

• Why did a finding I fixed come back as a Regression?
• How do I confirm my fixes worked?
• How do I reopen a finding I closed?
• Will a finding I marked as a false positive come back on the next scan?
• How do I mark a finding as fixed?

Full tutorial

How to verify a vulnerability fix with fixed and regressed issues

Step-by-step, with annotated screenshots.

Updated 8 October 2026 · Back to the help centre