Sn1per Deep Dive Part 4: Workspaces, Reporting, and the Professional 2026 Architecture

Every previous post in this series was verified by reading the actual 1N3/Sn1per Community Edition source. This one can’t be, and it’s worth being upfront about why: the pro/ directory in that public repository contains a single file, notepad.html. The Professional engine is closed-source. Everything below comes from Sn1per’s own release notes and documentation pages rather than from code this series read directly, and it’s flagged that way throughout rather than presented with the same confidence as Parts 1 through 3. That gap doesn’t close later in this series either: Part 7’s root-verified testing reran the Community Edition against a real lab, not the paid tier, so everything below still stands as documented rather than directly confirmed.

Community is CLI-only, Professional is a web UI on top of the same engine

Sn1per’s own comparison post is direct about the core split: Community Edition is “completely Command Line (CLI) driven,” fine for a handful of targets, cumbersome past 5 to 10. Professional’s main draw is a full web UI for remote management across an entire workspace, plus a set of add-on modules and, notably, access to “Sn1per SE,” a private development branch that receives scan engine updates ahead of what lands in the public Community repository. As of that comparison post, Community sat at v9.0 while the Professional engine had already reached v10.1, which lines up with what Part 1 found: the Community script cloned for this series identifies as v9.2, several point releases behind whatever Professional customers are actually running day to day, a gap Part 7’s real root testing reconfirmed still holds against a live Community install months later.

Sn1per Professional customers get two weeks of email support post-purchase, a specific and fairly short window worth noting exactly as stated rather than rounding up to “professional support included.”

What Pro 2026 specifically added

Sn1per’s release notes describe the 2026 release as “the largest since the v10.0 line,” and the list of what shipped is long enough to be worth going through by category rather than as a single wall of features.

Deployment. Docker-first, built on a Kali Linux rolling base with Apache 2.4, PHP 8.4, SSL, and HTTP Digest auth pre-configured. A docker compose service named sn1per-pro maps the web UI to host port 1338 (container-internal 1337), depends on a PostgreSQL service, and bind-mounts a shared /sniper/loot directory so scan output survives container restarts. The bare-metal installer (install_pro.sh) does the equivalent setup directly on Kali, Ubuntu, or Debian, including generating a random admin password on first run, stored at pro/data/.admin-password, and applying systemd hardening overrides (PrivateTmp, ProtectSystem) to Apache.

Interface. A move from Bootstrap 3.3.7 to Bootstrap 5.3 on the Tabler theme, replacing the old accordion-style Quick Commands panel with an Offcanvas sidebar that stays out of the way of scan output. That sidebar has thirteen named panels: Commands, Bruteforce, Fuzzer, Threat Intel, MassPwn, OSINT, Scan Tasks, Scheduled Tasks, Subdomain Takeovers, Credentials, Vulnerabilities, Notes, and Change Notifications. DataTables 2.x adds CSV, Excel, PDF, and Copy export to every table in the product, and a dark/light theme toggle persists via localStorage.

Workspace management. A new workspace-navigator.php landing page lists every workspace with host counts, last-scan timestamps, and risk gauges, so an operator running several concurrent engagements doesn’t have to SSH in and read directory listings to figure out which workspace is which. workspace-report.php and host-report.php give per-workspace and per-host detail respectively, both reading from the same SC0PE finding format Part 3 covered from the Community side.

Programmatic access. api.php implements a JSON API v1.0, the first documented programmatic interface Sn1per has shipped, authenticated either via the same HTTP Digest credentials as the web UI or a new X-API-Key header aimed at CI/CD and SOC integrations rather than interactive use.

New CLI flags. -v/--verbose, -db/--debug, and -rr/--remove-resume-files are documented as new in 2026, and specifically as session-scoped: they apply to the invoked scan only and don’t permanently change sniper.conf. -rr is the practical one: Sn1per’s resume-file mechanism speeds up rescans by skipping already-completed steps, and -rr clears that state for a genuinely fresh run without manually deleting files under loot/workspace/<name>/scans/.

Advanced modules. Five, all gated behind Professional: ReverseAPK (mobile APK decompilation via auto-installed JADX, APKTool, dex2jar, and libsmali-java, with a browser upload interface), MassPwn (a curated exploit database and payload repository for mass-exploitation workflows), Threat Intelligence (RSS feeds plus the CISA Known Exploited Vulnerabilities CSV plus Nuclei template integration), Nessus import/correlation, and a Burp Suite proxy integration defaulting to 127.0.0.1:8080.

A discrepancy worth flagging rather than glossing over

Sn1per’s release notes describe an “expanding SC0PE vulnerability framework” in 2026, and list six specific files as that framework: sc0pe.sh, sc0pe-active-webscan.sh, sc0pe-network-scan.sh, sc0pe-passive-webscan.sh, static-grep-search.sh, and javascript-analysis.sh. Every one of those six filenames is already present, unchanged in name, in the Community Edition modes/ directory this series cloned for Part 3. That’s not necessarily wrong: the Professional engine could plausibly have expanded what’s inside those same files substantially (more templates, deeper checks) while keeping identical filenames across editions, which would be a reasonable thing for a vendor to do and a reasonable thing for release notes to mention. But it’s also possible the release notes are describing existing shared functionality as if it were new to the paid tier specifically. Reading Professional’s actual sc0pe-active-webscan.sh against Community’s would settle it, and that file isn’t available to read. Flagging the ambiguity is the honest option here, rather than repeating “expanded” as a confirmed fact the way the rest of this post confirms things read directly from source.

What this means for choosing a tier

None of this changes what Parts 1 through 3 established about the Community Edition’s actual mechanics: the per-port msfconsole auto-exploit chain, the five-source subdomain enumeration pipeline, the template-driven sc0pe scoring engine, all run identically whether or not a Professional license sits on top, and Part 7’s real root testing confirmed every one of those mechanics live. What Professional adds is almost entirely operational surface area for running that same engine across a large number of targets and a team of people: a UI instead of a terminal, a workspace model instead of flat loot directories, an API instead of shell scripting around the CLI, and OS-level packaging (Docker, systemd hardening) so it’s less work to stand up in the first place. For a single target, the Community Edition genuinely is the whole scanning engine. For a hundred targets updated daily across a team, the Community Edition is the same engine with none of the tooling built to manage that scale, which is exactly the gap Professional is priced to close.

Part 5 leaves the tool itself behind and moves to the other side of the wire: what an automated Sn1per sweep, Community or Professional, actually looks like to whoever is watching the target’s logs.