Rewrite a technical document for a non-technical reader

You write the public security blog for a WordPress plugin company. The dev team
just filed a technical advisory for an internal audience, and you need a version for
non-technical store owners who just want to know if they're affected and what to do.

TECHNICAL ADVISORY: [
"CVE-2026-XXXXX: Unauthenticated SQL injection in the export function of Contact
Form Pro versions 4.0 through 4.6, via the 'filter' parameter in
/wp-admin/admin-ajax.php?action=cfp_export. CVSS 8.6 (High). Allows an attacker to
read arbitrary database contents including hashed user passwords, no authentication
required. Patched in 4.7, released today."]
AUDIENCE: [non-technical site owners using this plugin, some may not update plugins
regularly]
GOAL: [a blog post/email telling affected users what happened and what to do,
without causing panic or downplaying real risk]

Work through this before drafting:
1. Put the single required action in the first two sentences: update to version 4.7
   now. A worried reader scans for "what do I do" before they read any explanation,
   so don't bury the fix behind three paragraphs of technical background.
2. Translate the mechanism in plain language without losing accuracy: "SQL
   injection" becomes something like "a flaw that could let an attacker pull
   information straight out of your site's database without needing a password,"
   not a vaguer "a security issue was found."
3. Edge case: calibrate the tone to the actual severity (CVSS 8.6, high, no
   authentication required, meaning literally anyone could exploit it, not just a
   logged-in attacker). This is genuinely serious, so don't soften it into "a minor
   bug was fixed" to avoid alarming readers, that would be inaccurate and could
   leave affected sites unpatched. At the same time, don't invent worse consequences
   than the advisory states (it doesn't mention site takeover, so don't imply one).
4. Keep every technical fact exactly as stated (CVE number, affected version range
   4.0-4.6, patched version 4.7, what data was exposed) even while simplifying the
   explanation around them, precision on these details matters for anyone checking
   if they're affected.
5. Add a short "how do I know if I'm affected" check (what version number to look
   for and where to find it in the dashboard) since the audience may not know their
   current plugin version offhand.

Draft the full post: headline, the required action up front, plain-language
explanation of the issue, affected-version check, and a closing reassurance once
updated.

Replace the bracketed advisory, audience, and goal above with your own.