Wellstar & Cone Health Pixel Lawsuit Settlements: A Defender's Guide to Eliminating Tracker-Based PHI Leakage

Wellstar Health System and Moses H. Cone Memorial Hospital Operating Corporation (Cone Health) have agreed to settlements resolving class action lawsuits alleging that third-party tracking technologies — commonly referred to as pixels — embedded on their websites and patient-facing properties transmitted patient information to advertising platforms without authorization. These cases are part of a sustained wave of litigation and regulatory enforcement against healthcare providers that deployed marketing analytics tags (Meta Pixel, Google Analytics, and similar) on authenticated patient portals, appointment schedulers, and symptom-checker pages where protected health information (PHI) flows through the URL, page title, or form data.

This is not a theoretical risk. The HHS Office for Civil Rights (OCR) has issued guidance stating that regulated entities generally may not use tracking technologies in a manner that results in impermissible disclosures of PHI to tracking vendors, and the FTC has pursued healthcare-adjacent entities for similar disclosures. Plaintiffs' firms are now actively scanning hospital websites for tracker presence and using those findings as the basis for class action claims. If you operate a healthcare web property and have not inventoried every third-party script executing on authenticated pages, you are carrying unquantified legal, regulatory, and reputational exposure right now.

This post covers how pixel-based PHI leakage actually works at the wire level, how to hunt for it in your telemetry, and how to remediate and govern third-party scripts so this doesn't recur.

Technical Analysis: How Tracking Pixels Exfiltrate PHI

Affected environment: Any healthcare web property — patient portals, appointment scheduling flows, provider search, telehealth landing pages, symptom checkers, billing/payment pages — that loads third-party marketing or analytics JavaScript.

The mechanism. A tracking pixel is typically a 1x1 image request or a JavaScript snippet (e.g., connect.facebook.net/en_US/fbevents.js) loaded in the page. Once loaded, the vendor's script has first-party execution context on your domain. Critically:

1. URL and page metadata leakage. When a patient views portal.example.com/appointments/oncology/dr-smith, the pixel fires a PageView event to the vendor's collection endpoint (for Meta: www.facebook.com/tr/). The full URL, referrer, page title, and the patient's IP address ride along in that request. An IP address plus a URL indicating a specific condition or provider is identifiable health information under OCR's analysis.

2. Form and event data leakage. Marketing teams routinely configure custom events (Schedule, SubmitApplication, CompleteRegistration) that capture form fields. On unauthenticated marketing pages this may be defensible; on authenticated portal pages it is not. Strings containing names, email addresses, appointment types, and even free-text symptom entries have been observed in ev and cd[...] parameters of tracker payloads.

3. Identity correlation. Cookies such as _fbp and _fbc persist a pseudonymous identifier that lets the vendor link portal activity to a real advertising profile. That linkage is the core of the plaintiffs' claims in the Wellstar and Cone Health matters and in the dozens of parallel suits filed since 2023.

Why this defeats traditional controls: These requests are outbound HTTPS from the patient's browser, not from your servers. Your WAF sees nothing suspicious. Your DLP sees nothing at the perimeter. The exfiltration happens inside a legitimate TLS session to a legitimate destination, initiated by code your own marketing team deployed. The only places you can reliably observe it are (a) the page source itself, (b) endpoint/browser network telemetry from managed devices, and (c) proxy logs for staff-accessed portals.

Enforcement status: This is active, ongoing litigation and regulatory scrutiny as of 2026, not a historical footnote. OCR's tracking-technology guidance remains in force, the FTC continues enforcement actions against health data sharing with advertisers, and plaintiffs' firms run automated crawlers against hospital web properties to identify new defendants. No CVE applies — the vulnerability is architectural and governance-based.

Detection & Response

Because the leakage executes client-side, detection focuses on two surfaces: (1) auditing your web properties for tracker code, and (2) hunting for beacon traffic from managed endpoints that access your own portal (useful for scoping exposure and validating that removal actually worked).

Sigma Rules

---
title: Outbound Connection to Meta Pixel Collection Endpoint from Clinical Systems
id: 3f8a1c92-5d4e-4b7a-9c1f-2e6d8a0b3f51
status: experimental
description: Detects network connections to Meta Pixel collection endpoints (facebook.com/tr/ or connect.facebook.net) originating from systems that should not be initiating advertising telemetry, such as clinical workstations, portal infrastructure, or VDI used for patient-facing workflows. Useful for scoping tracker exposure on managed devices.
references:
  - https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html
  - https://www.hipaajournal.com/wellstar-health-system-cone-health-pixel-lawsuit-settlements/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.exfiltration
  - attack.t1041
logsource:
  category: network_connection
  product: windows
detection:
  selection_destination:
    DestinationHostname|contains:
      - 'connect.facebook.net'
      - 'graph.facebook.com'
  selection_path:
    DestinationHostname|endswith:
      - '.facebook.com'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
  condition: selection_destination and not filter_browsers
