Internet Weather Report

On 12/17/2025, I received a “Verify your email address” message that appeared to be a legitimate Fedora Accounts verification email. The sender authenticated cleanly (SPF pass, DKIM pass, DMARC pass) and originated from Fedora infrastructure (fas@fedoraproject.org, via bastion.fedoraproject.org).

But the HTML body contained a cryptocurrency-themed phishing payload that had nothing to do with Fedora.

What the email looked like (the tell)

The plain-text part was normal Fedora account verification copy:

• “This email address has been used to sign up for a Fedora Account…”

• An activation link on accounts.fedoraproject.org

• A 60-minute validity window

The HTML part, however, opened with attacker-controlled content:

• “✅ We have partnered with BINANCE… you have won a mining account with 1.3465 BTC…”

• A link out to graph.org (phish landing page)

• Instructions to “send proof” to “BINANCE online chat”

Then the email continued with the legitimate Fedora activation link and boilerplate.

That split (clean text/plain + poisoned text/html) is a classic way to slip past both automated scanning and a user’s quick glance, especially when the sender domain is reputable and authentication passes.

Why this is a problem

This is not “just another scam email.”

• The message was sent from a legitimate Fedora Project mail path and passed authentication checks.

• That gives the phish credibility and significantly increases the chance a recipient trusts it.

• It also means mailbox providers and filters are more likely to deliver it instead of quarantining it.

In other words: the threat actors didn’t spoof Fedora – they appear to have used Fedora Accounts as a delivery mechanism.

Likely abuse path (best inference from the artifact)

I don’t have Fedora’s backend logs, but based on the content structure, the most plausible scenario is:

• An attacker automated account registrations against the Fedora Accounts signup flow, inserting victim email addresses.

• During registration, they populated some user-controlled field that gets rendered into the HTML template (for example: “full name”, “display name”, or another profile/registration field).

• That field was either:

  • Rendered without proper output encoding, or

  • Allowed HTML/markup that was not sanitized, or

  • Passed through a formatter that produced HTML with unsafe content.

Result: Fedora’s mailer generated a verification email where the HTML portion contained attacker content, while the plain-text portion remained “normal,” increasing deliverability and deception.

That is consistent with the greeting line in the HTML being replaced with the phishing message, while the rest of the template remains intact.

What I did

• I reported the issue to Red Hat/Fedora security contacts (including Red Hat security).

• As of 12/18/2025, I did not receive a response.

• I also forwarded it to a Fedora contact address I could find (including Code of Conduct-related routing) as a “someone needs to see this” escalation, even if it’s not the perfect intake channel.

What Fedora should do (quick, practical fixes)

If you run a community identity/signup system, this is the defensive checklist I’d start with:

• Remove user-controlled fields from verification emails entirely, or strictly escape/encode them (no HTML allowed, ever).

• Ensure the HTML template uses safe output encoding for every variable.

• Make text/plain and text/html content-identical in meaning, so one can’t be “clean” while the other is weaponized.

• Add rate limiting, bot detection, and/or CAPTCHA on registration attempts.

• Add abuse detection for high-volume signups and unusual field content (URLs, crypto keywords, excessive Unicode symbols).

• Consider suppressing outbound verification email if the display-name/full-name contains suspicious patterns until reviewed.

What recipients should do

If you get a “verify your email” message you didn’t initiate:

• Do not click anything, even if SPF/DKIM/DMARC pass.

• Treat it as hostile when it contains:

  • crypto giveaways, “you won” language, or external links unrelated to the service

• If you want to be extra safe, go directly to the site by typing it manually (not via the email) and check whether an account exists or request password reset only if needed.

Indicators from this sample (sanitized)

• Legit sender: fas@fedoraproject.org

• Legit infra in headers: bastion02.fedoraproject.org / internal worker

• Payload link domain in HTML: graph.org

• Activation URL domain: accounts.fedoraproject.org (token redacted)

If you’re running an identity system: please assume attackers will use your reputation to deliver their scams. Email authentication tells you the message is really from the domain – it does not tell you the message is safe.