BTH News: October 29, 2026

Brotli emergency patches, a software supply-chain compromise, PHP vulnerabilities under attack, and AI-assisted hacking in South Korea.

Welcome back to Between The Hacks News, where we look beyond the cybersecurity headlines to understand what actually happened, why it matters, and what you should do about it.

This week, Microsoft issued emergency patches for a vulnerability in a widely used compression library. A software supply-chain attack demonstrated how a compromised credential can put downstream customers at risk. Two critical PHP vulnerabilities moved from warnings to confirmed exploitation. And South Korean police arrested suspects accused of using AI to attack more than 90 organizations.

There's plenty to cover, so let's get started.

1. Brotli: When a Vulnerability in One Library Becomes Everyone's Problem

A vulnerability in a compression library might not sound particularly exciting. But when that library is used by browsers, web servers, applications, and development frameworks, things can get interesting quickly.

That's what we're seeing with Brotli, an open-source compression library developed by Google.

Brotli helps reduce the size of data transferred across the Internet. It makes websites load faster and reduces bandwidth consumption. You've probably used it thousands of times without knowing it.

Unfortunately, researchers discovered a vulnerability, tracked as CVE-2026-111497, that could allow attackers to exploit applications processing specially crafted compressed data.

Microsoft took the unusual step of releasing emergency, out-of-band security updates for affected .NET versions, including .NET 8, 9, and 10.

CISA has also added CVE-2026-111497 to its Known Exploited Vulnerabilities catalog, confirming that the flaw is being exploited in the wild.

And Microsoft isn't alone. Because Brotli is used across numerous platforms and programming languages, other software vendors are investigating their exposure and releasing updates.

Does that mean everything using Brotli is vulnerable?

No. And this is where things get interesting.

There's a significant difference between having vulnerable software installed and actually being vulnerable to an attack.

For example, Brotli decompression isn't enabled by default in certain .NET configurations. An application must use the affected functionality in a way that allows an attacker to supply malicious compressed data.

That distinction matters.

A vulnerability might exist in a library used by millions of applications, but that doesn't mean every application can be exploited.

It also doesn't mean the vulnerability should be ignored.

Attackers are increasingly looking for weaknesses in common software components because one vulnerability can potentially affect thousands of products.

What should you do?

If you're responsible for applications using Brotli, determine whether they're using affected versions and whether the vulnerable decompression functionality is reachable by untrusted input.

Review vendor advisories and install applicable security updates.

Don't assume that updating the operating system fixes the problem. Applications sometimes include their own copies of vulnerable libraries.

And don't assume that simply having the library installed means you're exposed.

The important lesson: Understanding how a vulnerable component is used is just as important as knowing that the component exists.

That's one reason I continue to advocate for better software inventories and risk-based vulnerability prioritization.

2. LiteLLM: A Compromised Credential and the Software Supply Chain

Software supply-chain attacks are particularly concerning because they exploit something we all depend on: trust.

We trust software vendors to distribute legitimate updates. We trust package repositories to deliver the software we request. And we trust the tools developers use to build applications.

Attackers know this.

This week's LiteLLM incident is another reminder of what can happen when that trust is compromised.

LiteLLM is an open-source project that helps developers connect applications to multiple large language models through a common interface.

Rather than writing separate integrations for every AI provider, developers can use LiteLLM to simplify how their applications communicate with those services.

That makes it useful. It also makes it an attractive target.

According to LiteLLM's investigation, attackers exploited a previously exposed credential to compromise part of the project's software release process.

The attackers were then able to distribute malicious software through a channel developers ordinarily trusted.

The problem with trusted software

Imagine downloading a software update from the same place you've used hundreds of times.

The website looks legitimate. The package name is correct. The version appears to be an ordinary release.

But the software has been modified.

That's the danger of supply-chain compromises. Attackers don't necessarily need to convince you to visit a suspicious website or open a malicious attachment.

Instead, they compromise something you already trust.

And when the affected software is a dependency used by other applications, the consequences can spread well beyond the original target.

What should organizations do?

First, determine whether your organization uses LiteLLM and whether any affected versions were installed.

If so, follow the project's incident-response guidance, including reviewing potentially exposed credentials and rebuilding affected environments where necessary.

Simply installing a clean version may not be enough if an attacker has already obtained credentials or established persistence.

Organizations should also review how they manage software dependencies, protect development credentials, and verify the integrity of software releases.

This is another reason software bills of materials, dependency monitoring, and secure development practices matter.

The important lesson: A software update is only as trustworthy as the systems and credentials used to produce it.

And in an increasingly interconnected software ecosystem, a compromise affecting one project can create problems for organizations that have never heard of that project.

3. PHP2Shell: Last Week's Warning Becomes This Week's Exploitation

Last week, we covered two critical PHP vulnerabilities that could potentially allow attackers to execute code remotely without authentication.

At the time, the immediate concern was identifying vulnerable systems and installing the available patches.

This week, the situation changed.

On October 26, CISA added both vulnerabilities, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalog.

Both carry CVSS scores of 9.2.

The vulnerabilities have been collectively referred to as PHP2Shell.

Researchers have also reported successful exploitation against vulnerable honeypot environments.

That is an important development, but we need to understand exactly what it means.

Confirmed exploitation doesn't mean everyone is compromised

Security researchers frequently use honeypots to observe how attackers behave.

These systems are intentionally configured to attract attacks. In some cases, they're deliberately made vulnerable so researchers can study exploitation techniques.

Successful exploitation of a honeypot demonstrates that an attack can work under the conditions present in that environment.

It doesn't necessarily establish how reliably the exploit works against other configurations.

And it certainly doesn't mean every PHP website has been compromised.

However, CISA's decision to add these vulnerabilities to KEV provides another reason for organizations to prioritize remediation.

The forgotten systems problem

One of the biggest challenges with vulnerabilities like these isn't installing a patch.

It's finding every system that needs one.

An organization might know about its primary website, customer portal, and production applications.

But what about the development server someone installed three years ago?

Or the old WordPress website that was supposed to be retired?

Or the internal application nobody remembers maintaining?

Those forgotten systems can become attractive targets, particularly when they're accessible from the Internet.

What should you do?

Start by identifying affected PHP installations, including systems that may not appear in your official inventory.

Prioritize Internet-facing applications and systems that process sensitive information or have access to important internal resources.

Install the appropriate PHP security updates and review available indicators of compromise.

But remember that vulnerability management isn't simply about patching the highest CVSS scores first.

An Internet-facing server containing sensitive customer information represents a very different risk than an isolated development system with limited access.

Both may need patches. They don't necessarily deserve the same position in the queue.

The important lesson: Vulnerability severity tells you how dangerous a weakness can be. Your environment helps determine how dangerous it is to you.

4. AI-Assisted Hacking: South Korean Police Investigate Attacks Against 90 Organizations

We've been discussing how artificial intelligence could change cybersecurity for several years.

One concern has been that AI might allow less-experienced attackers to conduct operations that previously required larger teams or more specialized skills.

A case emerging from South Korea provides an interesting example of what that could look like.

According to South Korean police, a former penetration tester allegedly used an AI-assisted security testing framework as part of attacks targeting more than 90 organizations.

The victims reportedly included businesses, schools, hospitals, and other institutions.

Investigators allege that the attackers obtained millions of records and demanded payments from some victims to prevent stolen information from being released.

Seven suspects were arrested, according to the reports.

The allegations have not been proven in court.

The tool wasn't necessarily the problem

The framework reportedly used in the attacks was originally developed to help security professionals identify vulnerabilities.

That's an important distinction.

Penetration testing tools aren't inherently malicious. Security researchers and defenders use many of the same techniques and tools as attackers.

The difference is authorization and intent.

A legitimate penetration tester has permission to test a system.

An attacker doesn't.

Adding AI to these tools potentially changes how quickly they can operate and how much work they can perform with limited human involvement.

But we should be careful about assuming that every attack involving an AI tool was made possible by AI.

Traditional hacking tools and techniques remain highly effective.

The important question is what AI actually contributed.

Did it discover vulnerabilities that would otherwise have been missed?

Did it automate repetitive tasks?

Did it help attackers move between systems?

Or did it simply make existing techniques faster and easier to use?

Those distinctions matter when evaluating claims about AI-powered cyberattacks.

What changes for defenders?

AI-assisted attacks don't necessarily require entirely new defensive technologies.

Organizations still need strong authentication, effective vulnerability management, network segmentation, monitoring, and incident response capabilities.

But automation can compress the time defenders have to respond.

Tasks that once required substantial manual effort may increasingly be performed by automated systems.

That creates challenges for organizations whose security processes still depend on lengthy approval cycles and manual investigation.

I've written previously about the differences between AI agents and human employees, particularly when it comes to identity, accountability, and motivation.

Those questions become even more important as AI systems gain the ability to interact directly with production environments.

The important lesson: AI doesn't eliminate traditional cybersecurity risks. It can change how quickly and efficiently those risks are exploited.

Final Thoughts: Understanding Risk in a Noisy World

There's a common thread connecting this week's stories.

A vulnerability in a widely used library. A compromised software release. Critical PHP vulnerabilities being actively exploited. And attackers allegedly using AI to scale their operations.

All are legitimate cybersecurity concerns.

But they don't all represent the same level of risk to every organization.

A vulnerability with a critical CVSS score might be unreachable in your environment.

A lower-severity vulnerability might create significant problems if attackers are actively exploiting it.

A compromised software dependency might require an entirely different response than a traditional vulnerability.

And an AI-assisted attack might rely on weaknesses we've known how to address for decades.

Cybersecurity isn't simply about responding to every alarming headline.

It's about understanding which threats matter, how they affect your environment, and what you should do about them.

That takes more than a severity score.

It takes context.

Until next time, stay curious, stay informed, and stay secure.

Between The Hacks