falsepositives:
  - Non-browser applications with embedded web views (Teams, Outlook) loading shared content
  - Marketing department workstations legitimately managing ad campaigns
level: medium
---
title: Tracker Beacon Query String Indicating Health Context in Web Proxy Logs
id: 7b2e9d41-8a3f-4c6d-b5e2-1a9c4f7d0e83
status: experimental
description: Detects requests to advertising pixel endpoints whose URL or referrer parameters reference the organization's patient portal, scheduling, or telehealth paths. Tuning required - replace the example portal path fragments with your actual portal hostnames and URL paths.
references:
  - https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html
  - https://www.hipaajournal.com/wellstar-health-system-cone-health-pixel-lawsuit-settlements/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.collection
  - attack.t1074
logsource:
  category: proxy
detection:
  selection_tracker:
    c-uri|contains:
      - 'facebook.com/tr?'
      - 'google-analytics.com/g/collect'
      - 'analytics.google.com/g/collect'
  selection_health_context:
    c-referrer|contains:
      - 'mychart'
      - 'patient-portal'
      - 'portal.'
      - 'appointments'
      - 'schedule'
      - 'telehealth'
      - 'symptom'
  condition: selection_tracker and selection_health_context
falsepositives:
  - Patient browsing the public marketing site with an appointment CTA before authenticating
  - Generic '/schedule' pages on unauthenticated marketing properties (still worth reviewing)
level: high

KQL — Microsoft Sentinel / Defender

Use this to scope how much beacon traffic to tracker collection endpoints your managed estate is generating in the context of your own portal domains. Replace the portal domain fragments with your actual properties.

let Lookback = 14d;
let TrackerHosts = dynamic(["connect.facebook.net", "graph.facebook.com", "analytics.google.com", "google-analytics.com", "snap.licdn.com", "bat.bing.com", "sc-static.net", "analytics.tiktok.com"]);
let PortalContext = dynamic(["mychart", "patient-portal", "portal.", "telehealth", "appointments", "symptom"]);
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where RemoteUrl in~ (TrackerHosts)
| join kind=leftouter (
    DeviceEvents
    | where TimeGenerated > ago(Lookback)
    | where ActionType == "BrowserLaunchedToOpenUrl" or AdditionalFields has "url"
    | extend PageUrl = tostring(parse_json(AdditionalFields).Url)
    | where PageUrl has_any (PortalContext)
    | project DeviceId, PageUrl, PageTime=TimeGenerated
) on DeviceId
| where isnotempty(PageUrl) or InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","firefox.exe")
| summarize Connections=count(), DistinctDevices=dcount(DeviceId), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by RemoteUrl, InitiatingProcessFileName, DeviceName
| order by Connections desc;
// Companion: inventory beacon volume per tracker vendor for the remediation evidence trail
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DestinationHostName has_any ("facebook.com", "google-analytics.com", "analytics.google.com")
| summarize Hits=count(), Users=dcount(SourceUserID) by DestinationHostName, RequestURL
| order by Hits desc;

Velociraptor VQL

This artifact hunts managed endpoints for active connections to known tracker collection hosts — useful during a remediation validation sweep to confirm beacons stopped after tag removal.

-- Hunt for established connections to known advertising/tracker collection endpoints
-- Run during post-remediation validation of portal tag removal
LET tracker_hosts = ('facebook.com', 'fbcdn.net', 'google-analytics.com', 'analytics.google.com', 'bat.bing.com', 'snap.licdn.com', 'tiktok.com')

SELECT Pid, Name AS Process, Family, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
  AND Raddr.Port = 443
  AND (
    Name =~ 'chrome|msedge|firefox'
  )
LET enriched = SELECT *, lookup_dns(ip=RemoteIP) AS RemoteHost FROM netstat()
SELECT Process, RemoteIP, RemoteHost, LocalPort
FROM enriched
WHERE RemoteHost =~ 'facebook|google-analytics|analytics\\.google|bat\\.bing|tiktok'

Remediation Script

Run this against your web roots and CMS content stores to inventory tracker tags, then validate removal. It scans for the most common healthcare-litigation-referenced trackers and exports a CSV evidence trail for your compliance team.

# Audit web roots for third-party tracking tags - healthcare PHI leakage remediation
# Run on each web server / against exported CMS content. Produces CSV evidence for compliance.
$SearchRoots = @("C:\inetpub\wwwroot", "D:\Sites")   # Adjust to your web roots
$OutputCsv   = "C:\Temp\tracker-audit-$(Get-Date -Format 'yyyyMMdd').csv"

$TrackerPatterns = @(
    'connect\.facebook\.net',
    'fbevents\.js',
    'fbq\(',
    'facebook\.com/tr',
    'googletagmanager\.com',
    'google-analytics\.com',
    'gtag\(',
    'bat\.bing\.com',
    'snap\.licdn\.com',
    'analytics\.tiktok\.com',
    'sc-static\.net'
)

