Tell the client four things in plain words: what the issue is, whether their site is affected, what you have done or will do and by when, and what you need from them. Skip jargon, avoid blame, and send it before they read about it elsewhere.
Most clients do not want a lecture on severity scores. They want to know if their business is at risk and who is handling it.
A message structure that works
| Part | What to write | Example wording |
|---|---|---|
| Headline | The plain fact | "A plugin on your site has a published security problem." |
| Impact | Affected or not, and how you know | "Your site runs the affected version. We have no sign it was misused." |
| Action | What you did, with a date | "We updated it on staging today and will release tonight." |
| Ask | Anything needed from them | "Please check the booking form after the update." |
| Next step | When you will report back | "We will confirm tomorrow by noon." |
Only claim "no sign it was misused" if you actually checked logs and files. If you did not, say "we are checking".
Decide how urgent it is first
Urgency should come from facts, not fear. CISA maintains the Known Exploited Vulnerabilities catalog and says organisations should use it as an input to vulnerability prioritisation. If a flaw in your client's plugin appears there, it has been exploited in the wild, and you should treat it as same day work. If it is not listed, you still patch, but the time pressure is lower.
Also check whether the vulnerable feature is even enabled on this site. Some issues need a specific setting or role. Say so honestly, but do not use it as a reason to skip the update.
Words to avoid
- "Hacked", unless it is confirmed. Say "affected" or "exposed".
- "Nothing to worry about". Say what you checked instead.
- Version numbers without context. Add one sentence on what they mean.
What if no fix exists
Sometimes the plugin author has not released a fix. Give the client the options: remove the plugin, replace it, or disable the vulnerable feature, with the cost and the date for each. The WordPress handbook describes security as risk reduction, not elimination, so be candid that the choice reduces risk without removing it.
Keep a record
Log when you found out, when you told the client, what you did and when it was done. That log helps in a later review or a client conversation, and it is the kind of evidence a security questionnaire may ask for.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the check separates a vulnerability that exists from one that can be reached, which is the sentence the client most wants answered.
Safeguard's reachability analysis does this for dependencies in a project repository, and the free scan shows a sample report.
Quick check
Should I wait until the patch is done before telling the client?
No. Tell them early with a time for the next update. A short, early message builds more trust than a polished one that arrives late.
How do I know if a flaw is being exploited?
Check the CISA Known Exploited Vulnerabilities catalog and the plugin vendor's advisory, and review your own logs for suspicious requests.
Sources
Last reviewed: 19 October 2026.
