Replacing the Security Sink (blacklist.includes) with a Useful Callable

Sometimes the shortest path to code execution is not "add new code" but "rebind the function the app already calls" to a more useful existing primitive. Frontend code often assumes a helper is a pure boolean function and never defends against the helper reference itself being attacker-controlled.

Why It Works

• If blacklist or includes is reachable via prototype pollution or object-path copying, you can make the app call your chosen function at that call site.

Vulnerable Pattern

• Code like if (!blacklist.includes(input)) ... where blacklist/includes can be reached through pollution or path copying.

Exploit Flow

1. Make the app call your chosen function in place of the original helper.
2. Choose a replacement whose call signature matches closely enough to avoid crashes.

Variations

• eval, document.write, setHTMLUnsafe, Array.isArray, or any sink whose arguments line up with the victim call site.

Common Blockers

• Wrong argument count, this binding issues, or the chosen function returning a value that stops the vulnerable branch too early.

PoC Sketch

?ownerDocument.defaultView.blacklist.includes=ownerDocument.write&x=<img src=x onerror=alert(1)>

Good Situations To Use It

• You have a path-copy / pollution primitive.
• A security check calls a helper you can reach.
• A useful function matches that call signature.

Sources

• fcsc2026/web/shrimp_saver
• fcsc2026/web/shrimp_saver_revenge