In April we published a case study on a scan we ran against the Meta for Magento 2 Business Extension -- the official integration Meta ships for Facebook Pixel events, Conversion API calls, and product catalog syncing on Magento stores. 658 files, 18 findings, three of them Critical. We notified Meta's security team at [email protected] before that post went up.
Part One: The March findings, five months on
Three Critical findings, in short -- full technical detail is in the original post: a Meta OAuth access token rendered directly into the page DOM; a race condition in event-deduplication logic our analysis estimated causes 10–20% duplicate ad-attribution events under load; a mass-assignment vulnerability on Magento's core configuration store with no allowlist and no CSRF protection.
We went back to the source this week rather than go from memory. The repository is github.com/magento/meta-for-magento2 -- it lives in Adobe's Magento organization, not a Meta-branded one, though the code is Meta's own integration and the credentials at risk are Meta's. Its most recent commit is October 1, 2025. That predates our March scan. It predates our report. As of today, it's been over a year since the last commit landed on this repository at all, and the files behind the March findings are unchanged under that same commit.
To be precise about what we know and don't: silence from a security inbox doesn't always mean nobody looked -- a mitigation could exist somewhere outside the code we can see. What we can verify, and what anyone can verify themselves from the public commit history, is that the source hasn't changed since before we reported anything.
Part Two: This week's rescan, two new Critical findings
We run scans against public repositories on a rolling basis. This one came back with two findings we hadn't seen in March, both Critical, both distinct from the three above.
A webhook-processing endpoint in the extension's API configuration grants anonymous access -- no token, no session, no credential of any kind required to reach it. We're not publishing the route, the file, or the request shape. That's the whole point of reporting it first.
A static API credential is committed directly to the default configuration and returned as-is by the code that reads it -- the same class of finding as March's OAuth token, in a different file. We're withholding the literal value and its exact location for the same reason as above.
We reported both of these to Meta today, through their current bug bounty program, rather than the [email protected] address we used in March -- that inbox is no longer the address Meta's own published security contact points to. We'll publish full technical detail on these two the same way we did with the March findings: after Meta has had a real window to respond, whatever the outcome.
Why we're saying any of this now
This isn't about naming and shaming for its own sake. It's about the gap between "we take security seriously" and what a public commit log actually shows. Meta for Magento 2 is a widely installed extension, maintained by two large, well-resourced companies, handling live credentials and live ad spend, and it's now sitting on five known Critical findings across two reports with a code history that hasn't moved in over a year. That gap -- between trusted-by-default and actually reviewed, actually fixed -- is exactly what Ghost Architect exists to surface.
We'll keep checking back on all five. If something changes, on either report, we'll say so here.
See what a triage pass finds in your own codebase.
Install Ghost Open in under a minute. Point it at any local folder, GitHub repo, or zip file. See your Critical and High findings in under 10 minutes.
Install Ghost Open Free → Read the Original Report ↓