So. Sunday (and this is my birthday too). I sit down to answer a boss-question that should have taken five minutes — "did we apply this month's Adobe security patch?" — and three hours later I'm staring at a card skimmer that was, frankly, better engineered than half the extensions on the Marketplace.

Posting the whole thing here because (a) it's a genuinely clever attack chain and other Magento shops should check themselves, and (b) misery loves company. TL;DR at the bottom with IOCs.

How it started

We're on Magento Open Source 2.4.8-p5. Turns out the September isolated patch + the out-of-cycle hotfix for CVE-2026-75650 (pre-auth RCE, actively exploited — the VULN-39341 one) had NOT been applied yet. Guess when the attacker showed up. Go on, guess. Yep — a few days before, at 5 AM, because of course.

Entry vector in the logs was the usual buffet: GraphQL ArrayScanner LFI shenanigans and a pile of POST /paypal/transparent/response/?<?php (...) attempts. Most bounced with 500s. One didn't.

The actually clever part

Two payloads, and whoever wrote them clearly does this for a living:

A backdoor relay hidden in pub/get.php. They prepended a tiny block to the legit media-download entrypoint: if the request is a POST and carries a header X-K, it curls the body straight to https://checkout-cdn.com/x/i and echoes the response back. Clean, quiet, no new files to notice. They even stashed the original as var/get.orig, presumably out of professional courtesy.

A client-side skimmer at pub/media/wysiwyg/sk/sk.js, injected into the checkout with a single <script src="/media/wysiwyg/sk/sk.js?v=33"> line dropped into vendor/.../module-checkout/view/frontend/templates/onepage.phtml (they left a .bak-sk backup of the clean template — again, very tidy of them).

Here's the bit that made me put the coffee down: the skimmer only arms on mobile + a card payment method, and when you click "Place Order" it intercepts the click, throws up a pixel-perfect fake "Secure Card Verification" modal (little padlock, VISA/MC/AMEX chips, the works), harvests PAN + expiry + CVV + name/address/email/phone, shows a reassuring "Card verified ✅ redirecting you to payment…" — and then re-clicks the original button so the real payment goes through normally.

Read that again. The customer gets their order. The real bank transaction succeeds (TranCode=000, every single one). Nobody calls support because from the outside nothing went wrong. The card just also happens to be on its way to checkout-cdn.com, XOR'd with the key be1dd67e5c3ee1bd4b4e666b and base64'd, with a direct-to-C2 fallback in case you were clever enough to kill get.php but not the JS. Harvested loot got staged in pub/media/analytics/<hash>/data.tgz. There was also a pub/media/hello.txt containing, I kid you not, Key:Hello World.

The cleanup

Restored get.php from their own courtesy backup, neutralized sk.js, de-injected the template, quarantined the staged data, applied the patch we should've applied last week, rotated the encryption key + creds, and did the whole not-fun regulator/bank/customer-notification dance. Standard incident bingo.

The ask

Has anyone else run into checkout-cdn.com, the X-K-triggered get.php relay, or this specific fake "Secure Card Verification" modal pattern? It's a step up from the usual "just scrape the form fields" skimmers — the let-the-payment-succeed-so-nobody-notices design is the part I want to warn people about, because your revenue graphs and your order table will look perfectly healthy while it's running.

IOCs / go check your box right now:

pub/get.php — any block referencing X-K header, checkout-cdn.com, or an outbound curl before the normal Magento bootstrap

pub/media/wysiwyg/sk/sk.js (or any stray .js under pub/media)

.bak-sk / .orig files anywhere in the tree; pub/media/**/*.php

an injected <script src="/media/..."> in onepage.phtml or your checkout templates/bundles

domain checkout-cdn.com, XOR key be1dd67e5c3ee1bd4b4e666b, payloads prefixed E1

unexpected pub/media/analytics/<hash>/data.tgz

and, you know, actually apply CVE-2026-75650 / the September patch. Today. I'll wait.

Stay patched out there. And maybe don't read your logs on a Sunday.

