Skip to main content

When the Engine Stops: JLR’s Cyber Crisis and What It Reveals

It’s been a long time since I posted to this blog, I’ve had some personal issues that I needed to resolve and unfortunately this had to take a back seat for a while. But that said here is a new post regarding the ongoing issues at JLR.

 

The Impact of the Cyber Incident

 

Since late August, the UK’s largest car manufacturer has been grappling with a cyber incident that’s triggered a global production shutdown. The company’s IT systems are offline, its plants are silent, and tens of thousands of vehicles are stuck in limbo. What’s missing? Answers.

The disruption began when unusual activity was first suspected in the company’s systems towards the end of August 2025, prompting an internal escalation and reports of outages by staff on 31 August. By 2 September, the company confirmed a “cyber incident” and halted all operations worldwide, affecting manufacturing plants in Solihull, Halewood, and Wolverhampton, as well as facilities overseas in China, India, and Slovakia. In response, a manual vehicle registration workaround was rolled out with the DVLA, while the production stoppage forced suppliers such as Evtec and WHS Plastics to implement temporary layoffs. As of 28 September, the shutdown has been extended to at least 1 October, with no attacker named and investigations ongoing in collaboration with the National Cyber Security Centre and law enforcement.

 

Timeline of the incident so far

 

·        Late August 2025: Unusual activity is first detected within JLR’s IT infrastructure, raising initial suspicions of a possible cyber threat. At this stage, the company refrains from making any public statements while internal teams quietly begin to assess the situation in the background.

·        31 August: The situation escalates internally as staff across the company begin reporting widespread system outages, signalling the severity of the disruption. This prompts formal internal escalation procedures, with IT and management teams intensifying their investigations.

·        2 September: JLR publicly confirms it is facing a “cyber incident” and takes the significant step of suspending all global operations. Production is halted at major manufacturing plants in the UK, including Solihull, Halewood, and Wolverhampton, as well as at overseas facilities in China, India, and Slovakia.

·        Early September: To mitigate the impact on vehicle deliveries, JLR coordinates with the DVLA to implement a manual vehicle registration workaround. This temporary measure allows some vehicle deliveries to proceed despite the main IT systems being offline.

·        Mid-September: The production shutdown’s ripple effects become evident as key suppliers, such as Evtec and WHS Plastics, announce temporary layoffs. With manufacturing at a standstill, these companies are forced to reduce their workforce until operations resume.

·        28 September: Facing continued uncertainty, JLR announces that the production shutdown will extend at least until 1 October. No attacker has been publicly identified, and investigations continue in coordination with the National Cyber Security Centre and law enforcement authorities.

 

What We Know So Far

 

·        Widespread Shutdown: JLR’s principal UK plants—Solihull, Halewood, and Wolverhampton—are out of operation, as are their production sites in China, India, and Slovakia. All manufacturing activity has been suspended since the start of September.

·        Ongoing Investigation: The company is actively collaborating with the National Cyber Security Centre and law enforcement agencies to investigate the incident, though detailed findings have yet to be shared.

·        Interim Measures: In an attempt to keep business moving, JLR, together with the DVLA and Department for Transport, has introduced a manual vehicle registration workaround. This enables some vehicle deliveries to continue, despite the main IT systems being offline.

·        Financial Impact: The shutdown is causing estimated daily losses of between £5 and £10 million, with the cumulative effect potentially exceeding £240 million.

 

What Remains Unclear

 

·        Attribution and Motive: No party has claimed responsibility for the attack. There has been no ransom demand and no clear attribution to a specific group or individual.

·        Recovery Timeline: JLR has not provided any information regarding how long the disruption might last, leaving the timeline for full recovery uncertain.

·        Extent of Data Compromise: It is not yet clear what data, if any, has been compromised or how deeply the organisation’s systems have been affected.

 

Why This Matters

 

The ramifications of this cyber incident extend far beyond JLR itself. With tens of thousands of direct employees and a supply chain involving over 200,000 workers, the impact is felt throughout the Midlands, the wider UK manufacturing sector, and international operations. The situation highlights the vulnerability of legacy systems and the interconnectedness of modern supply chains. It also underscores the challenges companies face in balancing strategic silence with the need for transparency as staff, suppliers, and customers seek clarity in the midst of ongoing disruption.

