Security

How samples are isolated

Each analysis runs in its own virtual machine; on the isolated detonation network that machine has no route off its own segment and no path to the internet, and the machine is discarded after the run rather than cleaned.

One machine per analysis: A sample is detonated in a virtual machine of its own under a kernel level hypervisor. It does not share a machine with another submission, and the disk state of a previous run is not carried into it.
The isolated network: The isolated detonation network is defined with no forwarding at all, so there is no NAT and no route from the guest off its own segment or to the internet. Guest to guest traffic on that segment is switched off as well. A sample that tries to reach a command and control server on this network is recorded trying and gets nowhere.
Internet egress is a per-scan option: Some samples only reveal their behaviour when they can reach their infrastructure, so internet egress is a per-scan option on the submission form; with it on, the guest runs on a separate NAT network instead of the isolated one. It is not gated by plan, and on the file submission form it starts ticked, so it is an option to turn off rather than one to turn on. The anonymous free scan is the exception: those runs go on the isolated network whatever the submitted options say, because the code that picks the network refuses the option for them rather than trusting the form that set it.
Reverted, not cleaned: Each run gets its own throwaway copy-on-write overlay over a read-only base image, and reverting means deleting that overlay rather than cleaning the machine in place. Cleaning up after malware means trusting that you found everything it changed, which is the assumption malware is written to defeat. Discarding the disk state does not depend on that assumption.
Host-facing traffic is filtered: Traffic from a guest towards the host is filtered rather than routed: the guest is given the services a detonation needs and is not given a general path to the infrastructure running it. On the internet network, traffic from the guest towards private and link-local address ranges is dropped as well, so egress is aimed at the public internet rather than at the network the platform sits on.
Nothing installed beside the sample: Telemetry is taken at the hypervisor and kernel layer rather than from a monitoring agent the sample can see, so the recording does not depend on a component running next to the code under analysis. The platform page describes the recording layers in more detail.

These are descriptions of mechanisms, not assurances about outcomes. No method of transmission or storage is completely secure, and nothing on this page is offered as a guarantee that any particular sample, account or report is safe from every attack.

What leaves the platform

The sample itself never leaves; the only things sent to a third party are hash values and derived indicators, and they go to reputation services.

A derived indicator is a value produced by analysis rather than a piece of the sample: a SHA-256, MD5 or SHA-1 hash, a domain name the sample resolved, an IP address or URL it contacted, a JA3 or JA4 TLS fingerprint, a mutex name, a registry path. None of these carry the bytes you submitted. They are what a reputation lookup needs in order to answer whether anyone else has seen the same thing, which is why they are the only class of data that goes out.

The AI narrative layer is held to the same line, and it is a stricter one than it may look. It receives locally derived material only: a behaviour summary, the API call sequence, the indicator list, and extracted strings. It does not receive the sample. When a submission is an obfuscated script, the deobfuscation is done on the platform first and the AI layer comments on that local result rather than on the original.

What the platform stores about a scan, how long it keeps it, and how to have it deleted are covered in the privacy policy.

Report visibility

Reports from the free tier are publicly viewable, which is stated on the submission form before you submit and requires you to tick a consent checkbox; paid plans can keep scans private.

The free tier exists because a public corpus of analysed samples is useful to everyone reading it, and the trade is made in the open rather than buried in the terms. If a submission must not become public, it should not go through the free tier. A consent that was never shown proves nothing later, so the checkbox is recorded against the specific submission it authorised.

On a paid plan, visibility is chosen per scan. A private scan is not listed in the public index and is excluded from the sitemap, and the visibility check that guards the report refuses it to anyone outside the account it belongs to, or the organization it was explicitly shared with.

Ultra Privacy

Ultra Privacy is a stricter mode for a submission that should leave as little behind as possible. A scan submitted this way is written as private and is not published. Its derived data is held back from the intelligence and AI layers, so not even its hash is queried against an external service. When analysis finishes the platform deletes the sample bytes, the artifacts, the stored analysis records, the indicators, the captured traffic and the pre-built report, and leaves the report page as a tombstone recording that the scan ran and that its data is gone.

Because the bytes are deleted, features that need them later are unavailable for that scan: there is nothing left to re-analyse, to generate a byte-level rule from, or to match in a retro-hunt. That is the intended trade, not a limitation to work around. See the plans page for which tiers include private scans.

Account security

Account security consists of a password policy with a twelve character floor, optional two-factor authentication, rate limiting in front of the password check, and revocable API tokens.

Passwords: The minimum length is 12 characters. A new password is also checked against a list of common passwords, against similarity to your own account details, and is rejected if it is entirely numeric. These run wherever a password is chosen, at registration and at password change.
Two-factor authentication: Two-factor authentication is available using TOTP, the standard six digit code from an authenticator app, set up by scanning a QR code. Enrolment issues single-use backup codes for the case where the authenticator is not to hand. At the sign-in step an accepted code is remembered for as long as it could still be accepted, so offering the same code again is refused.
Failed sign-in attempts: Repeated failed sign-in attempts are rate limited per client address on the paths that compare a password, and each failure is logged. The budget is charged to the address doing the guessing rather than to the account being named, so nobody can lock you out of your own account by guessing at it. The limiter is deliberately best effort: if its counter store is unreachable it stops limiting rather than refusing every sign-in on the platform, which is part of why every failure is logged as well.
API and MCP tokens: Programmatic access uses a bearer token presented in the Authorization header. The token value is shown once, at creation, and only a keyed hash of it is stored, so it cannot be read back out of the platform later. A token can be created with an expiry date, carries its own read or submit scope, and can be revoked, which takes effect on the next request that presents it. Details are on the API page.

Reporting a vulnerability

If you have found a security issue in Malwagon, please tell us through the contact page and describe it as a security report so it reaches the right people.

Reports are welcome, including ones about behaviour that turns out to be intended. A useful report contains enough for someone else to reproduce the issue: the affected URL or endpoint, the steps in order, what you expected and what happened instead, and any request or response detail that matters. If a proof of concept is easier to show than to describe, include it. Please say so if the finding involves another user's data.

We ask that you give us a reasonable opportunity to investigate and fix an issue before describing it publicly, and that while testing you stay within your own account and your own submissions: no access to other users' data, no degrading the service for other people, and no social engineering of users or staff. Please do not upload real third-party data as part of a test.

There is no bug bounty programme and no reward is offered for a report. This page sets out what we ask of a reporter and is not a legal undertaking of any kind.

Reporting abuse

If a public report page contains something that should not be there, tell us through the contact page; requests to take a report down are reviewed case by case.

The usual case is a document or file submitted to the free tier by someone who did not realise the report would be public, and whose contents turn out to include personal or confidential information. It also covers a report that exposes data about you, and content that is unlawful or otherwise does not belong on a public page.

Send the report URL, or the SHA-256 of the sample if you have it, and one line on what the problem is. If you are asking on behalf of the person whose data it is, say so. The privacy policy covers requests about your own personal data, and the terms cover what may be submitted in the first place.