VulCode

Vulnerability disclosure: how to report a security issue to VulCode

Found a flaw in our website, client panel or an open source project? Tell us before someone else does. These are the rules that protect both you and our clients.

Report a vulnerabilitySecurity
A vulnerability report written in a mail app to hello@vulcode.com and on a phone the VulCode reply thread: receipt, reproduction, fix and thanks
The vulnerability report thread on a phone with the VulCode replies

What this policy covers

The systems we run ourselves. Everything else is its owners' responsibility.

  1. vulcode.com

    • vulcode.com and all its pages, in English too

  2. Client panel and API

    • The client panel at vulcode.com/en/panel, together with its standalone version
    • The site API at vulcode.com/api

  3. Our open source repositories

    • Our open source repositories in the VulCodeCom organisation on GitHub

  4. Out of scope

    Other people's systems and actions against people

    • Our clients' websites and systems, even if we built them
    • Services of providers such as Cloudflare, GitHub or Discord
    • Social engineering against our team or our clients
    • Overloading servers and performance testing

Rules for testing

Look, but so that nobody except you and us notices you were looking. If you follow these rules, we treat your report as help, not as an attack.

  1. Your test accountYour projectsYour tickets
    Other accounts and passwords

    Use your own accounts

    To test the panel, create your own account. Do not try to sign in to someone else's or guess other people's passwords.

  2. Finding
    Confirming
    Stop and report

    Stop at the proof

    Once you see the flaw works, stop. Do not pull more data than you need to show it.

  3. Your accountSomeone else's
    Changing data
    Deleting
    Invoices and tickets

    Do not change or delete data

    No changes to other people's accounts, projects, invoices or tickets.

    1. A scanner gently, on your own account
    2. No load tests
    3. No mass scans

    No overloading

    No load tests and no mass scans. The panel has rate limits and will treat them as an attack.

  5. Other people's data
    • Report it at once
    • Saving it
    • Sharing it

    Leave personal data alone

    If you come across other people's data, do not save or share it, and report it to us right away.

  6. Publishing a write-up
    Fixdeployed
    Write-upagreed with us
    Creditwith your consent

    Do not publish before the fix

    Details stay between us until we fix the flaw and agree with you on what can be described.

How to write the report

A plain email to hello@vulcode.com is enough. A report like this lets us reproduce the issue straight away.

A vulnerability report in a mail app: subject, where, what, how to reproduce in three steps, impact, proof, credit and two attachments

  1. Where and what

    The page address or panel path, the type of flaw and one sentence on what it allows.

  2. How to reproduce

    The steps in order, on your own test account, so we can repeat the problem straight away.

  3. Impact, proof and credit

    Who could exploit it, a screenshot or recording without other people's data, and whether you want credit by name.

What happens after you report

Your report is read by the person who writes the code. There is no form that disappears into a queue.

You
the reporter
  • ReceiptYou email the report
  • UpdateYou check the flaw is gone
  • ThanksConsent to credit
VulCode
the person who writes the code
  • ReceiptReceipt confirmed
  • VerificationReproducing it and who it affects
  • FixThe fix deployed to production
  • UpdateWhat was fixed, in writing
  • ThanksThanks under your name

  1. Receipt

    You VulCode. We confirm the report arrived and someone is on it.

  2. Update

    VulCode You. We tell you what was fixed and ask you to check.

  3. Thanks

    You VulCode. With your consent, we say who found the flaw.

If the flaw could have affected our clients' data, we inform them and the competent authority as GDPR requires.

Where to report if it is not our system

Not every problem belongs with us, and not every bug is a security flaw. The reporting address also sits in the standard place where tools and researchers look for it.

    • A flaw on vulcode.com or in the client panelFollowing the rules on this page.
    • A flaw in one of our open source projectsBy email, not in a public GitHub issue, until we release a fix.
    hello@vulcode.com
    • A flaw on a site we built for a clientYou can also write to us and we will pass it on to the client.
    The site's owner
    • A flaw in Cloudflare, GitHub, DiscordThose are their systems, not ours.
    That company's security programme
    • An ordinary bug that does not endanger dataWe fix it, without the urgent track.
    The contact form or a panel ticket
/.well-known/security.txt
Contact: mailto:hello@vulcode.comExpires: 2027-10-06T00:00:00.000ZPreferred-Languages: pl, enCanonical: https://vulcode.com/.well-known/security.txtPolicy: https://vulcode.com/pl/firma/zglaszanie-podatnosciPolicy: https://vulcode.com/en/company/vulnerability-disclosure

Questions from researchers

What researchers ask us most often before reporting.

Something to report?

Write to hello@vulcode.com. The subject fills itself in, and the message is read by the person who writes the code.

Report a vulnerability