DETONATION CHAMBER
chamber
sealed
runtime
·
egress
·
inference
·

Detonate untrusted code. Watch what it does. Keep the blast inside.

Paste a package, repo, or link you don't fully trust. Detonation Chamber runs it in a sealed, throwaway sandbox, records every file it reads and every address it reaches, and returns a verdict, with each escape attempt contained. How it works ↓

auto

Pick a type above and type a name, or paste a full reference. Nothing is run on your machine.

Scan a real package
Replay an attacksynthetic
Live containment test

Scan strip

filesystem process network blocked
live console idle
detonation-chamber · sealed sandbox syscall monitor · gVisor runsc
chamber@sandbox:~$ ▋

Event log

0
t+classoptargetresult

    Chamber activity

    ·

    Verdict distribution

    Top indicators observed

      Recent detonations

      whentargetverdictriskcanaryblockedreport

        What is Detonation Chamber?

        Installing a package, cloning a repo, or opening a link can run code that reads your secrets, calls out to the network, or changes files. Detonation Chamber runs it in an isolated sandbox first and shows you exactly what it did.

        01

        Submit

        Paste an npm or PyPI package, a GitHub repo, or any URL. The artifact is fetched on the host and never run there.

        02

        Detonate

        It runs inside a one-shot container with no network route out, a read-only disk, and dropped privileges, all isolated by gVisor. Fake "canary" credentials are planted as bait.

        03

        Read the verdict

        Every file read and connection attempt is drawn on the scan strip in real time. You get a risk score, the indicators, and a verifiable report: benign, suspicious, or malicious.

        What the chamber contains

        every one of these is enforced by the sandbox, not by trusting the code
        • Secret theftCanary AWS keys, SSH keys and tokens are planted and watched; any read is flagged.
        • Data exfiltrationCode-execution jobs get no network route, so every outbound connection fails and is logged.
        • Phishing pagesCredential forms posting cross-origin are caught; the page is browsed GET-only, never submitted.
        • Destructive commandsrm -rf / and friends hit a read-only root filesystem and fail.
        • Fork bombs & resource abuseHard process, memory, CPU and wall-clock limits kill runaway code.
        • Privilege escalationAll Linux capabilities dropped, no-new-privileges, gVisor kernel isolation.
        • SSRF & metadata theftPrivate, loopback and link-local targets (incl. 169.254.169.254) are refused on every redirect.
        • Prompt injectionFetched page content enters as inert data; there is nothing in the sandbox for it to act on.

        Who it's for

        • AppSec & SOC analysts triaging a reported package or link, who need defensible evidence for a ticket.
        • Developers vetting a dependency before npm install, who want a two-second yes/no with reasons.
        • CI pipelines gating new or updated dependencies before they reach a build.

        Under the hood

        • gVisor (runsc) for kernel-level isolation; one disposable container per job.
        • strace records real filesystem, process and network syscalls: behaviour, not guesswork.
        • Vultr Cloud Compute hosts the app and runs every sandbox.
        • Vultr Serverless Inference writes the analysis plan and the plain-English verdict.