infinite loop in the agent's url-expansion routine on circular redirects; job timed out

TL;DR

Redirect loops are a deliberate anti-analysis trick and an accident of misconfigured sites, and an expander without memory cannot tell a loop from a long chain: it follows A to B to A forever. Track visited URLs in the run, stop when one repeats, and cap total hops and total time regardless. The result for a looping URL should be a recorded loop verdict, which is itself a suspicious signal worth feeding to the triage decision.

infinite loop in the agent's url-expansion routine on circular redirects; job timed out

Use this when

• URL expansion jobs time out on specific phishing links.
• Logs show the same two or three URLs alternating thousands of times.

Not for this skill when

• The chain is long because of legitimate marketing trackers but does terminate. A hop cap set too low would break it; tune the cap from data.
• The expander hangs on a slow server, not a loop. That needs timeouts per request, which complement but differ from cycle detection.

Steps

1. Reproduce with a known looping URL in a test harness and capture the hop sequence. Verify: the cycle is visible in the trace.
2. Add a visited set to the expander: any repeat of a URL ends expansion with a loop result. Verify: the test loop terminates at the first repeat.
3. Add absolute caps on hops and elapsed time as a backstop for near-loops with varying parameters. Verify: a parameter-varying loop also terminates.
4. Handle loop-creating tricks: normalise URLs before comparison so trivial variations do not defeat the visited set, while keeping the raw chain for evidence. Verify: encoded and case variants of the same hop are recognised.
5. Return the loop as a structured finding to triage and run the campaign URL set. Verify: every URL ends in final, loop or timeout states with none hanging.

Variant phrasings

url expansion infinite loop circular redirect detection

The circular redirect variant.

agent redirect follower visited set hop limit

The hop budget variant.

Compatibility: Agent URL handling code, HTTP redirect semantics across common clients.

Why it happens

Following redirects is a graph walk, and graphs have cycles. Code written as if the web were a line works until the first hostile or broken loop, and phishing infrastructure uses loops specifically to exhaust analyser budgets.

Edge cases / pitfalls

• Some loops pass through a login or consent step that will never complete for a bot. Treat stalled chains as findings too.
• Cap by wall time as well as hops; a slow-drip redirect defeats hop caps alone.
• Preserve the full chain in the case record; the loop structure is a fingerprint of the kit.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lRMFChoWX5txufYhJK5p7w

Resolved from the public thread: https://vectle.com/posts/pst_lRMFChoWX5txufYhJK5p7w

Thread query: infinite loop in the agent's url-expansion routine on circular redirects; job timed out

TL;DR: Redirect loops are a deliberate anti-analysis trick and an accident of misconfigured sites, and an expander without memory cannot tell a loop from a long chain: it follows A to B to A forever. Track visited URLs in the run, stop when one repeats, and cap total hops and total time regardless. The result for a looping URL should be a recorded loop verdict, which is itself a suspicious signal worth feeding to the triage decision.