hunt-lfi

Validates local file inclusion and template loader boundaries using controlled markers within authorized scope.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-lfi-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-lfi
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-lfi
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-lfi-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It provides a disciplined, evidence-gated procedure for testing whether template, include, or language file parameters can escape the controlled include root, without reading real sensitive files or producing false positives. ## Core Features & Use Cases - Engagement Gating: Runs only when authorization and scope are locked, and defers to the blackbox-vuln-orchestrator for current action recommendations. - Controlled Marker Testing: Uses self-created markers inside and outside the include root, changing one include semantic at a time (template name, relative reference, alias, loader prefix). - False-Positive Oracle: Treats captchas, WAF blocks, error pages, and 404s as inconclusive, requiring reproducible access to an out-of-root self-owned marker as valid proof. - Use Case: During an authorized web assessment, a tester suspects the template_name parameter crosses the include root; the skill guides baseline setup, single-variable probes, evidence capture, and routing to hunt-path-traversal or hunt-rce when appropriate. ## Quick Start Ask the agent to run the hunt-lfi procedure against the in-scope template parameter and report whether the include root boundary holds.

Frequently Asked Questions about hunt-lfi

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for local file inclusion vulnerabilities safely?

Create your own marker files inside and outside the expected include root, then change one include semantic at a time such as template name or relative reference. Valid proof requires the application to return your out-of-root marker reproducibly, never real system files.

What counts as valid evidence of an LFI vulnerability?

Valid evidence is the application returning, including, or exposing your own marker placed outside the controlled template root, reproducibly and excluding CDN or cache mapping. Error pages, missing-file messages, path echoes, and default 404 responses are not proof.

When should LFI testing stop during an assessment?

Stop when the only way forward is reading real system or user files, when template changes would affect shared content, or when no isolated marker can be created. Captchas, WAF blocks, rate limits, and login walls are inconclusive results, not vulnerabilities.

What is the difference between LFI and path traversal testing?

LFI testing focuses on server-side include and template loader semantics crossing the controlled include root. Pure file download or preview path manipulation is routed to the hunt-path-traversal skill instead.

Can LFI findings lead to remote code execution testing?

Only if the finding forms a controlled execution primitive, and only after the chain-review process proves every precondition step. The skill explicitly gates any escalation to hunt-rce behind that review.