SAP Test Automation, MAPS, and CVE-2025-31324 Risk | Merito
Test AutomationApril 8, 2026By Chris Carpenter
SAP Test Automation and Merito MAPS Could Have Saved Jaguar Land Rover from CVE-2025-31324
CVE-2025-31324 is a useful case study for automation engineers because it shows how exposed services, missing authentication, executable upload paths, and weak validation can turn a vulnerability into a business outage. The core lesson is not just AppSec scanning. It is that SAP test automation should include negative security scenarios that verify controls fail safely on every release. Merito MAPS helps teams identify those gaps, prioritize the right controls, and operationalize them in the delivery pipeline.
Most people look at a CVE (Common Vulnerabilities and Exposures) and think the problem is the vulnerability. I'm writing this post to argue that it’s not. The problem is everything around it that allowed it to work, and the fact that nobody was testing those conditions the way an attacker would. The SAP NetWeaver vulnerability CVE-2025-31324 is a critical issue with a CVSS score of 10.0. It allows an attacker to upload a file without logging in. That file can then run on the system. Once that happens, the attacker has full control.
That sounds bad...and you are not wrong...it is really bad. But the more important story is what the vulnerability exposed about SAP validation and release discipline across so many organizations. Including some Merito customers and including the VERY people I taught automation testing to, way back in the day. That's not to say we get it right each and every time, I am aware its a constant, never ending battle where we're always learning. But with that said, slide 11 of our introduction deck does talk about what to automate. And Negative Testing IS one of them!
The Jaguar Land Rover impact
The attack on Jaguar made people sit up and look hard at SAP security. This was not a small incident. It became the most expensive cyberattack in UK history. We saw production stop across global operations, supply chains stalled and core systems went offline. It was estimated the impact reached a whopping $2.8 billion USD in lost profit (I wish I had a shocked Pikachu emoji).
That does not happen because of one bug alone. It happens because the environment, the controls, and the testing strategy all left the door open. Jaguar had strong SAP capabilities too. They had cybersecurity teams. I have to assume they were not ignoring risk. But the attack path still existed, and once it was used, it hit the core of the business... hard.
This is the part most teams miss, even when you are in the SAP world. You must understand SAP is not just IT. It runs manufacturing, logistics, finance, and planning. When SAP goes down, the business stops.
What actually happened
The vulnerability sits inside the Visual Composer component of SAP NetWeaver. It includes something called a metadata uploader. That uploader had a flaw. It allowed file uploads without checking who was sending the request. Attackers sent a crafted POST request to this endpoint:
`/developmentserver/metadatauploader`
No login required.
They uploaded malicious files, often JSP web shells. Once uploaded, those files could be executed. That gave attackers remote code execution. From there, they moved fast.
They escalated privileges to system-level access.
They expanded control across the SAP environment.
They disrupted core business processes.
In many cases, this was paired with additional weaknesses, including deserialization issues like CVE-2025-42999, to gain deeper control but we won't get into that. Groups like Scattered Spider, LAPSUS$, and ShinyHunters have been linked in reporting to activity around this vulnerability. Other groups such as BianLian and RansomEXX also showed interest. This was not a targeted one-off attack. It was a mass exploitation event. The vulnerability was being used in the wild months before many organizations reacted.
Why this worked
This is the part that matters and I said it above. The vulnerability alone did not cause the outage. The environment allowed it to succeed, and the validation model never challenged the system in the way an attacker would.
The endpoint was reachable.
Authentication was not enforced.
File uploads were not restricted.
Execution paths were open.
No negative tests existed to verify these scenarios before release.
That combination is what caused the failure. If even one of those controls had been in place, the outcome changes and this is where most SAP test automation programs break. SAP environments are often treated differently from other applications. They are seen as internal systems which are owned by specialized teams who test for business logic, not attack paths. That creates blind spots. I'm breaking this down to fairly general buckets but most often we see:
But many application security programs and QA efforts still stop at expected behavior. They do not validate what happens when someone tries to break the system. That gap is exactly where this attack lived. For automation engineers, this is the shift that matters and where careers can be slingshotted. Functional coverage is not enough. SAP automation also needs negative testing that proves unauthorized actions fail safely.
What should have stopped this
Start simple. This should never have been exposed, of course that's easier to say in hindsight. The metadata uploader endpoint should not be internet-facing. If it is not reachable, it cannot be exploited. I am mostly saying that to see if my own team is reading this LOL. There are a LOT of ways that statement is false...but let's stay on topic!
Next, authentication. Even if exposed, the endpoint should require login. No exceptions.
Then file handling. Even if a file is uploaded, it should not be allowed to execute. Upload and execution must be separated.
Finally, validation. Someone should be testing this exact scenario on every release. Not just to prove the workflow works, but to prove unauthorized behavior is blocked. While you are at it, throw in some role-based access control testing.
This should be some of the easiest automation test scripts you write in your career. For those organizations that care about test case count (cringe), get those numbers with these types of tests. Because if any one of these controls is working, this attack fails.
If your SAP automation only validates expected workflows, Merito can help you add the negative security coverage with two offerings, we have the MAPS assessment, and implementation services needed to catch exploitable gaps before release.
How Merito approaches this
This is not about adding more tools. Most customers already have the right tools. The problem is how they are used. Merito focuses on connecting three things:
The goal is not a report because we already have too many reports. The goal is detection before release. You most likely already have tools in your org for each of these. You are looking for endpoints that are scanned for exposure. Upload paths that are tested for abuse. And custom code that is reviewed for unsafe handling. If something like this exists, it is found early.
Test automation that actually tests risk
This is where test automation services need to go beyond happy-path validation and start testing failure conditions the way an attacker would. Using platforms like Tricentis and OpenText, Merito builds tests that simulate attacker behavior. We ask the questions:
What happens if a request is sent without authentication
What happens if a restricted file type is uploaded
What happens if someone tries to execute that file
These tests run every cycle. Not once. Not manually. Every time. If the system fails, the release stops.
Security inside the delivery pipeline
SAP transports move changes through environments. Security is often outside that process. Merito puts it inside.
Before anything moves forward:
Scans must pass.
Tests must validate controls.
Configurations must be reviewed.
This removes the gap where vulnerabilities slip through. This is also where MAPS matters. Merito MAPS helps teams identify which attack paths and control failures should become release gates, automated test cases, and implementation priorities. Click on the "Book Consultation" button on the header to schedule some time with me and the team.
Data strategy to limit damage
Did you think I'd forget about data? Even with strong controls, risk still exists. The next step is reducing impact. Sensitive data should not be exposed in lower environments...simple as that, there, I said it! It should be masked or virtualized. If a system is compromised, the damage is contained, as much as we can contain it. I remember very early in my career somebody said "if they have access to the server, we've got bigger problems" and I was left there dumbfounded. This was my first "big boy" argument to advocate for avoiding "many" problems all at once. So yes, their argument was valid... that is a big problem. And if we keep sensitive data out of that environment entirely, then we have a slightly less painful headache.
Monitoring that actually matters
Logs are not enough, every system has logs, what matters is what you do with them. Merito focuses on behavior like:
Unexpected file creation
Access to unusual endpoints
Patterns that look like automated attacks
These signals are surfaced quickly so teams can respond before damage spreads. There are several alerting tools your company already owns to its just a matter of making sure these are monitoring properly, workflows are established and that the right teams are getting notified.
The real lesson from Jaguar
This wasn't a failure of SAP or failure of tools. It was a failure of system design, control enforcement, and validation. The attack worked because the path existed and because nobody was proving, release after release, that the path had been closed. That is the part every organization needs to take seriously and for those who have read this far...I'm telling you in a world of AI, this is how you set yourself up for the next 10 years. Make yourself relevant by learning from these types of exploits and slightly tweak your testing strategy. Let Merito help you make your arguments to your leadership. I want you to take all the credit too! It will bring me great joy to watch you get promoted.
If your SAP environment has exposed services, weak authentication, or untested controls, the same Jaguar outcome is possible. Not theoretical...proven.
Start by asking direct questions, and if you don't know... let's do a DAST scan. You probably already have a DAST tool in your org too!
What SAP endpoints are externally reachable?
Which of those require authentication?
Can any of them accept file uploads?
Are those uploads restricted and controlled?
Are you testing those scenarios every release?
Do your automated tests include negative security cases, not just expected workflows?
If you cannot answer those clearly, there is risk. Not just with CVE-2025-31324, we know this will not be the last vulnerability like this. There will 100% be others. The difference is whether your environment is built to handle them. If you reduce exposure, enforce controls, and validate continuously, vulnerabilities lose their impact. If you do not, they become business events. Jaguar Land Rover already proved that.
If your team wants stronger SAP validation that covers both functionality and exploit resistance, I highly recommend you start with a MAPS assessment.
Frequently Asked Questions
Keep Reading
Related Blogs
Explore a few more Merito insights that align with the themes in this article.
