# File Processing Pipeline Testing

Model and attack the full file processing pipeline - upload, validation, storage...

- Repository: https://github.com/xalgorix/xalgorix (1285 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add xalgorix/xalgorix --skill file-processing-pipeline-testing -g -a claude-code -y`
Codex: `npx skills add xalgorix/xalgorix --skill file-processing-pipeline-testing -g -a codex -y`
Cursor: `npx skills add xalgorix/xalgorix --skill file-processing-pipeline-testing -g -a cursor -y`
Gemini CLI: `npx skills add xalgorix/xalgorix --skill file-processing-pipeline-testing -g -a gemini-cli -y`

## Description

Model and attack the full file processing pipeline - upload, validation, storage, transformation, scanning, preview, import, processing, serving - hunting parser confusion, archive extraction abuse, traversal, decompression issues, access-control gaps between stages, and content-type mismatches.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# File Processing Pipeline Testing

## Purpose

"Can I upload a .php?" is one question about one stage. Real breakage happens BETWEEN stages: the validator accepts what the parser executes, the transformation library trusts what the upload validator rejected, the storage layer exposes what the application hides. Model the whole pipeline, then test every stage boundary and every trust handoff.

## The Pipeline Model

```text
upload -> validate -> store -> transform -> scan -> preview -> import -> process -> serve/download
```

Map which stages exist for YOUR target (not all do): is there a preview generator, a thumbnailer, a virus-scan step, an import parser, a download/share endpoint? Each arrow is a trust handoff where one stage assumptions about the file may no longer hold.

## Stage-by-Stage Testing

### Upload / validation boundary
- Filename: path segments, traversal (`../../`), reserved names, unicode lookalikes, very long names, null bytes, case variants (`.PNG`, `.pHp`), double extensions (`report.pdf.php`), trailing dot/space (`file.php.`, `file.php `)
- Extension vs MIME vs magic bytes disagreement: declare `image/jpeg`, send PHP bytes with `.jpg` extension; note WHICH check each endpoint trusts
- Polyglots: GIF/JPEG containing embedded code, PDFs with JS, SVG with embedded scripts (SVG is XML: scripts and XXE live inside), HTML-in-image (served with wrong content-type becomes stored XSS)
- Content-Type the server assigns at STORE time vs at SERVE time (mismatch is the exploitable condition)

### Storage
- Where does the file land: same-origin path (execution risk), CDN/object storage, separate storage domain?
- Is the stored object accessible directly (guessable URL, sequential name) BEFORE the app links it?
- Storage-level ACL: can the raw object be fetched unauthenticated once the URL is known?
- Overwrite: does uploading with the same name/fingerprint overwrite another user object (hash-collision namespaces)?

The rest: https://github.com/xalgorix/xalgorix/blob/HEAD/internal/tools/skills/data/application-security/file-processing-pipeline-testing/SKILL.md