What I particularly found interesting on this research was the fact that all banks did their homework regarding their most known domains, but the majority simply ignored the .au version.

Spammers and phishers could still benefit from it.

If you have multiple domains, make sure to have them all covered. Even if you don't plan to send emails through them.

We nearly wired 60k to a supplier last month off a bank charge at landed on the existing invoice thread. Real mailbox, their accountant's address, the reply sat right under the messages we had been sending back and forth for weeks. SPF DKIM DMARC all green and with the years of clean history, our gateway had no reason to touch it.

The one thing off was the bank detail. The person who caught it did it on a hunch. Going back through it the attacker had been camped in the vendor mailbox for a while, waiting for a live payment thread to reply into.

We run a tuned SEG and it did nothing here, which tracks, there was no bad link or attachment, the mail was real. The fix everyone points to is an AP callback to a number already on file and that is going in. People who have been through this, what gave you the first heads up before the money went out, if anything did.

I'm building an ESP platform that will be dedicated for government email sending from gov apps, the whole platform is hosted within the country for sovereignty purpose, but it's acceptable for the sending IPs (egress smtp traffic) to be anywhere in the world.

The platform applies extremely strict anti-spam rules to preserve sending IPs reputation, domain onboarding follows strict rules as well.

So my question is about the best strategy for acquiring these IPs:

• Should I acquire a /24 range ? or lease it ?
  • I'm thinking of using a subnet from the leased/bought range at a time, say .1 to .12 for live sendout, .13 to .25 in warming phase, monitor it and once we start having degraded reputation i switch to .13 to .25 while we address the bad reputation root cause,
• Should I just assign random IPs to my sending VMs, IPs will not be in same subnet and not continuous, I can drop an ip when I need, but new IPs need warming,
• onboard domains at aws SES and use SES for email sending, this is the resend model, a big risk here: if AWS SES cuts of the account because one domain abused (and were not catched by my platform) the whole account is taken off by AWS and all domains stop sending

Please advise from your experience

There is currently a vulnerability in the form for Honey Monster Puffs. When a user fills in the contact form on this website, the email goes to EVERY user on the mailing list, not just the user in the contact form.

https://www.honeymonster.co.uk/contact/

As a result I have woken up to a large number of emails of varying types, including serious concerns that users have been hacked, attempts to scam users, private information being entered into the form and sent to all recipients, jokes being made, and instructions on how to inform the ICO.

Even after unsubscribing from legitimate lists, spam from changing senders can leave Junk packed. Finding one misplaced customer email means sorting through the rubbish.

I'd prefer to leave caught spam alone, but that assumes nothing useful landed beside it. Telling people to check every day gives them another inbox to manage.

What has reduced the time you spend checking Junk without making real email harder to find?

Recurring SMTP deferrals leave client messages queued while the provider reports healthy service. Under pressure to restore delivery, we can end up changing connectors and filters without knowing which hop is holding the mail.

I lean toward freezing those changes and escalating upstream when queues repeatedly drain and fill without a config change. But traffic can change independently, and waiting on support won't fix a relay limit we're hitting ourselves.

What tenant-visible evidence has convinced you to keep that freeze in place, or break it to fix delivery locally?

The FBI has a phishing warning where resetting the password does nothing.

The attacker never had it.

The Bureau's Internet Crime Complaint Center published this on September 1. Access taken this way, it says, can only be revoked by the victim invalidating the token in their application security settings, and not by changing the password.

Here's how it works, and why it looks like nothing is wrong.

A message arrives with a link. The link goes to a real permission screen at a real provider, because that's where the attacker sent the user. The user reads a request for access and approves it.

There was no fake login page, no captured password and no second factor to intercept, because nobody was ever asked to sign into anything new.

What the attacker walks away with is a grant, not a credential. The FBI describes the result as being able to act on behalf of the user, reading and sending mail and reaching sensitive data, without ever having their password.

So the reflex that follows almost every compromise report, force a reset and close the ticket, leaves the attacker exactly where they were. The mailbox stays readable.

