How We Defend Against Malware Uploads
Any file-hosting platform that accepts anonymous uploads will eventually be used to host something malicious. The question is not if — it's how quickly the platform detects it, how thoroughly it contains it, and how reliably it keeps that file away from anyone else.
This briefing walks through the layered defense that every single upload on InvisHosting passes through, and the trade-offs we made along the way.
Layer 1: Extension and MIME enforcement
Before a byte is written to disk, the upload pipeline rejects executable extensions outright. PHP variants, shell scripts, server-side languages, Apache config overrides — anything that could be interpreted by our own stack is refused at the door. We do this with an explicit deny-list applied server-side, never trusting client-provided MIME types.
This is the cheapest possible defense and it blocks the majority of lazy attacks. It does nothing against novel threats, so we never rely on it alone.
Layer 2: Quarantine by default
Every accepted upload lands in a quarantine directory that is never web-accessible. The file's database row is created with quarantine_status = 'pending', and the file page shows a "scan in progress" notice instead of a download link. There is no URL, anywhere, that will serve a quarantined file.
Quarantine buys us time to do slower, more expensive checks without blocking the uploader's request — and it means a malicious file can never be downloaded between upload and scan completion.
Layer 3: VirusTotal analysis
Our quarantine-check cron job runs every two minutes and polls VirusTotal for the analysis result of each pending file. Three outcomes:
- Clean → the file is moved into the public uploads directory and marked
clean. - Malicious → the file is deleted from quarantine, the database row is marked
flagged, and the file page surfaces a clear "flagged as potentially harmful" notice. - Still scanning → nothing happens. We re-check on the next run.
released and flag it for manual review rather than punishing the uploader for VirusTotal being slow.Layer 4: Hash short-circuit
Re-uploading a known-clean file shouldn't require another full scan. We keep a hash of previously scanned files and, on match, release the new upload immediately with the prior verdict. This isn't a security gain by itself — the security gain happened during the original scan — but it keeps honest users fast and frees scan budget for actually-unknown files.
Layer 5: Takedown plumbing
Detection is only half the job. Every file has explicit flags for filebanned (ToS violation), legaltakedown, dmcatakedown, and malwaredetected. The download and view handlers check these flags on every single request — no caching, no staleness window. Revoking access is a database write away, and it's reflected the next time anyone hits the URL.
What we don't do
We don't scan file content for things that aren't malware. We don't fingerprint uploaders beyond what's needed for rate limiting and ban enforcement. We don't retain logs longer than we need to.
Privacy and security are partners, not opposites. The same pipeline that keeps malware off the platform also keeps our footprint on your file to an absolute minimum — scan it, verify it, serve it, forget it.
Where we're going
The roadmap includes per-upload sandboxed previews, stricter sanitization for SVGs, and a public incident page when we do have to remove content. If you spot something that looks off, report it at the address in the footer — we read every one.