← Back to Cybersecurity News Center
Severity
HIGH
CVSS
7.5
Priority
0.625
×
Tip
Pick your view
Analyst for full detail, Executive for the short version, or Plain & Simple if you are not a tech person.
Analyst
Executive
Plain & Simple
Executive Summary
Threat actors exploited an HTML injection flaw in Robinhood's account onboarding pipeline to send phishing emails that originated from noreply@robinhood.com, passing all standard email authentication checks. Attackers precision-targeted victims using the 7 million email addresses stolen in Robinhood's 2021 data breach, making the campaign exceptionally credible to recipients. The business risk extends beyond Robinhood: any organization with unsanitized input fields in transactional email templates is potentially vulnerable to the same trusted-sender abuse pattern.
Plain & Simple
Here’s what you need to know.
No jargon. Just the basics.
👤
Are you affected?
Probably, if you have a Robinhood account or your email was in the 2021 Robinhood breach, you may have received or may receive a scam email that looks completely real.
🔓
What got out
Confirmed: email addresses from the 2021 Robinhood breach were used to target victims
Suspected: additional personal details may have been used to personalize messages, not confirmed
Confirmed: no new data breach at Robinhood has been announced in connection with this campaign
✅
Do this now
1 Do not click links in any email from Robinhood, go directly to the Robinhood app or website instead. 2 Turn on login alerts in your Robinhood account so you get notified of any sign-in you did not make. 3 If you got a suspicious Robinhood email, report it to Robinhood support and delete it.
👀
Watch for these
Emails from Robinhood asking you to verify your account or confirm a transaction you did not start.
Links in emails that look like Robinhood but take you to a different website when you hover over them.
Any login to your Robinhood account from a device or location you do not recognize.
🌱
Should you worry?
Your Robinhood password was not leaked in this incident. The danger is that scam emails look real enough to trick you into giving your password, so the risk goes away if you never click email links and always log in through the app.
Want more detail? Switch to the full analyst view →
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
HIGH
High severity — prioritize for investigation
Actor Attribution
HIGH
pompompurin (attributed to 2021 Robinhood breach and data sale; not confirmed for 2026 campaign), Unknown threat actor (April 2026 Robinhood phishing campaign)
TTP Sophistication
HIGH
8 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Robinhood trading platform (onboarding email pipeline, Device field input handling); Gmail users (dot-aliasing behavior exploited for account creation bypass)
Are You Exposed?
⚠
Your industry is targeted by pompompurin (attributed to 2021 Robinhood breach and data sale; not confirmed for 2026 campaign), Unknown threat actor (April 2026 Robinhood phishing campaign) → Heightened risk
⚠
You use products/services from Robinhood trading platform (onboarding email pipeline → Assess exposure
⚠
8 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Business Context
Phishing emails sent from a company's own verified domain are materially more effective than generic phishing — recipients have no standard signal to distrust them, and email security tools pass them cleanly. For Robinhood, the attack targeted users already victimized by the 2021 breach, compounding reputational damage and increasing regulatory scrutiny around breach data lifecycle. For any organization that discovers the same pattern in its own email pipeline, the exposure is both operational (customer account compromise, fraud liability) and regulatory (notification obligations under applicable data protection laws if customer data is accessed as a result).
You Are Affected If
Your platform accepts user-supplied input (device name, browser string, custom fields) that is rendered without sanitization inside transactional email templates
Your account creation or onboarding flow sends emails through your own authenticated sending domain without validating or encoding template variable content
Your email sending infrastructure does not rate-limit or flag high-volume registration attempts from dot-alias variants of the same canonical address
Your organization has experienced a prior data breach and the exposed email list has been circulated on threat actor forums — that dataset is a ready-made precision targeting list
Your email security stack relies on SPF/DKIM pass as a trust signal without secondary behavioral analysis of email body content
Board Talking Points
Attackers sent fraudulent emails that appeared to come from Robinhood's own verified address — standard email security tools saw nothing wrong because the emails were technically authentic.
Any organization that renders user-provided data inside transactional emails without sanitization faces the same risk; a code audit of email templates should be completed within two weeks.
Without that audit and fix, a single unsanitized input field is sufficient for an attacker to send phishing messages to your customers that carry your brand's full authentication credentials.
Technical Analysis
Attackers injected malicious HTML into an unsanitized Device field within Robinhood's account onboarding email template.
Because the injected content was rendered inside emails dispatched by Robinhood's own sending infrastructure, the resulting messages passed SPF and DKIM authentication - standard email authentication controls produced no alert signal.
No CVE has been publicly assigned.
Relevant weaknesses are CWE-79 (Improper Neutralization of Input During Web Page/Email Generation) and CWE-284 (Improper Access Control, unauthenticated abuse of the transactional email relay). MITRE ATT&CK coverage includes T1566.002 (Spearphishing Link), T1078 (Valid Accounts, trusted sending domain abuse), and T1589.002 /T1114 (breach data reuse for targeting). Gmail dot-aliasing (e.g., j.ohn.doe@gmail.com vs johndoe@gmail.com) was exploited to generate high volumes of account registrations from a limited set of real addresses, industrializing onboarding flow abuse. Robinhood remediated by removing the unsanitized Device field. No CVSS vector string or EPSS data has been published for this flaw. The 2021 breach dataset (7 million records) was attributed to pompompurin; the April 2026 phishing campaign operator remains unattributed.
Action Checklist IR ENRICHED
Triage Priority:
URGENT
Escalate immediately to legal and executive leadership if analysis confirms that injected emails were delivered to recipients whose addresses appear in your organization's prior breach disclosure records, as this constitutes a second-order harm to previously affected individuals and may trigger mandatory breach notification timelines under applicable state or federal law.
1
Step 1: Containment — Audit every user-supplied input field in transactional email templates; treat any unsanitized field as active risk pending remediation. Enforce allowlists for functionally constrained fields such as Device. Apply D3-UAP (User Account Permissions) to restrict which application components can write to email template variables. (Cite: NIST AC-3 / NIST AC-4 / CIS 4.6 / D3-UAP)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST SI-10 (Information Input Validation)
NIST SI-2 (Flaw Remediation)
CIS 4.2 (Establish and Maintain a Secure Configuration Process for Network Infrastructure)
Compensating Control
For a 2-person team without enterprise tooling: grep -rn --include='*.html' --include='*.mjml' --include='*.hbs' --include='*.jinja' '{{.*device\|.*user.agent\|.*metadata' ./email-templates/ to locate unescaped variable injection points in template files. Simultaneously pull your ESP (SendGrid, Mailgun, SES) template API and diff all template versions from the past 90 days using the provider's audit log export — most free-tier accounts retain this. Flag any template variable that renders a string value without a |escape or autoescape wrapper.
Preserve Evidence
Before touching templates, export and preserve: (1) your ESP's full template render logs or preview cache showing the exact rendered output of any onboarding/account-creation email sent within the past 30 days — these will show whether Device/User-Agent field content appeared literally in email body HTML; (2) your account registration database records for any signup where the Device or User-Agent field contains angle brackets (<, >), %3C/%3E URL-encoded equivalents, or HTML entity sequences (<, >) — these rows are direct evidence of injection attempts; (3) a static export of all current transactional email template source files with file hashes (sha256sum *.html > template_hashes_$(date +%Y%m%d).txt) before any remediation changes alter them.
2
Step 2: Detection — Enable logging of template variable values at email render time in your sending platform. Query SIEM and email gateway logs for outbound transactional emails where Device, User-Agent, or similar fields contain angle brackets, script tags, or URL-encoded equivalents (%3C, %3E). Alert on high-velocity account creation from Gmail addresses differing only by dot placement — these resolve to the same canonical address. (Cite: NIST AU-2 / NIST AU-3 / NIST AU-6 / CIS 8.2 / D3-LAM)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST AU-2 (Event Logging)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST SI-4 (System Monitoring)
NIST AU-12 (Audit Record Generation)
CIS 8.2 (Collect Audit Logs)
Compensating Control
Without a SIEM, run these queries directly against your ESP's log export (CSV/JSON) using jq or Python pandas: (1) jq '.[] | select(.subject | test("Welcome|Verify|Confirm")) | select(.body | test("<script|<img|<a href|javascript:"; "i"))' outbound_mail_log.json to find onboarding emails with injected tags; (2) sort -t@ -k1 registrations.csv | awk -F',' '{gsub(/\./,"",$2); print $2}' | sort | uniq -d to normalize Gmail dot-aliases and identify duplicate accounts targeting the same canonical inbox; (3) grep -P '[<>]|%3C|%3E|<|>|<|>' registration_db_export.csv | grep -i 'device\|user.agent' to isolate injection-bearing registration records. Cross-reference registration timestamps with your ESP's outbound send log to confirm whether injected content reached recipient inboxes.
Preserve Evidence
Preserve before analysis: (1) Your ESP's full outbound message log for all onboarding/account-creation sends over the past 90 days, including the raw MIME source of flagged messages — the raw MIME will show whether injected HTML rendered in the email body or was stripped; (2) Web application access logs (Apache/Nginx) for your registration endpoint, filtered on POST requests to /signup or /register, retaining the full request body or at minimum the User-Agent and any device metadata fields — look for payloads containing <script, <img src=x onerror=, or data: URI schemes; (3) Gmail dot-alias registration pattern: export all accounts with gmail.com addresses created in any burst period (>50 registrations/hour from gmail.com addresses) and normalize dots out of the local-part to identify how many map to the same canonical address, which reveals the scope of the bypass campaign against the Robinhood 2021 breach list.
3
Step 3: Eradication — Apply HTML entity output encoding to every user-controlled variable rendered in email body or headers. Enforce strict input validation and allowlisting at the point of ingestion, not only at render time. Disable or remove the unsanitized Device field from all email templates until encoding is confirmed. (Cite: NIST SI-4 [note: SI-4 is not in the provided KB; the closest available KB control is NIST AC-4 for information flow enforcement and CIS 7.1 for vulnerability management process] / NIST AC-4 / CIS 7.1 / CIS 7.2)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST SI-2 (Flaw Remediation)
NIST SI-10 (Information Input Validation)
NIST SI-7 (Software, Firmware, and Information Integrity)
CIS 7.2 (Establish and Maintain a Remediation Process)
CIS 7.4 (Perform Automated Application Patch Management)
Compensating Control
For teams without a WAF or enterprise input-validation library: (1) Implement Python's html.escape() or equivalent (PHP htmlspecialchars($var, ENT_QUOTES, 'UTF-8'), Node.js he.encode()) on every template variable before it is passed to the email rendering function — this is a code-level fix requiring no tooling budget; (2) For the Device field specifically, if values are expected to be OS/browser strings, enforce a server-side regex allowlist: ^(Windows|macOS|iOS|Android|Linux)[\w\s\.\-]{0,50}$ and reject or strip non-matching values before they touch the template engine; (3) Commit all sanitization changes with a signed git commit and tag the release (git tag -s eradication-htmlinject-YYYYMMDD) so you have a tamper-evident audit trail of when the fix was deployed, satisfying NIST AU-10 (Non-Repudiation) requirements without additional tooling.
Preserve Evidence
Before deploying the fix, capture: (1) A code diff export (git diff HEAD~30 -- '**/email*' '**/template*' '**/mailer*' > pre_fix_template_diff.patch) showing the exact lines where user-supplied variables were rendered without escaping — this is your root-cause evidence; (2) A sample of raw MIME exports from your ESP showing at least one confirmed injected email that passed DKIM/SPF intact, proving the authentication bypass mechanism worked via Robinhood's own signing infrastructure rather than domain spoofing; (3) Database rows where Device field content contains injection strings, exported with timestamps and associated account IDs, to determine whether the injected registrations were created by automated tooling (uniform timing intervals) or human operators (irregular timing), which informs threat actor attribution.
4
Step 4: Recovery — After encoding controls are deployed, submit test registrations containing HTML injection payloads and confirm rendered emails contain only escaped text. Verify SPF and DKIM records are intact and unmodified. Monitor transactional email bounce and complaint rates for post-remediation anomalies. Require MFA on all accounts with access to email template configuration or sending infrastructure. (Cite: NIST AU-6 / NIST AU-9 / CIS 6.3 / CIS 6.5 / D3-MFA / D3-CH)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST SI-6 (Security and Privacy Function Verification)
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST IR-4 (Incident Handling)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
For a 2-person team: (1) Regression test using a controlled registration with payload Device value of <script>alert(1)</script> and ><img src=x onerror=alert(2)> — receive the resulting onboarding email and view raw source to confirm the output renders as <script>alert(1)</script> and not executable HTML; (2) Query your DNS registrar or use dig TXT example.com to verify your SPF record and compare against a previously documented baseline hash — any modification to the SPF include chain or DKIM selector could indicate an attacker attempted to expand mail-sending authority; (3) Use MXToolbox (free) or mail-tester.com to send a post-fix test onboarding email and confirm DKIM=pass, SPF=pass, DMARC=pass with no alignment failures — screenshot and timestamp this result as evidence of restored integrity.
Preserve Evidence
Preserve before declaring recovery complete: (1) Side-by-side raw MIME captures of a pre-fix injected onboarding email (from ESP archive) and a post-fix test email with the same payload, demonstrating that escaping is now applied — this is your remediation proof artifact; (2) ESP bounce and complaint rate baseline for onboarding emails from the 30 days prior to the campaign, compared against rates during the campaign window — a spike in spam complaints against noreply@robinhood.com-originated messages during the attack period is forensic evidence of recipient harm; (3) A timestamped dig +dnssec TXT _dmarc.yourdomain.com && dig +dnssec TXT yourdomain.com output confirming DMARC policy, SPF record, and DKIM key selectors are unchanged from pre-incident configuration.
5
Step 5: Post-Incident — Expand the input sanitization audit across all transactional email pipelines: password reset, notification, invoice, and onboarding. Assess whether prior breach data (e.g., any historical data exposure at your organization) could supply a precision targeting list for a similar campaign; if so, treat affected users as elevated-risk recipients. Establish or update documented vulnerability management and remediation processes to include transactional email template review as a recurring control. (Cite: NIST AU-11 / NIST AC-2 / CIS 1.1 / CIS 5.1 / CIS 7.1 / CIS 7.2 / D3-LAM)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST SI-2 (Flaw Remediation)
NIST RA-3 (Risk Assessment)
NIST SI-10 (Information Input Validation)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 3.2 (Establish and Maintain a Data Inventory)
Compensating Control
For a 2-person team: (1) Build a transactional email input inventory in a spreadsheet: for each email type (password reset, invoice, notification, onboarding), list every template variable, its data source (user-submitted vs. system-generated), and whether it passes through an escape function — any user-submitted variable without a confirmed escape function is a finding; (2) Use semgrep with the community ruleset (semgrep --config=p/owasp-top-ten .) against your email rendering codebase to automatically flag unescaped template variables — free, runs locally, no telemetry required; (3) Cross-reference your user database against known breach datasets using Have I Been Pwned's domain search API (free for organization owners) to identify what percentage of your user base appears in prior breach compilations — this quantifies the precision-targeting risk specific to your organization, mirroring exactly how the Robinhood 2021 breach list was weaponized in this campaign.
Preserve Evidence
Capture for the post-incident lessons-learned record: (1) A complete inventory of all transactional email pipelines with variable-level sanitization status — this documents the full attack surface that existed, not just the one exploited field; (2) Historical registration records normalized to detect any Gmail dot-alias account clusters that were created before this campaign was detected, which may reveal an earlier reconnaissance or staging phase; (3) Any threat intelligence correlation between your known-exposed user email addresses (from prior breach events) and the accounts targeted or created during this campaign — if the same addresses appear in both sets, it confirms the attacker used a breach-derived targeting list, a finding that may trigger breach notification obligations under CCPA, GDPR, or state notification laws depending on jurisdiction and data classification.
Recovery Guidance
After deploying HTML entity encoding across all transactional email templates, run a minimum of 48 hours of post-fix monitoring on ESP complaint and bounce rates before closing the incident, as residual phishing emails already delivered to recipient inboxes may continue generating user confusion and credential submission for days beyond containment. Verify that all accounts created during the campaign window via Gmail dot-alias bypass are flagged for manual review and that any associated sessions or access tokens issued to those accounts are invalidated. Continue monitoring your registration endpoint for renewed injection attempts for at least 30 days post-fix, as threat actors who successfully exploited this vector are likely to probe for regressions or alternative unsanitized fields.
Key Forensic Artifacts
ESP raw MIME message archives for all onboarding emails sent during the campaign window — these preserve the rendered email body exactly as delivered, showing whether Device or User-Agent field content appeared as executable HTML and passed DKIM/SPF signing by noreply@robinhood.com (or your equivalent sending domain), confirming the authentication bypass mechanism
Web application registration endpoint logs (Apache/Nginx access logs or application-layer request logs) containing the full POST body or at minimum the Device and User-Agent field values submitted during account creation — injection strings (<script>, <img onerror=>, data: URIs) in these fields are direct evidence of attacker tooling and technique
Account registration database export filtered on accounts created in burst periods from gmail.com addresses, with dot-normalized local-parts — duplicate canonical addresses map the scope of the Gmail dot-alias bypass used to exhaust your per-address registration limits and evade deduplication controls
ESP delivery and complaint feedback loop (FBL) reports for the noreply sending address during the campaign window — spam complaint spikes against your own authenticated sending domain indicate recipients recognized the phishing content despite DKIM/SPF passing, and these reports establish victim harm for any regulatory notification analysis
Git or deployment history for the email template rendering codebase, specifically commits touching the Device, User-Agent, or metadata field handling functions — absence of escaping in the commit history establishes when the vulnerable code was introduced and how long the attack surface existed prior to exploitation
Detection Guidance
Detection for this campaign operates on two surfaces: outbound template integrity monitoring and inbound phishing recognition.
Outbound (email sender perspective): Per NIST AU-2 (Event Logging), define email template variable rendering as a loggable event type.
Per NIST AU-3 (Content of Audit Records), ensure log entries capture the raw variable value, template name, timestamp, and originating account.
Per CIS 8.2 (Collect Audit Logs), confirm logging is enabled across the transactional email sending platform — SendGrid, SES, Postmark, or equivalent. Alert on any template variable value matching patterns: literal angle brackets (), HTML tag fragments (script, img, a href), or URL-encoded equivalents (%3C, %3E, %22). Per NIST AU-6 (Audit Record Review, Analysis, and Reporting), review flagged records on a defined frequency; automated alerting is preferred over manual review for this signal type. Apply D3-LAM (Local Account Monitoring) logic to the account creation pipeline: correlate registration events by canonical email address (stripping Gmail dot variants) to detect high-frequency account creation from a single identity.
Inbound (receiving organization perspective): This campaign is specific to Robinhood infrastructure — emails originate from noreply@robinhood.com and pass SPF and DKIM. Standard email authentication controls produce no alert signal; do not rely on them as the detection mechanism. Detection must shift to link destination inspection: flag inbound emails from noreply@robinhood.com where embedded URLs do not resolve to robinhood.com properties. Apply D3-PBWSAM (Proxy-based Web Server Access Mediation) or D3-EBWSAM (Endpoint-based Web Server Access Mediation) to intercept and inspect link destinations before user interaction.
KB control gap note: NIST SI-3 (Malicious Code Protection) and SI-4 (System Monitoring) are directly relevant to this threat pattern but are not present in the provided KB reference data. If those controls are available in your organization's control library, apply them here. The citations above are limited strictly to controls verified in the KB.
Indicators of Compromise (1)
Export as
Splunk SPL
KQL
Elastic
Copy All (1)
1 domain
Type Value Enrichment Context Conf.
⌘ DOMAIN
noreply@robinhood.com (sending address)
VT
US
Legitimate Robinhood sending address abused via HTML injection in onboarding pipeline; not itself malicious but used as the authenticated sender for phishing messages
HIGH
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
MITRE ATT&CK Hunting Queries (2)
Sentinel rule: Phishing email delivery
KQL Query Preview
Read-only — detection query only
EmailEvents
| where Timestamp > ago(7d)
| where ThreatTypes has "Phish" or DetectionMethods has "Phish"
| summarize Attachments = make_set(AttachmentCount), Urls = make_set(UrlCount) by NetworkMessageId, Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, ThreatTypes
| sort by Timestamp desc
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Falcon API IOC Import Payload (1 indicators)
POST to /indicators/entities/iocs/v1 — Weak/benign indicators pre-filtered. Expiration set to 90 days.
Copy JSON
[
{
"type": "domain",
"value": "noreply@robinhood.com (sending address)",
"source": "SCC Threat Intel",
"description": "Legitimate Robinhood sending address abused via HTML injection in onboarding pipeline; not itself malicious but used as the authenticated sender for phishing messages",
"severity": "high",
"action": "detect",
"platforms": [
"windows",
"mac",
"linux"
],
"applied_globally": true,
"expiration": "2026-08-19T00:00:00Z"
}
]
Route 53 DNS — Malicious Domain Resolution
Query Preview
Read-only — detection query only
fields @timestamp, qname, srcaddr, rcode
| filter qname in ["noreply@robinhood.com (sending address)"]
| sort @timestamp desc
| limit 200
Compliance Framework Mappings
T1566.001
T1598
T1585.001
T1586.002
T1566.002
T1589.002
+2
AT-2
SC-7
SI-3
SI-4
SI-8
AC-2
+5
6.1
6.2
16.10
7.3
7.4
14.2
164.312(a)(1)
164.308(a)(5)(i)
164.308(a)(6)(ii)
MITRE ATT&CK Mapping
T1566.001
Spearphishing Attachment
initial-access
T1598
Phishing for Information
reconnaissance
T1585.001
Social Media Accounts
resource-development
T1586.002
Email Accounts
resource-development
T1114
Email Collection
collection
T1078
Valid Accounts
defense-evasion
Guidance Disclaimer
