Magento was not a random target.
Before I moved into offensive security I spent eight years building on it and leading Magento development teams, which meant I already knew where the complexity lived. What I wanted to know was how much of that complexity an AI research system could reason through on its own.
So we built one and pointed it at Adobe Commerce and Magento Open Source, including the B2B modules most enterprise merchants run on top. We gave it a month.
It produced 180 vulnerability reports. They went through both HackerOne and Intigriti, because Adobe migrated the program between platforms while the campaign was running. We rated 9 of them critical, 85 high, 49 medium and 37 low. Just over half came out high or critical.
- Critical 9 5%
- High 85 47%
- Medium 49 27%
- Low 37 21%
Just over half rated high or critical
Total AI inference spend for the month was roughly $1,200. So far, the bug bounty programs have paid roughly $20,000 for this research.
- Broken access control, IDOR, tenant isolation 78 reports 43%
- Stored XSS and active-content injection 41 reports 23%
- Auth, session, account takeover 17 reports 9%
- Business logic and financial abuse 13 reports 7%
- Information and secret disclosure 11 reports 6%
- SQL injection 8 reports 4%
- SSRF 5 reports 3%
- Race conditions 3 reports 2%
- Path traversal and unsafe file ops 2 reports 1%
- RCE and SSTI 2 reports 1%
180 reports submitted
Around 35% came back as duplicates
Around 60% of the reports have been accepted so far.
A duplicate means another researcher got there first. Same code, same path, same conclusion, arrived at independently.
That does not prove an attacker found the same bug. It proves something more useful. The path to discovery was reproducible. Multiple independent researchers, working separately with different methods, converged on the same weaknesses in the same codebase.
And there is no reason to assume that reproducibility stops at the edge of a coordinated disclosure program. The same source code is public. The same extensions are purchasable. The same documentation is online. Nothing about that pipeline is exclusive to people who file reports.
The part that makes this your problem, not Adobe’s
The usual reaction to platform research is that it belongs to the vendor. Adobe patches, you update, done.
That holds for core. It does not hold for what is actually running in your store.
A very large share of the Magento extension ecosystem is built by treating core as the reference implementation. Developers extend core classes, copy a block or controller and adapt it, reuse the same collection and filtering patterns, replicate the same rendering approach in an admin grid. That is not bad practice, it is how the platform was designed to be extended.
The consequence is that when a weakness exists in a core pattern, it propagates. Adobe ships a patch for its own file. The extension that copied that logic three years ago keeps running the unpatched version, in your store, indefinitely, because nobody upstream is responsible for it.
The vendor patch closes the vendor’s copy of the bug. Your copy is still there, in a paid extension, in a custom module a previous agency wrote, in the checkout adapter somebody added for a local payment provider.
Attackers can test your code too
Ecommerce security is still routinely reduced to patch cadence, PCI scope and infrastructure controls. Those matter, and none of them tell you whether the code running your checkout enforces authorization on every path that reaches it.
The threat model does not agree with that reduction.
Attacks on commerce platforms can be massive, automated sweeps against a known unpatched version. They can also be targeted, and targeting a store is not hard. Your third-party extensions announce themselves in static paths, asset bundles, response headers and public storefront markup. Those extensions can be bought, or pirated, or pulled from a repository. Once an attacker has the code, they are doing exactly what we did, with the same tools, without a disclosure policy and without a deadline.
The asymmetry is simple. Your attacker reads your code offline, at their own pace, with no rate limits and no WAF in the way. If nobody on your side has done that, they know your stack better than you do.
Patching is mandatory. It is also the floor, not the ceiling.
What the findings actually looked like
Two families accounted for two thirds of everything.
Authorization pinned to a transport. Magento reaches the same business operation through admin controllers, REST, GraphQL, the async bulk API, queue consumers, cron and imports. Authorization lives somewhere else entirely, in acl.xml, in webapi.xml resource declarations, in _isAllowed(), in a plugin bound through di.xml to exactly one adapter. So the question stops being whether an endpoint can be called, and becomes whether every road to that operation preserves the same actor, tenant, ownership and state assumptions. Over and over, it did not. A plugin wired to the synchronous path and missing from the async one. Store scope enforced in a modern resolver and absent from its legacy twin.
Low-trust data rendered in a high-trust browser. Almost none of the 41 were reflected payloads. They were values written by a customer, a B2B user or a restricted admin, persisted, carried across entities, and rendered days later inside an admin grid, a rule builder or an x-magento-init block. The attacker plants it and waits for someone with more privilege to open a routine screen.
The money bugs applied the same logic to state. Reward points, store credit, quotes, purchase orders, staged prices and refunds are state machines governed by rules spread across modules. One unit of credit must not fund two completed orders. An approval must stay required across every order-placement interface. A staged price must not become purchasable before its campaign starts. Each of those sentences turned into a report.
How we found them
The OliveX process is not a scanner, and not a single model with a long prompt. It is an orchestration of several models, each given a job it is actually good at.
That mix is deliberate, because the models are not interchangeable and neither are their prices. Opus 5 carried the hard reasoning and took roughly 90% of the $1,200 inference spend. Kimi K3, DeepSeek, GLM and GPT-5.6 Sol handled breadth, second opinions and the high-volume passes where paying flagship rates for every file makes no sense.
One pass builds the security model from the source, mapping ACL declarations, service contracts, plugins and every transport that reaches a given domain service. Another reads Adobe’s own documentation and release notes to establish what a control was supposed to do, which is how you tell a deliberate design decision from an omission. A third traces attacker-controlled values from source to sink across persistence and serialization boundaries, which is the part no scanner can do, because the input and the execution are days and three subsystems apart.
Then it builds the lab. Every hypothesis gets a disposable environment with separated attacker and victim identities, an allowed control and a denied control, and the exact state needed to prove or kill the theory in minutes instead of an afternoon.
Humans stay in the loop the whole way. They review every candidate finding, record the proof-of-concept videos that go to the program, and feed corrections back so the next pass over the same subsystem starts smarter than the last one.
The result that matters to a buyer is not that an AI with human in the loop produced 180 reports. It is that a month and $1,200 in inference spend bought an enormous amount of offensive attention on a large codebase, while humans decided what deserved to become a finding. That gate throws away most of the output. Suspicious code is not a finding. Reachable but not exploitable is not a finding. Raw HTML in a response is not a finding. Only a reproducible state change across a real trust boundary gets submitted, which is why a program receiving 180 reports from us is not receiving 1,800.
What to do about it this quarter
Four things, in this order.
- Build the authorization matrix. Roles, websites, resources, and every protocol that reaches them. Most teams find the gap while they are still filling in the grid, before anybody runs a single test.
- Move authorization into the domain services. Out of controllers, out of transport plugins, into the code that actually performs the operation. A rule enforced where the work happens cannot be bypassed by arriving through a different door.
- Add parity tests. REST, GraphQL, async bulk, cron and import should be provably equivalent on authorization, not equivalent by convention. Convention is what let them drift apart in the first place.
- Audit the extensions and the custom modules. Nobody upstream is patching them. That is where the core patterns you inherited went to hide.
Our findings ship as engineering artifacts with the trust boundary, the source-to-sink trace, a negative control and a reproducible state change. Most arrive as pull requests within 24 hours, because a finding that sits in a PDF for six weeks is a finding you paid for twice.
We already know what this platform looks like from the inside. The open question is whether anyone has looked at your version of it, the one with the extensions you bought and the code your agency wrote.
That is what we do.
One recommendation, even if you never hire us
Whoever reviews your store should not be the people who built it.
This is not a claim about anyone’s integrity, it is a claim about structure. When the agency that wrote your checkout is also the one auditing it, every finding is an invoice they have to justify and a decision they have to defend. That pressure does not need bad faith to bend a report. It bends on its own, through what gets called a finding, what gets called acceptable risk, and what quietly never makes it into the document. We see the result often enough that it stopped surprising us. Years of clean internal reviews, and then a list of real findings the first time somebody from outside opens the same code. Your agency can be excellent and this still holds.
Plenty of what gets sold as an ecommerce security audit is somebody pasting your URL into a scanner and forwarding the PDF with a logo on it.
You can tell, because every finding is something a tool can see without ever logging in. Take the two families that accounted for two thirds of our 180 reports and ask what a scanner would have done with them. The stored XSS enters through a customer field and executes days later inside an admin grid the scanner never authenticates into.
The authorization gaps exist only in the difference between two code paths that reach the same operation, so you have to know both exist before you can compare them. No tool that takes a URL as its only input knows your async endpoint skips a plugin your synchronous one enforces. It does not know there is a plugin.
You do not need to start with a full engagement. We can scope a short review against your storefront, your admin and the extensions you actually run, and come back with an honest read of where you stand. Real findings if there are real findings, and a plain answer if there are not. That is usually enough to know whether the longer conversation is worth having.
Results of Our Research in Numbers
- 180 vulnerability reports submitted.
- 9 critical, 85 high, 49 medium, 37 low.
- Approximately 35% duplicates.
- Approximately 60% of reports accepted so far.
- Approximately $20,000 paid in bounties so far.
- $1,200 in AI inference.
Contact us at olivex.io.
Damian Gambacorta is Founder & CEO of OliveX Security. Former Adobe Commerce certified developer and top-ranked HackerOne researcher in Argentina, with 1,200+ disclosures to companies including Apple, Microsoft, Meta, Visa and Disney.