vulnerability intake

Submit a finding

read the scope, then fill the form. encrypt it if it matters.

address
rky@shellcode.gg
key
0xA71F 4C09 2B3D E884
default window
90 days · coordinated
[01] >

Scope

This page takes vulnerability reports and handles them under coordinated disclosure. It is not an invitation to test anything, and the scope below is the whole of it - read it before you write, because it decides whether a report can be acted on at all.

01

In scope

  • Issues in tooling published under this domain - source, releases, build artefacts, and the instructions that come with them.
  • Issues in shellcode.gg itself that need no active testing to notice: an exposed file, a stale DNS record, a key or token that should not be public.
  • Findings in a third-party product you were authorised to test, where you want the vendor contact and the disclosure handled by someone who has done it before.
  • A report a vendor has ignored or refused, where the window has run out and you want a second read before you publish.
02

Out of scope

  • Raw scanner output, and a tool's own severity rating pasted in place of a finding. Verify it by hand or do not send it.
  • Missing headers, TLS configuration grades, mail-policy opinions and other best-practice notes with no demonstrated impact.
  • Denial of service, social engineering, physical access, and anything that needs an endpoint the reporter compromised themselves.
  • Offers to sell an exploit or broker access. Nothing is bought here, and nothing is disclosed to anyone but the vendor.
  • Anything found by testing a system you had no written authorisation to touch.
[02] >

Severity reference

Pick the band that matches the impact you can actually demonstrate, not the one that would be true with three more preconditions. Bands follow the CVSS v3.1 ranges and drive the response windows further down.

9.0-10.0

Critical

Unauthenticated code execution, a complete authentication bypass, or key material that reaches other people's data. Send this one encrypted.

  • pre-auth rce
  • auth bypass
  • key material
7.0-8.9

High

A trust boundary crossed: privilege escalation, authenticated code execution, or read access to records the account was never meant to reach.

  • privesc
  • internal ssrf
  • access control
4.0-6.9

Medium

Real impact behind a precondition - a specific role, a user interaction, or a non-default configuration - and the precondition is reachable in practice.

  • stored xss
  • csrf
  • path traversal
0.1-3.9

Low

Demonstrable but narrow: limited disclosure, a weak default, or a flaw that costs an attacker more than it returns. Still worth sending.

  • info leak
  • weak default
  • rate limiting

Your rating is the starting point, never the final one. The band is agreed during triage, and if it moves you get the reasoning in writing rather than a silently edited number.

[03] >

The report

Eight fields. The ones that matter are the target and the reproduction - a report that cannot be reproduced is a rumour, and a rumour cannot be taken to a vendor.

A pseudonym is fine. It is what appears in the advisory credit.

Used for the acknowledgement and the thread that follows. Nothing else.

Name the thing and the version, build or commit you tested against.

Your assessment. It is confirmed or renegotiated during triage.

One sentence: the flaw, where it lives, what it gets you. This becomes the subject line.

Steps a stranger can follow: the exact request or input, the environment, what you expected and what happened. Do not attach files - a mail draft composed by a link cannot carry them. Say what you have and it gets requested over encrypted mail.

The default is 90 days. Nothing is published before the window closes, and nothing is published at all without agreeing it with you first.

This page has no server. Submitting checks the fields, then hands the assembled report to your own mail client addressed to rky@shellcode.gg - nothing is transmitted from this page, and no copy of what you typed exists anywhere but your browser. If nothing opens, your browser has no mail handler: the form stays filled in, so copy it into a message and send it yourself.

Encrypt it first
[04] >

After you send

One person reads it, and that person answers. There is no queue, no ticketing bot, and no automated first reply pretending to be triage.

  1. 01

    Acknowledgement

    The report is read by hand and answered with a reference, a first view on the band, and a question list where the detail is thin. If it is plainly out of scope you are told then, not three weeks later.

    by severity band

  2. 02

    Triage and reproduction

    It gets reproduced against the version you named. If it does not reproduce you get the exact attempt back rather than a form rejection - a failed repro is usually an environment difference worth naming.

    48h - 10 working days

  3. 03

    Written assessment

    You receive the agreed band with the reasoning, the impact as understood, and what happens next. Where the finding is yours to take further, you get that in a form you can hand to a vendor unedited.

    in writing, same thread

  4. 04

    Coordinated disclosure

    The vendor is contacted where you have not already done it, a window is agreed, and the advisory credits your handle unless you asked otherwise. Nothing goes public early and nothing is sold to anyone.

    90 days by default

[05] >

Response windows

What you can expect to wait, by band. These are the targets the intake is run to, written down so you can hold them up when one slips.

Response is the first reply from a person; triage is a reproduced and banded finding; disclosure is the default public window. Targets, not a contractual service level - working days are Monday to Friday, UTC+01, and a window runs from your first message. A window is extended in writing, never silently.
Severity Response Triage Disclosure
Critical under 12h under 48h 7-30 days
High under 24h under 5 working days 30-90 days
Medium under 48h under 10 working days 90 days
Low under 5 working days best effort 90 days

a window that is about to be missed is flagged before it is missed, with a reason and a new date. silence is not one of the options.

[06] >

Encryption

Anything with working exploit detail goes encrypted. Put the summary in the form, then send the rest to the address below under this key.

pgp public key

A71F 4C09 2B3D E884 5FD2 9C31 0E67 B4AA 21D5 F308

Placeholder key - replace with the real fingerprint before launch.

Check the fingerprint against the one in the site footer and on the contact page before you trust it, and ask for the full public block by mail if you would rather import it than type it. If you have no way to encrypt, send the summary alone and say so - the detail can move to a channel that works for both of us.

not a vulnerability report

Something else to raise?

Scoped work, a vendor who stopped replying, or a question this page did not answer. Same person, different inbox rules.

Get in touch Read the FAQ