Food Retailer IT & Freezers Disrupted by Cyberattacks; Patch GitLab for CVSS 10.0 Flaw; South Korean Bank Hacker Possibly Identified by AI Session Logs

The similarities between this attack and the unexplained refrigeration failures at US military commissaries in August deserve investigation, although I don't believe a connection has been established. What makes the French incident particularly interesting is that attackers used a legitimate defrost function to cause physical and economic damage across hundreds of stores. An important commonality is the compromise of refrigeration controls across multiple locations, producing physical consequences without compromising the stores' primary IT systems. The engineer inside of me would like to know why a remotely issued command is allowed to drive refrigeration equipment into an unsafe operating condition without an independent temperature limit, alarm, or protective mechanism.

We've spent a lot of time talking about OT and Critical Infrastructure security recently. Make sure everything that can be remotely controlled and monitored is considered. It's no longer "just" a vending machine or refrigerator. Are you up on your environmental control systems? How about the data center? CCTV? Double check that you've got remote servicing and support, not only for the security of those devices, but also for the security of devices which are reachable from them. Have you considered the security of a device the technician "just plugs in" to do their task? An action item from the Ahold Delhaize attack: Make sure you're clear about all the impacts from an incident. Transparency trumps future damage control.

We often talk about the risks of exposed IoT devices like this, but there are few examples of catastrophic exploits like this. It appears that in this particular case, the thermostat controls were not only exposed to the internet, but also used a well-known password scheme (the current date… yes, the password changed daily). We do not know the motivations of the attackers yet, but the food supply chain has been considered a vulnerability for a long time.

While it remains unclear if the two events are connected, food and its distribution represent another critical resource, much like water, that demands heightened protection. Recent OT best practice guidance from CISA and the FBI highlights two primary defensive actions for organizations: eliminating public internet exposure and strengthening passwords and access controls. Had either of these measures been in place, this incident would not have made the headlines.

To paraphrase an old saying, "If you decide to poke a hole in the basket that holds all your eggs, you really, really need to watch what is coming through that hole." You can easily understand why remote alarms from freezers might justify external monitoring. This is one of the classic examples for the "data diode" approach — regular outbound reporting without any inbound connectivity, or as a minimum only with strongly authenticated logon.

Last Friday in NewsBites, we were discussing Cyber Informed Engineering and the importance of keeping physical processes within safe limits even when digital controls are compromised. Now attackers have reportedly manipulated refrigeration controls at hundreds of French supermarkets, spoiling enormous amounts of food. I find cyberattacks that damage the food supply particularly heinous. We rightly worry about attacks against hospitals, but food safety and availability deserve serious alarm, too. As Johannes points out, these controllers apparently had Internet exposure and a painfully predictable password scheme. Strong authentication and access restrictions matter enormously, but so do independent temperature monitoring, out-of-band alarms, local overrides, and physical safety limits that attackers cannot simply change through the compromised system. OT security isn't limited to power plants and factories. It's in the grocery store aisle, too.

This is extremely concerning. You might not think these devices are highly impactful, but weaponizing smart, temperature-controlled systems is a serious threat to many Western countries. You now have highly motivated attackers who are thousands of miles away spoiling food _en masse_ for the Western world. Hopefully retailers take their importance in the supply chain to heart. We have more technology today to properly isolate and control these systems at the port level with microsegmentation, or at the network level with macrosegmentation; we should enforce those controls. Will it be painful? Yes? The other painful thing is throwing out all the food in inventory.

Any attack on critical infrastructure — to include where we source our food and water — is an attack on civilians. I think this also illustrates the supply chain's impact on the “kinetic world.” Intermarché, U, Leclerc, and others don't share a computer network, but they could share a refrigeration vendor or maintenance provider, and Intermarché pointed to "a service provider that manages refrigeration systems." This means that sometimes “spray and pray” attacks or unintended overflow beyond an original intended target can have widespread effects. It also reminds me of what I said about the NCSC advisory last month: Exposure is rarely a decision someone approved. More often it comes from vendor remote support that nobody owns. Ed's point about independent monitoring is borne out here, too. One employee reported that "the on-call alarm never rang," while staff who were alerted overnight were reportedly able to fix things by hand. If you run facilities with remote-managed equipment: (1) Ask your service providers how and from where they access your controllers so you can update your monitoring accordingly; (2) Push on those vendors to use secure access solutions and just-in-time access over less-safe methods like old-school VNC or RDP; and (3) Make sure you have disaster recovery and business continuity plans that include on-site manual procedures for systems typically managed remotely.

Using the public networks in OT is inherently risky and justifies all of the measures that my colleagues have identified and recommended. Note that a password with a life of 24 hours used across multiple enterprises and hundreds of devices, does not meet the requirements of Strong Authentication (at least two kinds of evidence, at least one of which is resistant to replay).

