In software testing and quality assurance (QA), we often focus on identifying bugs, vulnerabilities and risks before they hit production. But what happens after a patch is released?
The recent cyber-attack on Jaguar Land Rover (JLR), which struck on August 31, 2025, is a stark reminder that security is a shared responsibility. Claimed by the group now calling themselves “Scattered Lapsus$ Hunters”—the same collective linked to high-profile breaches at M&S and others – the incident has disrupted global operations and shown how patch delays can lead to catastrophic downtime.
We’re diving into this case to explore not just the technical failures, but the organisational ones too.
Table Of Contents
The Attack: A Quick Recap
JLR, a major player in the automotive industry, fell victim to a cyber-attack that exploited known vulnerabilities in its SAP NetWeaver systems. Attackers chained two critical flaws: CVE-2025-31324 and CVE-2025-42999 to gain administrative access and execute arbitrary commands.
This forced a global shutdown across manufacturing plants in the UK, Slovakia, China, India and Brazil, alongside retail disruptions. Key suppliers were also hit, creating a ripple effect across the supply chain.
The human impact was immediate: around 33,000 UK factory staff were told to stay home after operations at plants were suspended until further notice. JLR, which typically produces around 1,000 vehicles per day, is now dealing with major backlogs and customer delivery delays.
And the fallout doesn’t end there. JLR confirmed that some customer data may indeed have been affected, reversing its earlier position.
The timing couldn’t have been worse: the attack coincided with the UK’s “75 plate” registration sales boom, a peak period for new vehicle sales.
The Ripple Effects: Beyond JLR’s Walls
The attack highlights just how interconnected modern supply chains are. Independent garages and aftermarket specialists have been paralysed, unable to access JLR’s digital ordering systems for parts. Thousands of Jaguar and Land Rover owners are now facing extended repair delays, as diagnostics and parts ordering grind to a halt.
This paralysis creates a domino effect: Dealerships are also stuck, unable to register new cars, leaving customers who’ve already ordered vehicles waiting indefinitely. Suppliers are reporting millions in lost orders. And ordinary drivers are left missing commutes, school runs, or appointments because their mechanics can’t get the parts to fix their cars.
This is the ripple effect hackers aim for: maximum disruption that goes far beyond the target organisation.
Vulnerabilities and Failures
Here’s what we know from sources including SecurityWeek, Hackread and The Stack:
- Exploited Known Vulnerabilities
SAP had already released patches for these NetWeaver flaws before the attack. Over 1,100 SAP systems were targeted globally in similar campaigns by April 2025. JLR’s delay in patching left them exposed. - Legacy Systems and Poor Segmentation
Decades-old ERP and production systems, which are tough to secure and lack proper network segmentation or a zero-trust architecture, meant attackers could move laterally once inside. - Weak Access Controls and Social Engineering
Likely entry point: phishing or vishing for admin credentials. Weak MFA (multi-factor authentication) and unmonitored privileged accounts made escalation easy. - Inadequate Business Continuity
No isolated backups or redundant systems meant JLR had to shut everything down globally. - Security Awareness Gaps
Despite JLR’s reported phishing tests in its 2023 annual report, JLR wasn’t ready for the sophisticated social engineering tactics used here.
Bottom line? This breach was preventable with stronger patching, identity controls and resilience planning.
It’s Not Just Down to Testing: The Handover to Operations
As QA and testing professionals, we validate patches and advocate for secure code, but once SAP ships a tested, approved patch, it’s down to the client’s operations teams to implement.
In JLR’s case, the patches were available. But downtime fears often delay patch rollouts in manufacturing. The irony? This attack has caused two weeks (and counting) of global downtime, far worse than the cost of a planned patch window. Lost revenue, halted production lines, supplier disruptions – these far outweigh the controlled downtime of a planned patch rollout. And as we’ve seen, the knock-on effects to garages, customers and beyond make the true cost even higher.
Testing is about risk mitigation, but it doesn’t end at release. Operations must treat patch management as a core function, not an afterthought. Tools like automated vulnerability scanners (e.g., Nessus) and patch management systems can help schedule updates during off-peak hours, minimising disruption. Downtime isn’t an excuse—it’s a choice, and in this case, it led to a much larger crisis.
Assigning blame in cyber-attacks is tricky, but it’s essential for learning.
- Vendors (SAP): They bear some responsibility for ensuring vulnerabilities are patched quickly and communicated effectively. In this instance, patches were available, so the vendor side seems to have done its part post-discovery.
- Ops/IT at JLR/Tata: Primary blame falls here for not applying patches promptly. Exposed internet-facing systems and weak MFA enforcement were avoidable. If testing validated the patches, ops teams should have implemented them without undue delay.
- Management and Leadership: Cultural issues, like prioritising short-term uptime over long-term security, often stem from the top. JLR’s 2023 report mentioned cybersecurity workshops, but execution gaps suggest insufficient investment or oversight.
- Attackers: Culpable, yes, but we can’t control them; we can only control our defences.
- Testing & QA: Not directly at fault, but this shows the need for tighter DevSecOps collaboration to ensure patches don’t just exist, but actually get deployed.
In essence, blame is distributed, but the lion’s share goes to those who manage live systems. As testers, we can influence this by advocating for end-to-end accountability in our training and processes.
Prevention Recommendations
To avoid JLR’s fate, organisations should adopt these best practices, with a testing lens:
- Aggressive Patch Management – Test patches in staging environments quickly and then push them to production. Use automation to reduce manual delays.
- Zero-Trust and Segmentation – During testing, simulate segmented networks to identify weak points.
- Strong MFA & Identity Controls – Incorporate security testing for access scenarios, including just-in-time privileges.
- Business Continuity Planning – Test disaster recovery plans regularly—treat them like any other QA exercise.
- Security Awareness & Red-Teaming – Run phishing simulations as part of ongoing QA training.
And don’t overlook supply chain risk, conduct vendor audits and share intelligence via groups like the Automotive ISAC.
A Call to Action for Testers
The JLR cyber-attack is a case study in why patch management isn’t just “ops work”. Testing uncovers risks, but if those risks aren’t acted on post-release, downtime fears quickly turn into downtime realities.
The lesson? Controlled patch windows may sting, but uncontrolled global outages hurt a whole lot more, impacting not just the business, but employees, suppliers and everyday customers.