Report a security issue

This goes straight to the Xplor Security Team. You don't need an account, and we don't need to know who you are.

Before you start

What happens to what you send

Your written report is encrypted in your browser before it's sent. The service that receives it only ever holds ciphertext which it has no key for. Only the security team's triage app can open it, using a private key held in hardware that never lets it out.
Attachments work differently. We scan files for malware, and a scanner can't check what it can't read. So attachments reach us readable, we scan them, then we encrypt them at rest. If you'd rather the scanner didn't see something, please put it in the written report instead.
We don't ask who you are. The contact field is optional. Leave it empty and we've no way to reply, so use your claim token to check back instead.
We can't promise anonymity at the network level. Connecting to any website shows your IP address to whatever sits in front of it. We keep ours away from case records and out of reach of the people handling reports, and we delete it after 30 days. If that's not appropriate for your situation, use Tor or a network you don't control, and avoid including any information that could identify you.

Scope

What this channel is for

Use this form to tell us about:

a security vulnerability in an Xplor product or service
a system or account you think has been compromised
data exposure — information reachable that shouldn't be
abuse of an Xplor service

Don't use this form for wrongdoing, misconduct, HR matters or ethics concerns. Those go through Xplor's whistleblowing process, which carries legal protections and obligations this channel doesn't provide. Reporting them here would leave you without those protections.

If you'd rather not trust this page's JavaScript

Encrypt your report locally with our PGP key — it's the Encryption field in security.txt — and paste the ASCII-armoured block into the report field. This page wraps it in its own encryption like any other text, we strip the outer layer during triage, and an analyst opens the inner block in their own tooling.

We don't run an automated PGP decryption service, and we don't take encrypted email into an automated pipeline. Putting an OpenPGP parser inside the one component that can decrypt every report would invert the protection this design exists to provide.

Your armoured block comes back byte for byte. One thing we can't avoid: browsers normalise line endings in a text box to line feeds. PGP armour copes with that and the signature and checksum still verify, but if you need the exact bytes kept, say so in the report and we'll arrange another route.

Your report

What kind of issue is this?

Tell us what you found What it is, where it is, and how to reproduce it. Anything that helps us confirm it quickly is worth including. This text is encrypted before it leaves your browser.

How we can reach you (optional) An email address, a Signal number, a name — whatever you're comfortable with, or nothing at all. This is encrypted with the report, not stored separately.

Attachments (optional)

Up to 5 files, 25 MiB each. We accept: -

Attachments aren't end-to-end encrypted. We scan them for malware first, which means they have to be readable. We encrypt them at rest afterwards.

Files often carry metadata that identifies you — camera model, GPS coordinates, usernames, document authors. Stripping it also strips evidence, so it's your call rather than ours.

Choose files to attach

Remove metadata from images before uploading Off by default. This works on JPEG and PNG only — we won't claim to strip formats we can't strip properly. PDFs, packet captures, archives and Office documents go up exactly as you give them to us.

Encrypting to key -

Report a security issue

This browser can't encrypt your report

The service is temporarily unavailable

We've got your report

Check a report you've already sent