If you’ve found a vulnerability
When you want to report a vulnerability, the first thing you need to do is find the right contact to send your report to. There are several places you can check to find contact details for a vendor.
- see if the vendor has a security.txt file on their website. Security.txt is a standard that gives people an easy way to contact a vendor about a security issue. It’s a file that sits on the vendor’s web server, and gives details of their PGP fingerprint, email address and vulnerability reporting policy. You can find the security.txt file for any website through the well-known path. For example, CERT NZ’s security.txt file is at https://www.cert.govt.nz/.well-known/security.txt
- look at the vendor’s website to see if it has contact details for their IT support or security team. The privacy page may reference a reporting point, or they might have a security policy page that lists their contact details
- check the WHOIS details for the vendor’s website. You can find the domain registrant’s contact information, like emails and phone numbers, there — it might be something like email@example.com, for example. WHOIS is a searchable domain details database, and a good place to start when you’re looking for a vendor’s contact details
- try doing an IP lookup to find the network owner for the website’s IP address. This can be a helpful back-up contact if you don’t get a response from the domain registrant. They might be able to let the domain owner know that you need to report a problem.
What to put in your report
The more information you put into your report, the better it is for the vendor. That doesn’t mean you should search for sensitive data to prove the vulnerability’s there though — it’s the vendor’s responsibility to do that. If you have concerns about something in particular, let the vendor know. They can assess the situation themselves.
Your report should, at a minimum, include details of:
- the products/services and versions that you think are affected
- the platform(s) the product uses
- the likely impact if the vulnerability’s exploited.
If there’s any other relevant information you can supply, such as the likely threat caused by the vulnerability, include that in your report too.
TIP: Don't use your access to the vendor's system to make changes to their data, and don't copy or delete anything, even if you think it might help mitigate the vulnerability. It's better if you don't access the system again once you've gathered details for your report. And, don't share the vulnerability or your access to the system with anyone else.
It should also go without saying that you must not use your access:
- to install malware in their system
- to cause a denial-of-service attack, or
- as an opportunity for social engineering.
How to communicate the vulnerability
It’s important to keep the information you have secure. You’ll need to use PGP encryption — or some other secure channel — to send a vulnerability report to the vendor.
If the vendor has a PGP key, you should be able to get it from a public key server, like pgp.mit.edu. Before you send the email, you should verify the fingerprint of the PGP key through a different channel. For example, if you received a copy of the vendor’s PGP key by email, you can check it against the PGP fingerprint that’s posted on their website. You can find a vendor’s PGP fingerprint on:
- their security.txt file
- their website
- your vendor contact.
Alternatively, you can send your report by email in an encrypted zip file using a strong algorithm. Share the password for it by phone or SMS — don’t send the password by email as well.
TIP: CERT NZ can help you communicate with a vendor whose systems are affected, if:
- you don’t want to contact the vendor directly yourself — for example, if you want to report a vulnerability anonymously
- you don’t have any success contacting the vendor yourself.
We act as a conduit of information only — we won’t investigate or verify your report ourselves. Instead, we’ll attempt to pass the report on to the relevant vendor on your behalf. This is known as coordinated disclosure.
After you’ve reported a vulnerability
Fixing a vulnerability can take time. Once you’ve shared details of a vulnerability with an vendor, you may need to prepare for a wait before hearing anything back.
Don’t release details of the vulnerability publicly to prompt a response. If you feel the vendor isn’t taking your report seriously, or doesn’t respond to you within a few weeks, contact us. We can work with you and the vendor to ensure you:
- get a response to your report
- know what the vendor plans to do to resolve the issue
- understand best practice for how to publish the information when there’s no response from the vendor.