GiveWP donor email leak exposes donors across multiple sites

A bug in the GiveWP WordPress donations plugin exposed donor names, email addresses and donor IDs in page source for sites running versions up to 4.6.0. The issue was reported publicly on 29 July 2025 and fixed in 4.6.1 later that day. At least two high‑profile sites (Pi‑hole and The Corbett Report) confirmed exposure. Have I Been Pwned (HIBP) lists ~30k impacted Pi‑hole donor addresses. No card data was involved, but the incident creates immediate phishing and deliverability risks for organisations whose donor lists were scraped.

What happened

GiveWP introduced changes to its admin experience that inadvertently caused donor metadata intended for admin‑only use to be embedded in public page source. In practice, that meant anyone (or any bot) viewing source on affected donation pages could collect donor names, email addresses, and donor IDs. In some cases the leak bypassed the plugin’s “anonymous donation” setting.

GiveWP shipped a patch as version 4.6.1 and later published a mea culpa clarifying timelines and process fixes. The WordPress.org listing now shows 4.6.1 as the latest, with the changelog entry “Security: Addressed an issue with donor information visibility.”

Who is affected

• Sites running GiveWP ≤ 4.6.0 prior to updating to 4.6.1. WordPress.org lists 100,000+ active installs.
• Donors who used forms on affected sites during the vulnerable period (and possibly historically if forms rendered donor data from older records). Pi‑hole confirmed names and emails; GiveWP says donor IDs could also appear.
• Not affected: payment card data and billing details processed by Stripe/PayPal; the Pi‑hole software product itself.

Timeline (all dates 2025)

• Sun 27 Jul–Mon 28 Jul: First donor spam reports emerge; Pi‑hole begins investigating.
• Tue 29 Jul: Public GitHub issue filed describing donor emails in page source; GiveWP ships 4.6.1 the same day.
• Wed 30 Jul: Pi‑hole publishes a detailed post‑mortem, criticising the lag between fix and user notice.
• Thu 31 Jul: HIBP lists a Pi‑hole breach entry (~30k addresses added). The Corbett Report posts its own disclosure, saying other sites were similarly exposed.
• Fri 1 Aug: GiveWP posts a fuller incident write‑up, apologises for tone, and outlines security/communications process changes.

Why email professionals should care

1) Targeted phishing. Donor lists are a goldmine: names + emails + donor context enable high‑credibility spoofs (e.g. “receipt update”, “matching gift challenge”, refund lures). Expect an uptick in credential and card‑harvesting attempts against your donors.

2) Deliverability knock‑on effects. When compromised donor emails get hammered by spam, your legitimate campaigns risk more bulk foldering and complaint spikes. Poor incident comms can also trigger unsubscribes and list churn.

3) Brand trust and regulatory exposure. Even if your card processors insulated payment data, email addresses are personal data. Depending on jurisdiction, you may owe notices and should be prepared to evidence timely mitigation.

4) Supply‑chain reminder. This is not a one‑off: GiveWP has patched serious issues in prior years (SQLi in 2023; RCE class in 2024). Plugin risk is email risk when it touches signup/donation flows.

Immediate playbook for affected orgs

Contain & verify

1. Update to 4.6.1 or later everywhere. Clear caches and CDN edge content to ensure patched markup is live. If you run staging, verify the page source is clean.
2. Audit exposure: pull web server logs for donation pages; check for spikes in GET/HEAD with common bot UAs and referrers around 23–31 July. If you have WAF logs (Cloudflare, etc.), search for automated scraping patterns.
3. Check “anonymous donations” logic: if you used it, validate no donor names are rendered in source after the fix.

Protect donors 4) Send a transparent notice to donors who may be impacted (segment by form/site and likely exposure window). Keep it plain, apologetic, and specific about what was and wasn’t exposed. Avoid embedded links where possible; provide a short, memorable vanity URL to a security update page on your domain. 5) Publish a standing advisory page (no gating) explaining the incident, how to verify legitimate emails from you (sending domains, DKIM/DMARC alignment, link domains), and how to report suspicious messages. 6) Harden spoofing defenses: ensure DMARC at p=quarantine/reject on your primary and donation‑related subdomains; align return‑path domains; make sure all vendors used for donation receipts or marketing are properly authenticated. 7) Adjust engagement strategy: pause non‑essential campaigns to the potentially exposed segment for a few days; resume with lower‑friction content, no aggressive CTAs, and consistent branding.

Internal hygiene 8) Rotate any API keys or webhooks exposed to WordPress via GiveWP add‑ons; review admin user roles created by the plugin. 9) Document the timeline, decisions, and evidence for regulators/boards. 10) Monitor abuse mailboxes and complaint feedback loops for 2–4 weeks; tune suppression rules for addresses showing sudden, sustained complaint or bounce activity.

Preventing a repeat

• Treat plugins as third‑party processors. Maintain a risk register for any component touching donor/CRM data; require vendor SLAs for security advisories.
• Pre‑prod gates for auto‑updates. Route plugin updates through staging with content diff checks (including public HTML markup) before production.
• Security headers & robots. While not a fix, a conservative X‑Robots‑Tag and robots.txt policy on donation pages can reduce indexation of sensitive HTML and slow mass scraping.
• Anonymous‑by‑default UX. If donor privacy is core to your mission, design forms that never render personal data client‑side. Assume any client‑side object can be scraped.

Open questions

• Dwell time: When did the regression first ship? (Changelog shows 4.6.0 on 23 July; first public reports 28–29 July.)
• Blast radius: Aside from Pi‑hole and Corbett Report, how many sites saw scraping before patching? WordPress.org shows 100k+ active installs.
• Notification quality: Will GiveWP or marketplaces provide direct, in‑dashboard security advisories with clear severity and impact language?

Disclosure: This article focuses on email‑relevant impacts. Cardholder data was not exposed by this bug. Organisations should still consult legal counsel regarding notification duties in their jurisdictions.