Ignoring vulnerability reports is a stupid gamble.

Deleting the message does not fix the bug

Someone takes the time to report a vulnerability in your website. They explain the problem, provide enough evidence to investigate, and try to reach the right person. Your response is silence.

If that same weakness is later exploited, surprise is a poor incident-response strategy. Ignoring a credible warning is a stupid gamble with your customers’ data and your own business.

That is the decision I want to call out: receiving useful evidence and choosing not to investigate it.

From the founder: yes, it gets frustrating

I have reported vulnerabilities across multiple websites. Some of those reports have received no response. Finding the issue, documenting it carefully and trying to get someone to listen takes time. Silence after that work is frustrating.

I want owners to take these warnings seriously while there is still an opportunity to investigate and fix the problem. A short acknowledgement and an assigned person would already be a better start.

This article keeps those organizations anonymous. I am not publishing their unresolved findings or claiming that a particular ignored report caused a later breach. A lack of response also does not tell me what an owner has done internally. It tells me the reporting conversation has stalled.

An unanswered report is not a resolved report

Imagine a report showing that one signed-in customer can read another customer’s private records. That is a generic example, not an exposed target or an instruction to attack one.

Closing the email does not change that permission check. Neither does pointing at the website’s professional design, HTTPS certificate, coding assistant or installed security product. The relevant question is whether the server enforces the boundary the report says is missing.

A report gives you something concrete to examine. Until someone validates or disproves it, you have an unresolved claim about your system. Treating that uncertainty as reassurance is poor judgment.

Investigate the evidence before dismissing it

Reports can be incomplete, duplicated or wrong. Scanners can produce noise. An unsolicited message can also contain an unsafe attachment or an exaggerated claim. Review the message safely; do not run an unknown script just because it arrived under a security heading.

Give credible evidence a route to someone who can assess it. Ask which asset is affected, what behavior was observed, what access was required and what impact is supported. Arrange any further validation within explicit authorization and agreed boundaries.

OWASP’s vulnerability disclosure guidance describes receiving reports and communicating with researchers. Build a process that gets a report to an accountable person instead of letting it disappear between support, development and management.

A useful response has an owner and a next step

First, acknowledge receipt through the reporting channel. Give the researcher a reference and explain who is handling the report. That acknowledgement is not a promise that every claim is valid or that a reward is due.

Next, have an authorized person validate the evidence safely, preferably using controlled accounts or a suitable test environment. Assess impact and urgency. If the claim is unsupported, explain what could not be reproduced and what information would help.

For a confirmed finding, assign responsibility for the fix, communicate a realistic next update and consider appropriate containment while remediation is prepared. Retest the relevant behavior after the change. Record what passed, what remains open and the limits of that retest.

Keep the conversation moving even when the answer is “we are still investigating.” A realistic update is more useful than an empty promise followed by silence.

Make yourself reachable before you need the warning

Give researchers a monitored contact channel and clear reporting instructions. Tell them how to share sensitive evidence privately and what testing your policy permits. A public contact address is not blanket permission to test your systems.

For websites, RFC 9116 defines security.txt, including a contact field and a location under /.well-known/security.txt. Keep the contact information current. Publishing a file only helps if someone handles the reports it brings in.

Payment discussions and vulnerability triage need separate decisions. Reward arrangements should be explicit. Evidence of an urgent issue should reach the authorized owner without disclosure being used as payment pressure.

Take the warning seriously while you can act on it

My frustration is with preventable inaction. A credible vulnerability report deserves a review, an accountable person and an outcome. If it is valid, fix the cause and verify the change. If it is wrong, explain the result.

At VEYRSEC, the aim is to make findings useful: agreed scope, clear evidence, practical remediation and honest retest results. That applies to AI-built websites, PHP applications and other web stacks.

You can read our testing methodology, see the shape of a sample security report, or request a scoped initial check. Deal with the warning while you still have a chance to choose the next step.