GitLab.com is already running the patched versions; GitLab Dedicated customers do not need to take action. The flaw impacts all types of GitLab deployments — in other words, just update all your instances now. For security fixes, GitLab releases the details of each vulnerability publicly 90 days after the release in which they are patched.

GitLab has patched several vulnerabilities recently. This issue is particularly severe as it does not require authentication and allows for code execution.

Here we go again. How many GitLab criticals in the last few months? I'll say the same thing I always do: This system holds your source code, your pipeline config, and your secrets, so it needs to be at the top of your patch list. To be fair to GitLab, there's no report of exploitation yet. GitLab.com is already patched, and the advisory says the RCE works "under certain conditions," which they haven't spelled out.

The bug I'd ask you to look at twice is CVE-2026-96893 in the Duo Agent Platform. It's rated lower, but an authenticated user can inject content into AI agent instructions that results in "unintended command execution attributed to other users." That last part should worry anyone doing forensics, because if the audit log says Alice ran it, but an agent did it because of something Bob planted, your investigation starts from the wrong person. As an industry we must consider that agent plugins and skills are now a patch and hygiene surface. Attribution is getting messier in this agentic attack world, and I don't see that trend going away anytime soon.

Yowza! This list of GitLab vulnerabilities reads like a whole set of SANS course labs: unauthenticated RCE, CI/CD authorization flaws, potential exposure of protected environment variables, and prompt injection that could cause an AI agent to execute commands attributed to other users. In a training lab, that would be a blast. On a production system that builds and deploys your software, it's a nightmare. Johannes is absolutely right to highlight the unauthenticated code execution, but the breadth of issues here deserves attention, too. CI/CD systems often hold source code, secrets, and deployment privileges reaching deep into the environment. Treat that infrastructure like the crown jewel it often is. Patch this one, folks!

GitLab has grown to nearly $1B in revenue in its most recent fiscal year. Hopefully this spurt of high severity flaws is the fruit of using some of the increased profit on real increases in securing their infrastructure.

This reinforces the observation that financially motivated threat actors are actively using AI to speed their attacks, increasing the tempo. Our defenses remain essentially the same; what has changed is our response window. You need to have a risk-based tiering of systems where most of them fall into automated updates and where security controls are implemented as SOP. This way you have resources to throw at analysis, regression testing, and planning on high-impact, riskier (to the business) systems. Don't forget to use the AI capabilities of your existing toolset. Even your CFO, who begrudgingly gives you 11:58PM to 12:01AM downtime, appreciates that you don't wish to join the list of victims, but may miss that you're trying to stack the deck in their favor to avoid future awkward conversations, so tell them so. It's easy to forget you've got the same business goals in mind. The better your relationships are with other parts of the organization, the easier it will be to talk about improvements you need and for them to talk about their business/mission requirements and come up with cool ways to achieve both.

The resume request was amusing, but the other evidence (session histories, configs, memory files) in the actor’s open directories is more interesting to me. Agentic tools generate abundant state; whoever finds the right evidence and can piece it together first wins, whether that's the attacker finding the evidence needed to pivot through your environment, or you finding the evidence of the back-and-forth and iteration on activity in real-time. Economically, open-source agents plus cheap APIs let low-skill actors launch rapid intrusions, which has already been observed widely. Barriers were low with RaaS and access brokers, but cheap and prevalent AI lowers them further. Overall, AI attacks are faster but leave far more noise and artifacts. Therefore, parsing them demands equal AI skill from investigators and leaves minutes, not hours or days, for preservation and analysis. Preserve evidence quickly and comprehensively: tmp files, network requests, timestamps, and heartbeat cadence can reveal agent “thinking” patterns that I personally find really interesting and look forward to future research on. Monitor east-west traffic as attackers use agents internally. AI attacks differ not just in speed but in artifact type and noise, requiring new sleuthing to distinguish success, noise, or deception. I’m optimistic, though. This is forcing a shift in how we think about real-time IR capabilities.

A resume request in an AI session log that might help identify the attacker? Ya gotta love it when attackers mess up like that. We spend plenty of time talking about how AI can amplify offensive capabilities, but poorly secured AI tooling can also leave an enormous trail of artifacts for investigators. Prompts, tool calls, session histories, and intermediate files can become a treasure trove of evidence. Kudos to CrowdStrike for finding and analyzing this material. And remember, automation can amplify attackers’ operational mistakes, too!

It is essential that we hold the user, not the tool, responsible.

