Putting AI to Work on SAP MDM: How Claude Helped Us Find and Report Real Vulnerabilities

There’s a lot of noise right now about what AI can and can’t do in offensive security. Plenty of demos, fewer real results. We decided to settle the question for ourselves with a concrete experiment: could a modern AI assistant meaningfully help us discover genuine, previously unknown vulnerabilities in a real SAP product, not a toy target, but a complex, poorly documented piece of the SAP landscape?

We picked SAP Master Data Management (MDM) 7.1 as the subject, worked through it with Claude as a research partner, and the answer turned out to be a clear and slightly uncomfortable yes. Over the course of the project, we identified a series of pre-authentication weaknesses across two MDM server components and reported everything to SAP through responsible disclosure. This post is the high-level story of how that went, what we did, what we found, and what it tells us about where AI-assisted security research is heading.

We’re deliberately keeping the technical specifics out of this article. The findings are with SAP, and SAP MDM 7.1 is still running in production at organizations that haven’t migrated. You’ll find the shape of the research here, but not a recipe.

Why MDM, and why this is a hard target

SAP MDM is the platform many organizations historically used to consolidate and govern their master data, suppliers, materials, customers, and catalogs, before SAP’s newer master-data offerings. It speaks like a proprietary binary protocol over dedicated TCP ports. There’s very little public documentation on its internals, and the product reached the end of mainstream maintenance years ago. In other words: an opaque, legacy, network-exposed service that’s still quietly sitting inside real corporate networks. That combination is exactly the kind of thing attackers love, and defenders tend to forget about.

It’s also precisely the kind of target that has traditionally demanded weeks of painstaking, specialist effort: capturing traffic, guessing at undocumented message formats, disassembling server binaries by hand, and slowly building up an understanding of how the thing actually works before you can even begin to look for bugs. That’s the part we wanted to test AI against.

How we worked with Claude

The interesting story here isn’t a single magic prompt; it’s the workflow. We used Claude (via Claude Code) as a tireless research collaborator across the full arc of the project:

• Reverse-engineering an undocumented protocol from scratch. Starting from raw network behavior, Claude helped reason for the binary framing, distinguish valid commands from noise, and iteratively build and refine probe scripts to map out how the server responds. What would normally be days of trial-and-error became a fast, conversational loop of hypothesis → test → interpret → next hypothesis.
• Binary analysis of the server executables. Claude assisted in working through the disassembly of the MDM server binaries to locate the relevant command handlers, understand how requests were dispatched, and pinpoint where security checks were and weren’t being applied.
• Disciplined hypothesis testing. For every “this might be exploitable” hunch, we had Claude design experiments to confirm or kill it. Crucially, it was just as willing to rule things out as to chase them. Several promising-looking avenues were carefully demonstrated to be dead ends, which kept the research honest.
• Building proof-of-concept tooling. Claude generated and iterated on dozens of small, purpose-built scripts to validate each finding cleanly and reproducibly; the difference between “I think this is a bug” and “here is a controlled demonstration SAP can act on.”

The part that genuinely impressed us was the rigor. When we pushed on whether one of the memory-safety issues could be escalated all the way to remote code execution, Claude didn’t hand-wave. It walked through the relevant exploit mitigations present in the binary, reasoned about the practical constraints, and concluded, correctly, that while the weakness was real and serious, full code execution wasn’t practically achievable in that pre-authentication context. An AI that tells you what doesn’t work is far more valuable for real research than one that just tells you what you want to hear.

What we found (at a high level)

Across the two MDM server components we examined, the recurring theme was the same one that has haunted legacy enterprise middleware for decades: too much trust extended before anyone has proven who they are. Without going into specifics, the categories of issues included:

• Pre-authentication information disclosure: internal details about the server and its environment that should never be visible to an unauthenticated party on the network.
• Exposure of sensitive configuration and stored credentials, combined with credential protection, turned out to be far weaker than it appeared.
• Authentication that could be bypassed or simply wasn’t enforced on operations that absolutely should have required it, up to and including taking control of server-level access.
• Pre-authentication denial-of-service and memory-safety defects that allow the service to be knocked over remotely.
• A very large administrative surface exposed without authentication, effectively handing an attacker a map of everything the server can do.

Individually, several of these would be serious. Chained together, an unauthenticated attacker with nothing more than network access to the service could move from “I can see this port” to “I control this system and its data” remarkably quickly. That’s the headline, and it’s why we treated this as a coordinated-disclosure matter rather than a blog-first one.

Responsible disclosure

All of this was carried out in a controlled, authorized lab environment against systems we own, and every finding has been reported to SAP through their responsible-disclosure process, with the standard coordinated-disclosure window before any technical detail goes public. We want to thank SAP’s product security team for their continued, constructive engagement on reports like these; responsible disclosure only works when both sides take it seriously.

A point worth underlining for defenders: SAP MDM 7.1 is past mainstream maintenance. If you’re still running it, the single most important control is to make sure these services are not reachable from untrusted networks, to tightly segment and firewall them, and to have a migration plan. Legacy software doesn’t get safer the longer it sits there; it gets more interesting to attackers.

What this means for SAP security research

The honest takeaway is that the economics of this kind of research has shifted. Reverse-engineering an undocumented binary protocol and auditing a server binary used to be the kind of work that only a handful of specialists would attempt, and only when they had weeks to spare. With an AI collaborator handling the relentless, iterative grind and doing so while reasoning carefully about exploitability rather than overclaiming. That effort collapses dramatically. A small team can now cover ground that used to require a much larger one.

That cuts both ways, and it’s exactly why we run this kind of research at SecurityBridge. The same capability that lets us find and responsibly report these issues is available to people who won’t report anything at all. Defenders need to internalize that the barrier to deeply analyzing “obscure” legacy SAP components is falling fast. Obscurity was never security; now it’s barely even a speed bump.

For us, this project was a strong data point: used carefully, with a researcher’s judgment kept firmly in the loop, AI is already a genuinely capable partner for serious SAP vulnerability research. We’ll keep pushing on that responsibly, and we’ll keep working with SAP to get what we find fixed.

SecurityBridge’s research lab conducts SAP security research in authorized environments and reports findings to SAP under coordinated disclosure. Technical details in this article have been intentionally withheld pending SAP’s remediation and disclosure process.