$results = foreach ($root in $SearchRoots) {
    if (Test-Path $root) {
        Get-ChildItem -Path $root -Recurse -Include *.html,*.htm,*.aspx,*.cshtml,*.js,*.php,*.jsp -ErrorAction SilentlyContinue |
            Select-String -Pattern ($TrackerPatterns -join '|') -AllMatches |
            ForEach-Object {
                [PSCustomObject]@{
                    File       = $_.Path
                    Line       = $_.LineNumber
                    PatternHit = ($_.Matches.Value -join '; ')
                    Snippet    = $_.Line.Trim().Substring(0, [Math]::Min(200, $_.Line.Trim().Length))
                    Host       = $env:COMPUTERNAME
                }
            }
    }
}

$results | Export-Csv -Path $OutputCsv -NoTypeInformation
Write-Host "[+] $($results.Count) tracker references found across $($SearchRoots -join ', ')"
Write-Host "[+] Evidence exported to $OutputCsv"

# Cross-check: which pages are authenticated portal pages? Flag highest-risk hits.
$PortalIndicators = 'mychart|patient|portal|appointment|schedule|telehealth|symptom|billing|payment'
$highRisk = $results | Where-Object { $_.File -match $PortalIndicators }
if ($highRisk) {
    Write-Host "[!] $($highRisk.Count) HIGH-RISK hits on portal/authenticated-context paths:" -ForegroundColor Red
    $highRisk | Format-Table File, Line, PatternHit -AutoSize
}

For Linux-hosted properties:

#!/bin/bash
# Scan web roots for tracker tags and export findings
ROOTS="/var/www /srv/www"
OUT="tracker-audit-$(date +%Y%m%d).csv"
echo "file,line,match" > "$OUT"
for root in $ROOTS; do
  [ -d "$root" ] || continue
  grep -rniE 'connect\.facebook\.net|fbevents\.js|fbq\(|facebook\.com/tr|googletagmanager\.com|google-analytics\.com|gtag\(|bat\.bing\.com|snap\.licdn\.com|analytics\.tiktok\.com' \
    --include='*.html' --include='*.htm' --include='*.php' --include='*.js' --include='*.jsp' "$root" \
  | awk -F: '{printf "%s,%s,\"%s\"\n", $1, $2, substr($0, index($0,$3), 120)}' >> "$OUT"
done
echo "[+] Findings: $(( $(wc -l < "$OUT") - 1 )) rows in $OUT"
# Flag hits on portal-context paths
 grep -iE 'mychart|patient|portal|appointment|schedule|telehealth|symptom|billing' "$OUT" && echo "[!] HIGH-RISK portal-context hits above"

Remediation

There is no patch for this — the fix is governance plus engineering. Prioritize in this order:

1. Immediate: strip trackers from authenticated pages. Remove all third-party marketing tags (Meta Pixel/fbevents.js, GA4 measurement, LinkedIn Insight Tag, TikTok Pixel, Bing UET) from every authenticated page of the patient portal, appointment scheduler, telehealth platform, and billing flows. If marketing insists on funnel analytics, use server-side, first-party collection with a signed BAA — or accept aggregate, de-identified metrics only.

2. Segment tag manager containers by risk zone. Create a separate Google Tag Manager (or equivalent) container for authenticated portal properties with an allowlist of approved tags enforced by change control. Any new tag on the portal container requires privacy officer and security sign-off. Marketing's container stays on the public marketing site only.

3. Deploy a restrictive Content Security Policy on portal pages. script-src and connect-src should enumerate only first-party and explicitly approved origins. CSP in Content-Security-Policy-Report-Only mode first gives you a free inventory of everything currently beaconing out — send reports to your SIEM.

4. Scrub URLs of health context. Appointment and search pages should never encode condition, specialty, or provider identity in the URL path or query string where third-party scripts (and referer leakage to any outbound resource) can capture it. Use opaque identifiers; render context client-side.

5. Engage legal and compliance on exposure scope. Given the Wellstar and Cone Health outcomes, quantify your historical exposure: which trackers were present on which authenticated pages, for what date range, and what data categories may have been disclosed. Preserve evidence before you make changes — remediation spoliation is a real litigation risk. Determine whether a breach risk assessment under HIPAA is warranted; OCR's position is that disclosure of PHI to a tracking vendor without a BAA is an impermissible disclosure.

6. Verify vendor contracts. If any analytics vendor touches pages where PHI could be present, you need a Business Associate Agreement in place. Meta and Google will not sign BAAs for their advertising products — which settles the architecture question for you.

7. Continuous monitoring. Add the Sigma proxy rule and the KQL tracker-beacon hunt above to your standing detection library. Re-run the file-system audit script on every release cycle or CMS template change. Plaintiffs' firms are re-crawling hospital sites quarterly; you should be scanning yours monthly.

References: OCR Guidance on Online Tracking Technologies (hhs.gov), FTC Health Products Compliance Guidance, and the settlement reporting at The HIPAA Journal (source URL below).

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub