Defend Siemens S7 PLCs; Patch GitLab CE/EE for Exploited Critical Flaw; Apply Updates for Oracle, Citrix Netscaler, Atlassian, Splunk

AI is making it easier for people with less OT expertise to develop and modify tools that interact directly with industrial controllers. Because an attacker with unauthorized access can read or write PLC data and disguise malicious activity as legitimate monitoring, operators must question whether they can trust the control logic, process data, and information coming from a field device. This makes configuration management, independent verification of control logic, and the ability to restore a known good configuration just as important as keeping the PLC off the Internet. Remember, availability is obvious when something stops working. Loss of integrity is potentially more dangerous because the system may continue operating while providing incorrect information or acting on manipulated data.

Used to be we needed to be really careful about traffic destined for our PLCs, as a single malformed packet could disrupt them. While they now seem to be able to handle an Internet-exposed connection, they are now targets for disruptive hacking activity. This round is further augmented by the use of AI hacking tools. Their traffic mimics legitimate management traffic. Grab the guidance from CISA and apply the mitigation and hardening guidance to all your PLCs, doubling down on the Siemens specific guidance, to include applying patches, disabling unneeded features, implementing logging and monitoring, changing default credentials, implementing segmentation, isolating the management port, and leveraging the latest hardening guide. Then make sure you're hunting for the IOCs such as the snap7.dll library. Don't just focus on Internet facing PLCs; make sure that your internal ones are similarly isolated such that only authorized devices are able to access them.

We often forget that the biggest barrier to entry in the exploitation world once was the ability for a specialist to go in and get very good at learning one product, and with that knowledge go find the bugs in relation to that, whether it was a single library such as an ASN.1 parser or a specialist item such as a PLC. Now with base knowledge and a little effort, attackers can bypass much of that rigor and get right to the portions of the issue that they care about. What we are seeing is the acceleration of the ability for something to be exploited. Now what we need is the ability to accelerate the protections of these systems. Notice that the initial problem was "improperly segmented" — instead of trying to eject attackers, try using some of this super intelligence to properly segment to start to defend against these attacks.

This is serious and rather startling. But beneath it all, there’s an important lesson hiding behind the attention-grabbing phrases "PLCs Under Threat" and "AI-generated attack code" here. AI may be helping attackers build and iterate their tooling more quickly, but the defenses CISA recommends are traditional and familiar: Know what PLCs you have, don't expose them directly to the Internet, segment them properly, strengthen authentication, disable services you don't need, and monitor for changes. In other words, AI may be changing the economics of attack, but it does not repeal decades of sound security engineering. For critical infrastructure operators, getting the fundamentals right matters more than ever.

Credit to CISA and partner agencies for issuing this advisory. Ultimately it serves as a timely reminder for organizations to build their cybersecurity strategy around a proven framework like the NIST CSF or CIS Critical Security Controls. The recommended mitigations are practical, standard practice, and straightforward to deploy. Connecting an operational technology (OT) environment to the internet is fundamentally a business risk decision, so it needs to be formally documented and routinely evaluated in the risk register.

If you haven't patched your self-hosted GitLab environment, assume compromise. The good news is the updates can be done without any downtime. Update your GitLab environment, and hunt for the IOC '@gl_introduced’. If you're not on GitLab 19.2.4 or higher, get that scheduled. Make sure that you're signed up for GitLab's patch notifications.

Is it bad that the first thought I had was, "Two days to exploitation, that’s not too bad?" Lately, I've started expecting to see sub-24-hour exploitation of bugs on the regular, and I think that will become the norm. This will be especially true for juicy targets like GitLab which can be a direct path to the crown jewels for a target. My question on these issues goes back to, "How do we make the upgrade process as painless as possible for the customer?" We have to make secure behavior the easier option, and so the principles of ‘secure by design’ mean pivoting towards systems that auto-upgrade safely. We haven't solved that yet, especially for business critical systems, and if you're building software, you need to be considering how to architect for seamless upgrades and micro patches that don't require a "strongly recommended" upgrade process. For providers of essential software, it's great to provide timely fixes, but now let's make those timely fixes easier to implement with less business friction and downtime?

Source Control is becoming a core product in the age of AI and coding. Expect to see many more attacks against these systems as agentic systems become more and more core to the business.

And once again, we have exploitation attempts within days of a critical vulnerability disclosure, or, as I call it, "The New Normal." GitLab is an especially important system to prioritize because our source code, CI/CD pipelines, secrets, and software development workflows increasingly make these platforms part of our crown jewels. If you run an affected self-managed GitLab instance, patch now, and if you were exposed during the window, don't stop at patching: use the published indicators to look for evidence that someone got there first.

The Oracle CPU is so significantly broad that you may single thread on that and miss the updates to Citrix, Atlassian, and Splunk. You likely want to roll out the Citrix NetScaler updates post-haste, then check that your Splunk and Atlassian teams haven't already applied the update. I'd put money on your Splunk team being proactive, possibly needing help rolling the updates to the universal forwarder, while spinning up the regression testing on your Oracle environments. You should already have an agreed upon timeline/process for testing and rolling out that CPU in a timely fashion. If you're in the federal space, the fiscal-year end with associated freezes is approaching, so double check that these updates will be in production before then.

First, the bad news: 1,000 bugs in a month is a LOT of bugs, and there's really no responsible way to assume risk for not patching them if they're confirmed exploitable. We're seeing bugs go from disclosure to weaponization in record time, so with more than 10% of these bugs being critical, you have to act. This is also not just one product — it's multiple, many of which will be deployed in various combinations and configurations at customers, so it'll be a tough push for customers to get these systems upgraded — and almost every enterprise uses some or all of these products, so very few in the industry can sit back and relax this weekend. I worry, realistically, that many won't act as fast as the adversaries and we'll be reading about organizations breached through their Oracle products in the coming weeks. Hyperion and Fusion Middleware, which received the bulk of the patches, both present an attractive attack surface for financial data or backend access. This underscores why criticality assessments are so important, yet so few organizations do this well today. We're only going to see more 1,000-patch months in the future, and “patch them all” just isn't the reality for any vulnerability management team I know today. The solution here is two-fold: 1) Prioritization based on asset exposure and criticality, and 2) Contextualized vulnerability information that clearly highlights those that are in an exploitable state (not just those with a vulnerable version of software installed). This isn't easy work, but it's the future of vulnerability management as a discipline as I see it. Now, the good news: The uptick in vendors releasing mega patch dumps is a positive sign that they're using AI-assisted security testing for good, and some of these products built on decades of technical debt may have a fighting chance to clear the backlog of bugs, find new bugs ahead of the adversary, and overall improve the way software is built in the future. Not all AI news is hype or doom-and-gloom.

Last NewsBites, I remarked that Microsoft fixing 421 vulnerabilities in one month was an extraordinary volume for defenders to absorb. Well... Oracle has now arrived with 943 new security patches, while Atlassian reports another 10 critical and 162 high-severity third-party vulnerabilities, and Splunk and Citrix have substantial updates of their own. Sigh. I sometimes muse about what a time traveler from 2019 would think if they read one of the recent issues of NewsBites. They'd probably think, "What the heck happened? Why are there so many vulnerabilities?" They might think that somehow we'd either gotten MUCH better at finding vulns, or that we got WAY worse in secure software development. A big part of the answer is that we've gotten dramatically better at finding vulnerabilities. And this is exactly why organizations need to be building VulnOps capabilities now: Inventory what you actually run, understand exposure and business context, prioritize intelligently, automate what can safely be automated, remediate, and verify. Nobody can treat a thousand-plus vulnerability fixes as a flat checklist and do a good job. We have to build processes capable of continuously turning this torrent of vulnerability information into rational risk-reduction decisions.

We are probably going to see a massive increase for a while in bugs. My initial hope was that the software would be good enough to find the flaws, and then we would close lots of holes and move on. I'm increasingly thinking that we are going to be making even more software by a large exponential number, and that will increase the number of bugs.

First, this is a measure of the quality of our code. Second, there is an upper bound to the amount of change that our systems can tolerate. These hundreds of patches come from the same people who provided the code requiring the patches. Third, applying these patches is unplanned activity and cost. Fourth, applying all these patches will take not only resources but time, leaving a window to exploit the vulnerabilities. Finally, patching on this scale will be incomplete. We can only hope that AI will improve the quality of code at the source. It is clear that we cannot achieve essential quality at the source using traditional tools and processes.

There's never a good time for a cyberattack, but the first week of school for an educational institution is probably at the top of the list for least ideal, and attackers know this too. The UTSA incident, however, is a good vignette on enterprise breach response. They made an early decision to isolate and cut off access, even to an asset students would need, and they provided communication, proactively extended deadlines for payments, and began comms for password rotation procedures. It underscores the importance of tabletops (and even more importantly, rehearsing those tabletops and IR playbooks regularly) to engage all aspects of the organization for business continuity. Never a good news story when we hear of a breach, but my initial assessment is that UTSA is demonstrating strong leadership and response capability to minimize impact as much as possible.

I want to give UT San Antonio some credit here. Taking systems offline can be enormously disruptive, particularly days before the start of a university semester, but sometimes good incident response looks disruptive from the outside. Containment may require accepting short-term operational pain to prevent a much larger problem. I also like that the university paired its technical response with practical accommodations for the people affected, including delaying classes and extending student deadlines. This kind of stuff isn't fun and can be embarrassing. But cyber incident response ultimately has to take care of people, not merely systems.

That the attack delayed the first day of school to August 24 is concerning. I'm both trying to get my head around the financial and downstream impact of that delay as well as devising a strategy to prevent that sort of impact of an attack. There is a trend of attackers going after universities right at the beginning or end of the term to attempt to extract a significant ransom. To date, nobody is taking claim for the attack, and it doesn't appear university data was exfiltrated. UT did an excellent job of containment and eradication, as well as shifting rapidly to alter deadline and business processes relating to impacted systems — it's really impressive. If you're a UT student, read the guidance on the UT San Antonio Today site; you need to reset your passphrase unless you reset it after 1 am on August 20. They are keeping that site updated.

UTSA's cybersecurity defenses successfully blunted the attack, with system shutdowns appearing to be purely precautionary. Hopefully they publish an after-action report detailing the incident, with safeguards in place and response actions taken. There is a lot the industry can learn from this successful defense.

"Passphrase resets" has an ominous ring to it. It sounds as though strong authentication is not in use.

Apple updated iOS/iPadOS 26 & 18, so make sure both OSes are updated in your environment. Note that they also released visionOS 26.6.1, but not the details. With common code reuse, it's safe to assume it's the same fixes and roll out the update. The separate Safari update applies to older macOS versions; they only package the updated Safari on the most current macOS release.

Image parsers remain such dangerous little pieces of software. They routinely process complex, attacker-supplied data automatically, often with little or no user interaction, which helps explain their long history in sophisticated exploit chains. Keep those Apple devices patched, particularly the ones carried by executives and other high-value targets.

CareCloud provides electronic health record services to about 45,000 hospitals and medical practices across the US. While they are providing ID monitoring/credit protection to affected individuals, don't wait for that breach notice. When you have that protection in place, it softens the blow of these notices. We really cannot opt out of service providers storing our information electronically, and those systems will always be targeted for that reason, so all we can do is protect ourselves. Take a moment to check your subscription status of any ID monitoring services you have, particularly any provided by a breached company; don't let that "insurance" coverage expire.

There are several interesting topics converging in this story. For one, attackers existed in this environment for nearly a week before their access was contained, and that's an eternity when you consider how much data and additional damage could be inflicted in such a long period of time, especially with the added multiplier of AI-assisted orchestration or analysis. A second topic here is that enterprise breach response is rarely finished when the incident is. It's a good reminder that fallout from a breach may not be known for months or years following the incident. This has long-running impact on business reputation and trust, as the incident continues to appear in headlines for weeks or months after the containment (and often not with much praise for what’s been done to mature processes and security following the incident). Third, this touches on the real human impact of these breaches, because it's not just an impact to a business bottom line. Medical information is some of the most sensitive information about an individual and can be used in downstream extortion against individuals who certainly are not protected by cyber insurance if an adversary threatens to release information about their medical history that could have financial or professional impacts on them. As consumers, our only consolation is often identity theft monitoring service, which is insignificant in the grand scheme of damage that this information can do. Lastly, we don't know publicly who was behind this, or whether they're sitting on information for further third-party extortion of victims.

One thing that jumps out at me here is the difference between the visible incident and its eventual scope. An eight-hour disruption in March ultimately became notification of a breach affecting more than 3.7 million people. That's a useful reminder that operational recovery and forensic understanding run on very different clocks. Restoring service is only one milestone; determining what an attacker accessed, what left the environment, who was affected, and what those people need to know can take considerably longer. AI may help accelerate parts of that forensic work over time, but it remains a painstaking process that requires care and validation.

Securely configuring cloud environments remains a common challenge for many organizations. The Center for Internet Security (CIS) addresses this by publishing industry-accepted standards, such as the AWS Foundations Benchmark, which offers clear, step-by-step guidance for implementation and assessment. For operating system security, organizations should leverage preconfigured CIS Hardened Images to streamline compliance and ensure baseline protection from day one.

This case is interesting and a bit of a drama, including claims of misattributed data, protection, death (intentional or otherwise), and parallel illegal activities with supporting evidence, which have made it take this long to build the case and prosecute the developer. Creators of ransomware need smart programmers too, and I still romanticize using their skills for good. That said, there need to be visible, significant consequences for aiding criminal activities, to not perpetuate the illusion that it is some sort of untouchable, glorious career path.

Justice moves slowly — five years to reach trial is a long road. However, if the prosecution succeeds, the steep penalties could serve as a powerful precedent for other nations prosecuting cybercriminals.