Grey hat hacker
A grey hat hacker looks for flaws in systems they have no permission to touch, but without intent to profit or cause harm, and usually tells the owner what they found. What separates them from a professional is not technique or intent: it is that there is no written authorisation behind it.
What a grey hat is
In security, a grey hat is someone who looks for vulnerabilities in systems that are not theirs and that nobody has given them permission to touch, but who is not there to steal or to break anything. When they find something, they usually tell the owner.
The name comes from sitting between the other two hats: they act neither with the intent of a criminal attacker nor under the engagement of a hired professional. That middle position is about intent, not method: the tools and the steps are the ones either of the other two would use.
Which is why the label depends on the situation rather than on the person. The same hacker can be a white hat on Tuesday, with a signed contract, and a grey hat on Saturday, poking at a system nobody asked them to look at.
What matters to an organisation is not the label but what to do when one turns up. Somebody writing to say they have found a flaw in your website is a situation that happens, and most organisations have not decided in advance who answers.
The three hats
| White hat | Grey hat | Black hat | |
|---|---|---|---|
| Authorisation | Prior and in writing | None | None |
| Intent | Improve the client’s security | Improve the security of someone who did not ask | Personal gain or damage |
| On finding the flaw | Reports it through the agreed channel | Usually reports it, sometimes in public | Exploits or sells it |
| Scope | Defined and bounded | Whatever they decide | Whatever they can reach |
| Legal position | Covered by the contract | Exposed, even with no damage done | Criminal |
| What the organisation gets | A reproducible report and an agreed remediation | A tip-off of variable quality, with no guarantee of silence | An incident |
The row that decides everything is the first one. Prior authorisation is not paperwork: it is what turns exactly the same technical activity into a service or into a crime. A penetration test and an unauthorised intrusion can look very similar in a server log; what separates them is a document.
And the last row is the one most often skipped in the comparison. A grey hat gives you a piece of news; a professional gives you a reproducible finding, its scope, its severity and a remediation path, and undertakes not to talk about it.
Responsible disclosure: what grey hats tend to get right
The practice that gives this figure its better half a name is responsible disclosure: whoever finds the flaw tells the system owner first, gives them a window to fix it, and only then goes public, if they go public at all.
It is a convention rather than an obligation, and that is where it gets uncomfortable for the organisation on the receiving end: the window is set by the person reporting. An organisation that takes months to reply ends up learning about the flaw at the same time as everybody else.
The mature answer is to publish a channel for security reports and a commitment to respond. It costs nothing, and it turns an awkward email into a process: the reporter knows where to write, and the organisation knows who answers.
Vulnerability reward programmes are the funded version of the same idea. They add explicit permission and rules of engagement, and with those in place the participating hacker stops being a grey hat: they are authorised.
Why good intentions are not authorisation
Accessing someone else’s system without permission is a criminal offence, and what the person does next does not change that part. Telling the owner can weigh heavily on how the matter ends, but it does not undo the access.
There is also a practical problem that has nothing to do with the law. A grey hat tests against production, with no agreed window, nobody warned and nobody watching. If something falls over, it falls over for real, and the team responding has no way of knowing whether it is handling a test or an intrusion.
For the organisation that translates into something concrete: you cannot tell a grey hat from an attacker while it is happening. What the detection team sees is the same activity, which is why the tip-off always arrives after the scare.
The professional version of this activity exists precisely to remove both of those. A web penetration test or an external penetration test runs with an agreed scope, an agreed window, a named point of contact and a confidentiality undertaking.
A worked example
A hacker independently finds a flaw in a company’s software that would allow access to customer data.
Rather than using it, they write to the company anonymously, explaining the problem and how to fix it.
The email arrives at a generic address. Nobody owns replying to that, so the message spends several weeks circulating between departments while the flaw stays open.
The outcome is the worst of both worlds: the organisation can no longer claim it did not know, the flaw is still there, and the person who reported it has no reason left to stay quiet. All of it is avoided by publishing a security contact and assigning an owner.
Common mistakes by the organisation receiving the report
Answering with legal before answering with engineering. Threatening the reporter is the fastest way to turn a private tip-off into a publication, and it does not fix the flaw.
Having nowhere to write to. With no published security address the report comes in through sales, through support or through LinkedIn, and gets lost. It is the cheapest item on this list to fix.
Fixing the instance rather than the class. A grey hat shows you one example, almost never the extent. If they report an identifier that can be tampered with, the question is not whether that one is fixed but how many other places in the application share the pattern.
Mistaking a report for an assessment. An email with a screenshot says nothing about what else is exposed. Knowing your full attack surface is separate work, and it is work you can actually commission.
What to do when a grey hat contacts you
Acknowledge receipt the same day, even if you have nothing to say yet. Most disputes of this kind start with silence rather than with disagreement.
Reproduce the flaw before arguing about it, and do it somewhere you can watch. A report without reproducible steps is not actionable, and asking for them politely is a reasonable request.
Treat it as an incident until you know it is not one. If the flaw allowed access to data, the important question is not who reported it but whether anyone used it earlier: that is incident response, and it is answered in the logs.
Then close the class rather than the case. It is the natural moment to measure the real exposure of that application against a defined scope, which is something a one-off tip-off will never give you.
FAQ
Is a grey hat a good hacker or a bad one? The label cannot answer that. They act without permission, which is the bad one’s trait, and they report instead of profiting, which is the good one’s. Hence the grey.
Can I hire a grey hat? The moment you hire them they stop being one. What you are hiring is a hacker with a contract, a scope and a confidentiality undertaking, which is exactly the definition of a white hat.
How is this different from a Red Team? A Red Team exercise simulates a real adversary end to end, including the part about not warning the defenders, but with the organisation’s leadership authorising it in writing and knowing when it starts and when it stops.
Is it grey hat or gray hat? Both spellings are in use; grey is the British form and the one this site uses. In Spanish you will also see hacker de sombrero gris, although most of the sector writes the term in English.