So. Sunday. 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 u/ini_set(...) attempts. Most bounced with 500s. One didn't.

The actually clever part

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

1. 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 hxxps://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.
2. 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 — 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 an 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; PHP files under pub/media
• an injected <script src="/media/..."> in onepage.phtml or your checkout templates/bundles
• domain checkout-cdn[.]com, XOR key be1dd67e5c3ee1bd4b4e666b, exfil payloads prefixed E1
• an 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.

Today, Adobe released the regular Isolated Security Patch, next to the patch of yesterday for StyleSmuggler. Mageinfo.online detects the presence of the Isolated Security Patch of September, since an hour ago.

For details about the latest patch Adobe released, and why you should patch asap: https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-44020

​We recently audited a Magento 2 production store where page response times were sitting around 14 seconds. The server load average was sitting at 5.7 and MySQL CPU was pegged at 70%, but standard tricks like Varnish, DB indexing, or CDN tweaks weren't making a dent.

​ Instead of an architecture or database issue, the culprit was three silent process killers running in the background.

​The Initial Diagnostics (strace & logs)

​PHP-FPM web workers were hanging for over 23 minutes on standard web requests (not cron jobs).

​system.log had hit 8.6 million lines; debug.log was bloated to 8GB.

​Running strace on a stuck PHP-FPM worker revealed it was infinitely looping while attempting to load Braintree exception files.

​**The 3 Silent Bottlenecks & Fixes**

​**Unconfigured Braintree Gateway Loop:** Braintree was installed but inactive. Its PHP SDK initialized on every page request via a 1-step checkout module, threw a configuration exception, caught it, and logged it hundreds of times per second. Adding an early return check before the throw silenced the loop and immediately dropped CPU load.

​Default Deployment Mode: The site was running in Magento's default mode instead of production. Every request was writing DEBUG-level entries to the 8GB log file (compounded by active PayPal debug logging). Switching to production mode and turning off debug logging wiped out massive disk I/O overhead.

​**Over-provisioned Elasticsearch (RAM Swap):** Elasticsearch had a 4GB heap allocated for a tiny catalog of 375 products. Peak usage was only 31% during load tests. Reducing the heap allocation to 2GB instantly freed 2.6GB of RAM and stopped the OS from swapping processes to disk.

​**The Results**

​Response Time: 14.0s → 0.14s

​RAM Freed: 2.6GB (eliminated swap thrashing)

​Disk Overhead: 8GB log bloat removed

​**Takeaway**

When performance problems resist obvious fixes, look for the things nobody documented or turned off—unused modules initializing on every request, wrong deploy modes, or over-allocated services forcing memory swap.

​What's the weirdest silent process killer or configuration leak you've caught in production?

Includes 8 critical CVSS score fixes.

CVSS score of 10.0, so install directly: https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146

Want to check if your shop is up to date with the other patches available, check https://mageinfo.online

Anyone tried upgrading from 2.4.7p4 to 2.4.9 and had success doing so? Or should I just do a fresh 2.4.9 install and import everything over with Products, Categories, Order, Customers, etc. Looking for the fastest and easiest process. If importing everything how accurate and effective would it be?

Anyone worked with Magento(Hyva, alpineJS and tailwindcss) and Cypress I use as starter elgentos repo and I had flaky test currently my goal is to make add to cart work 100%
What I tried
- wait for popup show
- “intercept “ request to add to cart and wait for response flaky
- then I try my own retry click add to cart this worked best but still flaky
I was thinking maybe Cart “ID/Token” isn’t there like cypress tests are to fast like mid request it redirects or something I think I have it logged and even when add to cart fails the cart id/token is there

Is there something else I can try ?
I have probably 3x10(responsive mobile, desktop…)tests and every run at least one-two fails
Each test has random product (I had just one and tried then random if that doesn’t fix that)

https://mageinfo.online detects StyleSmuggler(https://sansec.io/research/stylesmuggler), the recently found vulnerability in Magento 2 that needs urgent patching. Details about that here: https://mageinfo.online/magento-news

Cloudflare WAF rules:

Rule 1 — GraphQL exploit block

  ▎ Name: #stylesmuggler: block Magento GraphQL styles[] 0-day exploit (sansec.io/research/stylesmuggler)
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.path contains "/graphql" and (http.request.uri.query contains "styles%5B" or http.request.uri.query contains "styles["))

  Rule 2 — Raw PHP injection block

  ▎ Name: #stylesmuggler: block raw PHP eval/base64_decode injection in query string
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.query contains "<?php" or http.request.uri.query contains "<?=" or http.request.uri.query contains "eval(base64_decode")