At this point you should be using automatic processes to keep your certificates updated, making the process of keeping them updated transparent, regardless of certificate lifespan. Some of you are saying you're already using their 45 day certificates, this is not a concern; my point is that the days of manual certificate update and deployment need to be long past. Make sure that your automated renewal processes don't hard code the renewal interval — look for values like 83, 80, or 60 days — and that you have not specifically configured your ACME client to rely on validation reuse. Fix issues now; don't wait for May. They'll just get forgotten or skipped.

Certificate lifetimes will continue to shrink over the next few years. Best to get ready now and ensure proper automated renewal procedures are in place. Let's Encrypt offers a "shortlived" profile that can be used to retrieve certificates that are valid for only seven days. Try using them in a test domain to see if you can properly maintain and rotate them on time.

Let's Encrypt has been ahead of the curve in shortening certificate lifespans, which is a good thing. The certificate issuers should all focus on increasing the strength of registration/authorization in certificate issuance processes.

Johannes's suggestion to test with very short-lived certificates is a good one. When doing so, make sure to exercise the entire certificate lifecycle, not just renewal. Does the new certificate actually make it to every endpoint where it needs to be installed? Do services reload? Does monitoring catch failures before users do? If one step breaks, can the automation recover? Shorter certificate lifetimes can improve security, but they'll also expose brittle handoffs in our operations. A certificate that renews successfully but never gets deployed to production isn't doing you much good.

Expect this trend to continue across every CA as the industry addresses broken revocation mechanisms, reduces risk windows for compromised keys, and automates certificate management. In short, shorter certificate lifespans provide a guaranteed cleanup mechanism for various security risks.

As CAs, go the representation made by Let's Encrypt, Domain Ownership Validation, is already fairly weak. On the other hand, Let's Encrypt's leadership has encouraged the pervasive use of encryption at the transport layer.

Third-party system access using credentials obtained via social engineering. I'll take MFA for a $1,000 Alex. We're not going to stop social engineering; what we need to do is double down on comprehensive MFA, ideally phishing-resistant MFA to reduce its effectiveness. Don't forget to include training on not providing MFA tokens/codes to ANYONE. The idea of phishing-resistant MFA is there are no codes or other shareable components, avoiding this scenario.

While one now recommends the use of strong authentication in all multi-user systems, the failure to use it on enterprise Internet facing applications is reckless.

Two weeks ago I wrote about ShinyHunters' threats against the FBI, and how much cybercrime has come to resemble legitimate business. I didn't expect the next chapter to involve someone from the legitimate business side. While the facts are sealed and murky, the story raises a question the industry should ask regardless of how this case ends. When you bring in a ransomware negotiator, you hand them your most sensitive facts on your worst day. That's an extraordinary level of trust, and most organizations extend it through an insurance panel list or an IR retainer, sometimes without deeply vetting how that firm vets its own people. Krebs reports that his sources expect charges against principals at other negotiation firms "may be forthcoming." If that turns out to be true, it'll be a hard year for a profession that, in my experience, is mostly made up of responsible people doing difficult work in good faith. So before your next incident, consider these practical steps: (1) Ask your IR and negotiation providers how they screen staff and control access to case data; (2) Find out who on their side can see your financial position and ransom deliberations; (3) Make sure engagement with criminals is a sanctioned, supervised function on your own team too, not something one person handles alone.

Anybody else recalling last year's incident at DigitalMint? Ransomware remains lucrative, which is why it's still going strong, and the temptations are a sufficient lure to cause one to change roles. If you're hiring such a negotiator, regrettably many private companies do pay the ransom, and you're going to want to carefully verify they are reliable. On the other side, this emphasizes the need for ongoing reliability checks. In my background, we had positions which required human reliability checks, regular screening/testing, and required codes of conduct, to conduct certain roles. These are up-front requirements, in positions where temptation to cross the line is significant. Temptation is real, and people make bad choices. Do what you can to detect and deter these actions.

This is an interesting development. Although details remain limited beyond what KrebsOnSecurity reported, previous cases have shown ransomware negotiators becoming complicit in cybercriminal activity. The cited book reference suggests that negotiators frequently build rapport with attackers — a dynamic that can sometimes be a telling indicator of deeper involvement.

One may infer from the title of his book that he knew what he was doing.

The investigation highlights the value of collecting logs for analysis. Remember to investigate options like a data lake for offline log storage over longer intervals. This guy started setting things up in 2023 before pulling the trigger in 2025. Now that you have comprehensive logs, are you catching the right things? For example, could you have triggered an alert at the deletion of Domain Administrator accounts or broad scale password changes? How about detecting unauthorized changes or sessions? New tools make this analysis easier; it's worth pulling this thread as well.

Justice served. CISOs ought to leverage this outcome as a real-world case study in their annual cybersecurity training programs.

The lesson for the rest of us is that, when terminating an employee, it is as essential to terminate all privileges and authorities, as it is to remove them from the payroll.