One-Click Fix Verification

How long a developer waits to find out whether their patch actually worked directly determines how long their software stays vulnerable. Every hour between "fix submitted" and "fix confirmed" is an open window for attackers. Shrinking that window should be a first-order priority for any security-conscious team.

In manual penetration testing, fix verification can take days or weeks — constrained by pentester availability, scheduling, and scope negotiation. It's common for release deadlines to slip as engineering teams wait on security to complete retesting. The fix is ready. The blocker is process.

In Shinobi, verifying a fix is as simple as clicking a button.

How It Works

When a developer patches a vulnerability, they click the Verify Fix button on the corresponding finding. This spawns specialized AI agents carrying the full context from the original pentest — the same knowledge, the same attack surface model, the same exploit logic. Verification runs through three phases:

Phase 1: Cursory Checks

Before attempting anything, the agents confirm the basics: the application is reachable, the affected functionality is operational, and any credentials supplied by the user are still valid. If any of these fail, the verification attempt is marked as blocked and the user is notified immediately — no wasted cycles.

Phase 2: Exploit Replay

The agents replay the original exploit exactly as it was documented in the finding. For multi-step exploits, they automatically update pre-requisite state and variables in the exploit chain to ensure it remains executable against the current build.

Phase 3: Fix Bypassing

If the original exploit fails, Shinobi doesn't declare victory and walk away. It treats a blocked exploit as a hypothesis, not a conclusion — and then attempts to disprove it.

The agents try a range of bypass techniques to probe whether the fix is comprehensive or merely cosmetic. Examples include:

1. Modified payloads — Tests whether input validation is broad or specific to the original exploit string. If the original used <script>alert(1)</script>, Shinobi might follow up with <img src=x onerror=alert(1)> or <svg/onload=alert(1)> — checking whether the developer blocked one specific tag or actually sanitized all HTML output.

2. Alternative parameters and injection points — Probes whether the fix addressed the root cause or just the symptom at the original attack surface.

3. Different attack paths — Tests whether the remediation is structural or route-specific. For example, if an IDOR was patched on GET /api/v1/users/{id} by adding an authorization check at the route level, Shinobi verifies whether the same resource is reachable through POST /api/graphql or a bulk-export endpoint — distinguishing a properly enforced resource-layer control from a single-route band-aid.

4. Encoding and evasion variants — Tests whether filters can be bypassed through obfuscation, alternate character encodings, or protocol-level tricks.

Fix Bypass in Action

The following walkthrough shows Shinobi's fix verifier defeating a patch for a Server-Side Request Forgery (SSRF) vulnerability.

1. The vulnerability was identified in a screenshotting API endpoint.

2. Shinobi sets its objectives — not just to reproduce the exploit, but to actively probe the patch.

3. The original exploit fails. Shinobi infers that a blocklist was likely implemented.

4. Shinobi constructs a checklist of bypass techniques to work through systematically.

5. Its first attempt — encoding the IP in decimal notation — fails. It moves immediately to the next technique: hosting a redirect on its own server.

6. The redirect bypasses the patch.

7. Shinobi marks the finding as still open and attaches evidence.

---

 

Shinobi's fix verification is designed to give engineering teams rapid, high-confidence answers: not just "the original exploit is blocked," but "the fix is structurally sound." That's the difference between a patch that closes one door and one that actually locks the room.

Want to see the verifier agents in action? Book a demo to experience one-click fix verification firsthand.