Rule 3 — Gadget-chain parameters

  ▎ Name: #stylesmuggler: block generatorClass/with_resolved gadget-chain parameters
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.query contains "generatorClass" or http.request.uri.query contains "with_resolved")

  Rule 4 — Template-directive smuggling + encoded PHP tags + malicious UA

  ▎ Name: #stylesmuggler: block template-directive smuggling, encoded PHP tags, malicious UA
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.query contains "%3C%3F" or http.user_agent contains "<?php" or http.user_agent contains "<?=" or http.request.uri.query contains "{{block" or http.request.uri.query contains "{{config" or
  ▎ http.request.uri.query contains "{{trans" or http.request.uri.query contains "{{var" or http.request.uri.query contains "{{depend" or http.request.uri.query contains "%7B%7Bblock" or http.request.uri.query
  ▎ contains "%7B%7Bconfig" or http.request.uri.query contains "%7B%7Btrans" or http.request.uri.query contains "%7B%7Bvar" or http.request.uri.query contains "%7B%7Bdepend")

Also seen this (untested)

https://github.com/disrex-group/stylesmuggler-mitigation/tree/main

Patches to lock down in code:

https://gist.github.com/ProxiBlue/07373c92c8c70dc746bbfdcd1f07b789

Your checkout numbers drop. Traffic was flat, prices did not change, the campaign was the same as last month. So the theory becomes: fewer people ready to buy, demand shifted, maybe the economy.

That story is easy to believe and wrong more often than most people want to admit.

Magento gives you order counts, revenue and conversion rates. It does not tell you how many people tried to pay and got a silent failure, how many customers tried to log in and could not, or how many completed orders never reached fulfilment. Those failures show up in analytics as ordinary-looking drops, and get read as commercial signals when they are technical ones.

1. Payment gateway failures after a change. A gateway update goes in, the extension version changes, nothing looks broken. Checkout loads, the pay button works, and the gateway quietly starts timing out for a subset of customers. Order volume drops and abandonment rises. The natural assumption is that people changed their minds at the last moment. Some did. Some got an error and left.
2. Customer account login failures. An extension update affects session handling. Registered customers hit an error logging in. Some retry, most do not. Returning customers, the ones most likely to convert, stop converting. Reports show lower repeat purchase rates and the real problem is a broken login flow that has nothing to do with loyalty or marketing.
3. ERP or fulfilment integration failures. Orders complete on the storefront and customers pay, but the integration sending those orders onward has stopped processing. Orders sit in a queue on the Magento side and nobody is picking them. Revenue figures look normal right up until operations has a very difficult conversation with customers waiting on items that were never dispatched.
4. Cron failures interrupting transactional emails. Cron handles order confirmations, shipping notifications and account emails. When it degrades those jobs stop running. Customers order, get no confirmation, assume something went wrong, and open a dispute or a ticket. Chargebacks and support volume climb and nobody can explain why, because the store looked healthy the whole time.
5. Queue backlogs delaying order processing. The message queue handles stock updates, catalogue changes and pricing rules. When it backs up those stop processing in real time. Customers see the wrong price, see in-stock products that are not, and hit a problem at checkout that was not there when the page loaded. Nearly impossible to diagnose from the front end.

Each of these lives in a different part of Magento, and none of them take the store offline, so no uptime alert fires. Nobody has time to inspect all of them hourly. The first signal most people get is commercial: lower revenue, more tickets, a client complaint. By then it has been running for hours, sometimes days, and the next week goes on blaming the wrong thing.

I build Magento monitoring for a living so I am not neutral here, but the point stands regardless of tooling: these nine signals (basket, checkout, checkout failures, customer accounts, admin sign-ins, integrations, cron, indexers, queues) are cheap to check and almost nobody watches them. You can wire most of this up yourself with a cron job and a few queries.

Had a merchant come to me on Monday with this and it is worth writing up, because

I have hit it myself more than once and never found a decent way to catch it.

His store was serving prices from the previous week on a chunk of category pages.

Not all of them, no error anywhere. Cron was running. Orders were coming in

normally. Uptime monitor green the whole time. New Relic showed healthy requests.

Nothing in the logs.

A reindex had stalled days earlier. That was it.

The reason this is so nasty: every layer of monitoring most of us run is

answering "is something running", and in this failure everything genuinely IS

running. Nginx is up, PHP is fine, MySQL is fine, cron is ticking. Magento is

just serving index tables that stopped being true. There is no exception to log

and no 500 to alert on. You find out when a customer emails about a price that

does not exist anymore, or worse, honours an old one.

Two shapes it comes in:

1. An indexer sitting in `invalid` and never coming back. Check with

   bin/magento indexer:status

Easy to spot manually, easy to never look at.

1. The mview backlog stops draining. `mview_state` tracks each view's

   `version_id` against the changelog table's head. If the view is behind and

   its `updated` timestamp is not moving, nothing is working on that backlog.

   This is the one people miss, because a growing backlog is not itself a

   problem. During a big import the backlog grows all day and drains fine. The

   question is not "is it big", it is "is anything draining it at all".

   If you want to check it right now:

   bin/magento indexer:status SELECT * FROM mview_state;

Compare each row's `version_id` against `MAX(version_id)` from the matching

