Contact: Support, Security and Abuse

The form and [email protected] reach the same inbox.

What to put in it depends on what it is about. The four sections below are the checklists we work from, and a message that answers them is a message we can act on without a round trip.

Support

Support is the channel for a scan that did not finish, a report you think is wrong, an account or credit question, or anything on the platform that does not behave the way the documentation describes.

Choose Support in the form above.

The scan: The scan identifier or the report link. A public report link is the fastest thing to work from, because it carries the module, the image and the settings the run used.
What you expected and what happened: One line each. If a layer is missing from a report, name the layer: static, document, dynamic, network, memory, intelligence or the AI narrative.
The account: The email address the account is registered under, if the question is about credits, seats or an API token. Never send the token itself.
How to reproduce it: The steps, and whether it happens every time or only sometimes. For an API or MCP problem, the endpoint and the HTTP status code you received.

Security disclosure

Report a vulnerability in Malwagon itself with Security disclosure chosen in the form above. That is what separates a disclosure from ordinary support when it arrives.

The security page describes how samples are isolated, what leaves the platform and how disclosures are handled. Read it first: a finding it already documents as intended behaviour is not a vulnerability, and the page will save you the write-up.

Where it is: The URL, endpoint or component. If it is in a report view, say whether the report was public or private.
How to reproduce it: Ordered steps, the request if there is one, and what an attacker gets at the end. A proof of concept that stops at the first sign of impact is enough.
Impact: What the finding lets someone read, change or reach that they should not. Say plainly if you are unsure.
Scope you stayed inside: Test against your own account and your own scans only. Do not access another tenant's samples or reports, do not run denial of service against the platform, and do not use a live malicious sample to demonstrate a web finding.
Disclosure status: Whether the finding is published anywhere, or when you intend to publish it.

Abuse and takedown

Abuse covers a public report that should not be public, content reachable through a report, and misuse of the platform itself, and it is also where a takedown request goes.

Choose Abuse or takedown in the form above, and say in the first line which of the two it is.

Free scans produce publicly viewable reports, so a document submitted anonymously can end up with its extracted strings, screenshots and indicators on a public page. A takedown request is how that gets removed.

What to point at: The exact report link, and inside it the specific artifact: a screenshot, an extracted string, a dropped file, a hostname or the sample entry itself.
Why it should come down: For example that it carries personal data, proprietary material, credentials, or content belonging to you or to an organisation you act for.
Who you are in relation to it: Whether you submitted the sample, own the affected material, or are acting for the owner. State the authority you are acting under.
For platform misuse: What the platform is being used to do, and the reports or accounts that show it. Attach the report links rather than describing them.

If your request concerns personal data about you specifically, the privacy policy sets out what is collected and the rights you have over it, and the same subject line reaches the same place.

Sales and plans

Sales is for plan and seat questions, for Team and Enterprise deployments, and for anything the pricing page does not answer.

Choose Plans and sales in the form above.

The plan you are looking at: Community, Pro or Team, and what is missing from it for you.
Scale: Roughly how many scans a month, how many analysts need seats, and how many runs need to be in flight at the same time.
What the work needs: The analysis images you need, whether runs have to be private, whether you need longer detonations, and whether the REST API or the MCP server is part of the workflow.
Anything that constrains the deployment: Data handling requirements, network conditions or reporting formats your team has to produce.

Writing the message

One topic per message, and a link rather than a description of a link. If it is about a scan, the scan id or the report address is the fastest thing you can give us.

Your message is written to our own database and the operator is notified directly. You are told it was recorded rather than that it was delivered, because those are different claims and only the first one is ours to make.

Do not send a live sample. If you want something analysed, submit it through the scan form and send the report link instead. A sample submitted to the platform never leaves it, and anything you paste into this box is outside that boundary.

For anything that needs an attachment or a thread you can point at later, write to [email protected].