This isn’t just a JLR problem. It’s a Midlands problem. A UK manufacturing problem. A legacy systems problem.

            Supply chain fragility: With 33,000 direct UK employees and over 200,000 in the supply chain, the ripple effect is real.

            Regulatory entanglement: The DVLA workaround hints at deep integration—and deep vulnerability.

            Strategic silence: JLR’s discretion may be legally prudent, but it leaves suppliers, workers, and customers in the dark.

 

Cyber Resilience: More Than Just Technology

 

Cyber resilience isn’t just about firewalls and backups. It encompasses a broader set of principles that are crucial for organisations facing modern threats. True resilience requires:

·        Transparency: Being open with stakeholders about incidents and their impacts, even when all the facts aren’t yet clear, helps to maintain trust and manage expectations.

·        Contingency Planning: Effective preparation ensures that, when disruptions occur, there are clear procedures in place to limit damage and recover quickly.

·        Communication Under Pressure: The ability to provide timely updates and guidance to staff, suppliers, and customers is essential, particularly when uncertainty is high.

In the case of JLR, their current silence may be a deliberate strategy, possibly for legal or investigative reasons. However, for the Midlands region—where the ripple effects of this incident are felt by thousands of employees and hundreds of thousands across the supply chain—such silence is deafening. The lack of information leaves businesses, workers, and communities in the dark, heightening anxiety and uncertainty.

The situation serves as a stark reminder that cyber resilience is not just a technical challenge, but also a test of leadership and communication. Companies must find the balance between necessary discretion and the need to keep their wider networks informed and reassured during times of crisis.


Comments

Popular posts from this blog

Root of the Problem: Linux Flaws That Give Attackers Admin Rights

 I realised that I haven’t posted to my blog in a long time and this week an article about CVE’s in linux caught my eye and that was the perfect excuse to write another blog post. Cybersecurity researchers at Qualys have uncovered two critical local privilege escalation (LPE) flaws that are shaking the foundations of Linux security. These aren't your run-of-the-mill vulnerabilities; we're talking about direct, express lanes to full root access on major Linux distributions. If you use Ubuntu, Debian, Fedora, openSUSE Leap 15, or SUSE Linux Enterprise 15, you need to pay close attention. The Double Threat: CVE-2025-6018 & CVE-2025-6019 An article detailing the CVE’s can be found at the link below ( CVE-2025-6018 and CVE-2025-6019 Vulnerability Exploitation: Chaining Local Privilege Escalation Flaws Lets Attackers Gain Root Access on Most Linux Distributions | SOC Prime )     Qualys has pulled back the curtain on two distinct, yet chainable, vulnerabilit...

From OVA to Rocky: My Wazuh Upgrade Story

  In this blog post I will be covering something I’ve covered in a previous blog post, but I’ve decided to change my home lab and put my Wazuh SIEM on a standalone rocky linux, there are several reasons I chose to do this, Performance & Scalability: The OVA VM is a pre-built virtual machine that may not be optimized for high availability or scalability. A dedicated instance on Rocky Linux allows for better resource allocation and tuning. Customization & Flexibility: The OVA VM comes with predefined configurations. Running Wazuh on Rocky Linux gives you full control over system settings, security policies, and software updates. Compatibility & Stability: Rocky Linux is a stable, enterprise-grade OS, and Wazuh has been tested for compatibility with newer versions like Rocky Linux 9.3. This ensures long-term support and reliability. Security & Isolation: A dedicated instance provides better security isolation compared to a shared virtualized environment. You can impl...

Up the Wazuh: A SIEM-ple Adventure in Troubleshooting

Initial setup To start  I downloaded the .osa file from the  wazuh website ( https://wazuh.com ) and then installed it in my virtualbox hypervisor. Then I booted up my fedora linux VM and the wazuh VM with the dashboard and manager on.  After I had logged in to the wazuh VM with the default credentials I used the ip a command to find out the ip address of the wazuh VM. As from reading the documentation I’d need this later. In my fedora VM I opened a terminal and used the commands on the wazuh website to install the agent on the VM. After some time the installation was completed and I had to update the. conf file with the IP address of the wazuh manager. This is important because  the file is a generic file that needs to be modified to make it specific to each individual setup.  All was going well up to this point. I tried to get the fedora VM to talk to the wazuh VM. The problems I encountered It was here the problems started when I tried to pi...