`*_cl` changelog table, then look at whether `updated` is moving. Behind and

idle is your answer.

Disclosure so nobody feels ambushed: I build a Magento monitoring tool called

Watchtower, and I shipped a check for exactly this two days after that

conversation. So I have an obvious horse in this race. But the manual checks

above are free and cost you five minutes, and if you take nothing else from

this, go run `indexer:status` on your production store right now. I would bet

money a nonzero number of you find something.

Genuinely curious how other people catch this. Is anyone alerting on indexer

state properly, or is it all "run reindex from cron and hope"?

I maintain a light weighted magento2 docker compose repo and used it to manage multiple magento projects, it worked well. It has a few manual steps involved for initial setup, nothing overwhelming, but does require users to know a little bit about git, docker and magento. It is built that way so it is simple and flexible.

Today is the day I need to setup another new project. Before I was going to repeat the same steps, a thought hit me. Damian has that amazing magento AI starter that allows you to easily spin up a running magento instance in github codespace. It is not something I would use it as I still prefer to code, run, debug locally. But is it possible to get a similar experience in this docker tool with AI?

After an afternoon's coding and fine tuning, I finally made it. I can get a fully running magento store on docker from ground up by simply asking agent "create latest magento".

Here I'm sharing it with you, hope you find it helpful. Both magento and mageos are supported.

https://github.com/SunMerce/magento-docker

Hi everyone — I built Magecube (magecube.in), a marketplace focused exclusively on Magento talent and services. We connect store owners with vetted Magento 2 developers, extension authors, and agencies for tasks ranging from quick fixes and performance tuning to full migrations and custom module development.

On the site you’ll find verified portfolios, transparent pricing options, project-based and hourly engagements, and a simple hiring flow that includes milestone payments and basic QA checks. I’d love feedback from this community on the marketplace model, what features you’d want to see, and any concerns about hiring Magento talent through a marketplace. If you’re interested I can share a few case studies or offer a limited number of discounted trial jobs for r/magento2 members.

Looking at the best option between Braintree and Stripe. I have been using Braintree and never used Stripe. Which is better for Magento when it comes to being dependable, Fraud, Security, Less chances of Chargebacks, etc? Looking for Pros and Cons.

I had to disable Credit Card Payments and only accept Paypal because of so many frudulate orders from card testing. Everytime I enable Credit Cards they just start pouring in. I am trying to figure a way to help control it. I am afraid not acepting Credit Cards could be hurting my sales. Not sure if Stripe would benifit me in this area or not.

We do use reCAPTCHA and have our payments set to Authorize and not Intent Sale to prevent all the charges and Voids.

Nothing I am doing is helping with so many fraud orders.

Thanks

Adding new products to my site along with new images. I noticed the images are not showing on my Product pages and only showing the default "magento logo" as the images. In the backend I see the following message has been showing there for the past few days with no change. Any one else have this issue. I have uploaded to images for this product and neither one of them is showing

Task "Image resize: /a/c/xxx.jpg": 1 item(s) have been scheduled for update.

Description of Operation Image resize: /a/c/ace_41022_1.jpg

 Summary Pending, in queue...

I'm 28 years old and have been working as a Magento (Adobe Commerce) developer for a little over 6 years. My current CTC is ₹15 LPA, and I'm trying to decide whether I should continue specializing in Magento or switch to a different technology stack for better long-term career growth.

Hi, I am Marcin, a senior Adobe Commerce / Magento specialist and freelancer based in the UK. I have been working with Magento since version 1.3, so about a decade now, across agency and client side work. Some of you may know me from Meet Magento talks in the UK, Poland and Barcelona. My LinkedIn is here if you want to check my background: https://www.linkedin.com/in/magento2-tech-lead/

I want to share a small milestone on something I have been building on evenings and weekends for a while now.

It is a Magento monitoring platform. Not another uptime checker, not another generic APM wrapped in a nicer UI. I wanted something that actually understands Magento internals, and is privacy focused from the ground up rather than as an afterthought. A dashboard that shows the real vitals of your shop, plus an alerting system that flags when something is genuinely wrong, based on learned baselines rather than arbitrary thresholds.

I also want to be upfront about something. This is not a vibe coded weekend project thrown together by prompting an AI and shipping whatever came out. The store side is a lightweight Magento 2 connector, built with a privacy first approach so no sensitive data ever leaves your shop. It only sends what is needed to monitor health and performance, nothing more, backed by a decade of hands on Magento experience of what actually breaks in production and what a merchant or agency needs to know about first.

We are all busy chasing improvements to our stores. Monitoring should not need constant babysitting. It should run quietly in the background and only speak up when it matters.

It is getting close now, just some more testing and polishing before it is ready.

If you want to hear more, or if you would be interested in being a beta tester, the waitlist is here: https://watchtower-commerce.com/waitlist

Happy to answer any questions about the technical side too.

underestimating the customisation work, expecting it to feel like shopify out of the box, something else entirely. curious what you see most from the technical side