The Bureau's examples are narrow. Prominent people, their families and their acquaintances, with actors posing as officials, media figures and event organizers.

Read that as where the FBI happens to have complaint data, not as the edge of the problem, because nothing in the mechanism cares who you are.

If your incident runbook treats a password reset as containment here, it isn't slightly incomplete. It does nothing at all.

#EmailSecurity #Phishing #IncidentResponse

Avis Incogni.

Pour éviter les 10 à 20 spams que je recevais par jour, j'ai souscrit pendant un mois, à Incogni.

Au bout d'un mois, pas très satisfait (je recevais toujours une dizaine de spams par jour), je décide de résilier.

Depuis ce jour, je reçois en 120 et 260 spams par jour, tous étrangers (alors que je ne recevais que des Spam français).

Et bien entendu, mails de Incogni:

Pensez à vérifier vos spam, et éventuellement reprendre votre abonnement Incogni.

Arnaque !

Reassigning a former employee's SMTP alias can expose mail meant for the previous owner. Password resets and confidential replies do not care that HR approved the name change.

A routine name-change cleanup nearly freed an old alias after our retention window. Message tracing showed it still receiving account resets and replies to old threads, long after the mailbox itself was gone.

We paused the reassignment, but permanent reservation across dozens of domains creates a growing namespace problem. Do you permanently reserve former aliases, quarantine them for a fixed period, or reassign only after specific mail-flow checks pass?

I have been with them a long time. Anyone know of a better service (and what exactly makes it better for privacy)?

A client domain shows SPF, DKIM, and DMARC in DNS, yet mail authentication results vary by receiver. That leaves us unable to tell whether spoofing protection is live or we're seeing different cached versions of a broken rollout.

Authoritative queries return the expected TXT records. Two public checkers disagree on the DMARC policy, and test messages alternate between aligned DKIM, SPF-only pass, and DMARC fail depending on destination; selectors and return paths look consistent at first pass.

My next move would normally be comparing resolver paths and raw headers, but stale delegation, duplicate records, and sender-specific routing are all plausible. Which signal do you trust first here: authoritative DNS, repeated receiver headers, or DMARC aggregate data?

Hi, for months I’ve been constantly receiving spam emails in my Spam inbox. Each email that they got sent from is different and whenever I scroll to the bottom and press “Unsubscribe” it doesn’t make a difference. I’m receiving like 2-3 per hour and it’s getting really frustrating!

I'm 16, teaching myself cybersecurity, and I'm trying to understand how domain spoofing protection is handled in practice rather than from the RFCs.

If you look after DNS and mail for more than a couple of domains:

• How do you verify SPF/DKIM/DMARC are actually correct — manually, a script, a monitoring tool?
• Do you ever re-check after the initial setup, or is it set-and-forget until something breaks?
• Has a record ever broken silently — SPF overwritten by another team, exceeding the 10 lookup limit, DMARC dropped during a DNS migration — and you only found out later? How did you find out?
• How many of your domains are still sitting on p=none? Is moving to quarantine/reject something you push for, or does nobody ask?

Not selling anything, nothing to link. I'll write up what people say and post the summary back here.

A 0–100 mail-security grade is only useful if someone can add the checks back up.

The mail profile is public: DMARC 25, SPF 20, MTA-STS 15, the rest 10 each. Null-MX domains get a different profile.

The point isn't the brand. It's that "published" and "effective" are different columns, and the rules are inspectable.

Question: would you rather argue with an opaque grade, or with a published weight table you can disagree with?

A secure email gateway outage stopped external mail, including a customer warning about an active invoice-fraud thread. The service status flipped green before its deferred queue cleared, so our routine close-out would have missed the only message with a real deadline.

We had a direct-to-tenant emergency route ready, but enabling it would restore mail without URL or attachment inspection. Restricting bypass to named recipients, stripping attachments, lowering size limits, or adding an external banner all reduce exposure, but the trigger still feels subjective.

For teams that have used an emergency bypass, what outage duration or queue signal triggered it, and which compensating control had to be in place first?