Welcome back to Between The Hacks News, where we look beyond the headlines to understand what happened, why it matters, and what we can learn from it.

This week, we have a job interview that helped open the door to a multibillion-dollar cryptocurrency theft, attackers running up enormous bills using stolen AI credentials, cyberattacks against European refrigeration systems, compromised websites targeting mobile phones, and devices at the White House apparently renting out their Internet connections to strangers.

Five very different stories. One recurring problem: technology we trust can become a pathway for attackers.

Let's get into it.

1. A Job Interview That Cost $6.3 Billion

In September, a Binance engineer received a job offer through a legitimate recruiting platform.

The recruiter looked real. So did the company.

The first interview was with someone claiming to work in HR. It happened over live video. The interviewer shared social media profiles, photos, and enough personal detail to make the conversation feel credible.

The second interview was with the supposed CEO.

Then came the take-home coding assignment.

That is a fairly normal hiring process. The minor problem was that the company did not exist.

According to Binance's November 3 report, the assignment contained malware. The engineer downloaded it onto a work laptop, giving the attackers a foothold inside the company.

This started earlier

The September interview was not the beginning of the entire intrusion.

In June, another engineer had downloaded a tampered installer while searching for an AI coding tool. Binance detected suspicious activity, replaced the laptop, and rotated credentials. But the attackers had already learned who worked on the wallet team and how people inside Binance were connected.

That knowledge made the later recruiter approach far more convincing.

By October 20, Binance says the attackers were using the company's own internal AI tool to reach two more engineers. One of those computers held credentials that opened another door.

On October 29, the attackers used that access to reach Binance's wallet infrastructure.

According to Binance, approximately $6.34 billion in digital assets was moved during the incident.

Four months of preparation. Several compromised computers. One very expensive take-home assignment.

Binance says approximately $2.85 billion was frozen or intercepted. The company has also committed to covering the losses with its own funds.

Why this matters

I've written about North Korean operatives posing as job applicants before.

In The Spy Who Applied to Code, I covered an attempt to infiltrate cryptocurrency exchange Kraken through a fraudulent job application.

In Your Next Cyberattack Could Start with a Job Application, I explored why recruiting has become part of the corporate security perimeter.

This time, the attacker sat on the other side of the interview.

There is nothing unusual about an employee exploring another job. The danger begins when an outside organization asks that employee to download and run unfamiliar code on a corporate computer.

For employees, the lesson is simple. Keep interview assignments off work devices. Verify the company and the people involved. If you must run unfamiliar code, use an isolated environment.

For employers, assume a convincing recruiter can be part of an intrusion. Limit what developer workstations can reach. Protect credentials. Monitor internal tools, including AI systems, for unusual access.

The Binance incident was not caused by one bad click. It was a chain of small openings that eventually reached the systems that mattered.

That is usually how the expensive ones work.

Sources: Binance's November 3 incident report, Reuters, BleepingComputer.

2. Hackers Are Stealing AI Access and Leaving Companies With the Bill

Remember cryptojacking?

Attackers compromised computers and used their processing power to mine cryptocurrency. The victim paid for the electricity and computing resources while the attacker collected the proceeds.

Now there's an AI variation.

It's called LLMjacking.

Instead of stealing computing power to mine cryptocurrency, attackers steal access to cloud-based AI models and use those resources without authorization.

And the bills can be enormous.

On November 2, Google Threat Intelligence Group and Mandiant published research describing multiple LLMjacking incidents investigated during 2026.

In some cases, unauthorized AI consumption generated more than $100,000 in charges in a single day.

At some organizations, cumulative fraudulent charges reached $1 million before access was revoked.

That's a fairly expensive way to discover your API credentials have been stolen.

How does this happen?

Organizations increasingly integrate large language models into their applications and business processes.

Those integrations often use API keys, service accounts, and cloud credentials to authenticate requests.

If attackers obtain those credentials, they may be able to use the organization's AI services as though they were authorized customers.

Depending on the permissions and configuration, attackers can consume large volumes of tokens, invoke expensive models, or resell unauthorized access.

The legitimate organization receives the bill.

Google's research describes incidents across several industries, including financial services, retail, technology, and transportation.

Why this matters

We've spent years teaching organizations to protect passwords, authentication tokens, and cloud credentials.

AI doesn't change that requirement.

It adds another reason to take it seriously.

An AI API key isn't just a technical credential. It may provide access to a service that can accumulate substantial charges very quickly.

And the risk isn't limited to billing.

Depending on the integration, a compromised credential might also expose data, application capabilities, or other resources.

Organizations should treat AI credentials like other privileged secrets.

Store them securely. Limit their permissions. Rotate them when compromised. Monitor usage patterns and investigate unexpected spikes.

Set budgets and alerts, but don't assume a budget alert automatically prevents further consumption.

And avoid embedding privileged API keys in applications or repositories where unauthorized users can retrieve them.

There's also a governance lesson.

If you don't know which teams are using AI services, which models they're accessing, or how those services are authenticated, you may have an inventory problem before you have a security problem.

Sound familiar?

Source: Google Threat Intelligence Group and Mandiant: The Rise of LLMJacking.

3. European Refrigeration Attacks Spread Beyond Supermarkets

A few weeks ago, I wrote about hackers manipulating refrigeration equipment at French supermarkets.

Temperatures reportedly reached 50°C (122°F), spoiling food and forcing retailers to discard products.

My article, The French Fridge Failure, focused on the dangers of exposing management interfaces for physical equipment to the Internet.

Unfortunately, the story didn't end in France.

On November 2, supermarkets in several European countries reported similar attacks affecting refrigeration and freezer systems.

Retailers in Sweden, Belgium, and Luxembourg were among those reporting incidents.

At one Swedish supermarket, freezers reportedly reached 50°C.

That's 122°F.

Not exactly ideal ice cream storage conditions.

The attacks disrupted operations and forced retailers to discard food.

Then the story took a more concerning turn.

From frozen food to blood storage

On November 4, French authorities disclosed that cyberattacks had affected refrigeration monitoring and control systems at three regional facilities associated with the French Blood Establishment.

The good news is that the blood supply was reportedly not affected.

Staff received alerts and moved blood products to refrigeration units that weren't connected to the compromised systems.

That response is worth emphasizing.

The organization had a way to detect the problem and protect the products despite the disruption.

Authorities are still investigating the technical details, and the available evidence doesn't establish that all the refrigeration incidents involved the same attackers or vulnerabilities.

The concern is not limited to Europe.

The Pentagon is also investigating refrigeration failures that spoiled food at at least six U.S. military commissaries in August. Investigators are treating the incidents as possible cyberattacks, although they have not publicly confirmed the cause or connected them to the European activity.

Different continent. Uncomfortably similar symptoms.

Why this matters

This is why I keep emphasizing the difference between Internet-connected and Internet-accessible.

A refrigeration controller may legitimately need to communicate with a remote monitoring service.

That doesn't mean its administrative interface should be reachable by anyone on the Internet.

Remote connectivity can provide enormous operational benefits.

But connectivity must be designed around appropriate authentication, access restrictions, monitoring, and separation of critical functions.

The blood-storage incident also illustrates the importance of resilience.

Security isn't only about preventing attackers from reaching a system.

It's about limiting the consequences when something goes wrong.

Independent temperature monitoring, local alarms, and procedures for transferring sensitive products can make the difference between a serious incident and a much larger emergency.

A firewall is useful.

A backup plan is useful too.

Preferably, you have both.

Sources: Reuters, November 2, Reuters, November 4, Defense News.

4. Your Phone Could Be Attacked Just by Visiting a Website

Most people understand that downloading suspicious applications or clicking unfamiliar links can be dangerous.

But what if you visit a legitimate website and the website itself has been compromised?

That's the scenario described in new research from French cybersecurity company Sekoia.

On November 4, researchers disclosed a campaign they call Poisoned Source, which they linked to the Russia-associated threat actor APT29.

The attackers used compromised websites, deceptive domains, and a compromised web analytics component to deliver malicious JavaScript.

The code collected information about visitors' browsers and mobile devices.

Depending on the device and software version, the attack infrastructure could deliver an exploit chain targeting iOS or Android.

Some of those exploits required no additional user interaction after the affected page loaded.

No suspicious attachment.

No application installation.

Just visiting a compromised website with a vulnerable device.

But there's an important detail

The campaign used vulnerabilities for which patches were already available.

Security researchers sometimes call these N-day vulnerabilities, meaning the weaknesses were already known rather than previously undisclosed zero-days.

That distinction matters.

It means devices running current, patched software may already have protection against the specific exploit chains researchers identified.

The attackers targeted particular combinations of browser and operating-system versions, not every iPhone or Android device.

The reported payloads could collect sensitive information, including browser cookies and, under some conditions, additional device data.

Stolen session cookies can be particularly valuable because they may allow attackers to impersonate authenticated users without knowing their passwords.

Why this matters

This is a good reminder that a legitimate website isn't automatically a safe website.

Attackers don't always need to convince you to visit a malicious domain.

Sometimes they compromise a website you already trust or a third-party component that website loads.

For individuals, the most important defense is keeping your phone and browser updated.

For organizations, mobile device management, security monitoring, and policies governing access to sensitive systems can help reduce exposure.

And for website operators, third-party scripts deserve scrutiny.

An analytics script may seem harmless, but code delivered through that script runs in visitors' browsers.

That's a meaningful trust relationship.

The broader lesson is familiar.

Software updates matter, even when there isn't a dramatic headline telling you to install them.

Sources: Sekoia research coverage, The Hacker News, Help Net Security.

5. The White House May Be Renting Out Its Internet Address

Residential proxy networks let customers route their Internet traffic through someone else's connection.

That can make the customer's activity appear to come from an ordinary home, business, or mobile device instead of a data center or known VPN.

According to research reported by KrebsOnSecurity, several Internet addresses associated with the White House appeared as exit points for residential proxy services.

In plain English, strangers may have been able to rent an Internet connection that looked like it came from the White House.

That is not the sort of side hustle anyone wants on a government network.

How does this happen?

Residential proxy software can arrive through malware, but it may also be bundled into an application or software component. A user installs something that appears useful or harmless. Somewhere in the process, the device becomes part of a commercial proxy network.

The owner may receive nothing. The proxy operator receives a network connection it can sell.

Researchers at Parallax observed the White House-associated proxy activity between October 5 and November 3. Other proxy-detection services reportedly identified the same addresses as residential proxy exits.

The researchers did not identify the devices or people involved. They also did not establish that classified systems were compromised. The activity could involve staff devices, personal phones, or another system using the network.

That uncertainty matters.

But so does the activity.

From Internet weapon to rented identity

I've written about IoT botnets for years.

In Attack of the Light Bulbs, I explained how compromised cameras, routers, and other connected devices can be combined into an Internet weapon. More recently, in Unlimited Access: Every Device on Your Network Can Talk to the Internet, I focused on the visibility problem. Most of us do not know where our devices are connecting or what they are doing in the background.

This is the next version of that problem.

Traditional IoT botnets turned devices into weapons. Residential proxy networks turn them into rented identities.

The device's processing power may not be the valuable part. Its trusted Internet address is.

Why this matters

Traffic leaving a White House address carries a very different reputation and risk than traffic leaving an obvious hosting provider.

Unknown customers could use that address for scraping, account abuse, fraud, reconnaissance, or other activity. Poorly secured proxy software may also create opportunities to reach resources that should never be exposed to the proxy customer.

For organizations, blocking known malicious destinations is not enough. Security teams need visibility into outbound connections, installed applications, browser extensions, mobile software, and devices that quietly join external networks.

For individuals, be suspicious of free applications that promise rewards for sharing bandwidth. Review installed software and permissions. Keep routers and connected devices updated. Separate less-trusted devices from computers and systems that matter.

Your Internet connection has value.

If you are not paying for the product, you may be the product. And apparently, your IP address may be available by the hour.

Sources: KrebsOnSecurity, Parallax.

Final Thoughts

This week's stories illustrate how cybersecurity risks emerge from ordinary activities.

A software engineer interviews for a job.

A company integrates AI into its applications.

A supermarket remotely monitors its refrigeration equipment.

Someone visits a familiar website on their phone.

Someone installs an ordinary-looking app or connects a device without knowing it has joined a proxy network.

None of those activities is inherently suspicious.

The risk appears when an attacker finds a way to exploit the trust or access involved.

And that's why security can't be reduced to a checklist of vulnerabilities.

We need to understand how people use technology, how systems communicate, what privileges they have, and what happens when something fails.

The Binance attack is particularly interesting because it combined several weaknesses over months. The attackers didn't need every defense to fail simultaneously. They needed enough opportunities to eventually reach the systems that mattered.

The refrigeration incidents remind us that cybersecurity can have physical consequences.

LLMjacking shows that stolen credentials can now produce substantial financial losses without stealing traditional financial information.

And the mobile attacks demonstrate why keeping software updated remains one of the simplest and most important security practices.

The White House proxy activity shows that a compromised device can lend attackers something beyond computing power: the trust attached to its Internet address.

Different attacks. Different technologies.

Many of the same fundamental lessons.

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

Between The Hacks

CVSS gives us a severity score. EPSS estimates the likelihood of exploitation. CISA’s Known Exploited Vulnerabilities catalog tells us when exploitation has been observed.

Put all three on a dashboard and they can look like competing answers to one question: What should we fix first?

They aren’t.

Each signal answers a different question:

• CVSS: How severe could this vulnerability be?

• EPSS: How likely is exploitation activity in the next 30 days?

• CISA KEV: Has CISA determined that it has been exploited in the wild?

Then your environment supplies the part none of them can: whether you run the affected product, whether an attacker can reach it, and what the system means to your organization.

CVSS: How Bad Could It Be?

The Common Vulnerability Scoring System provides a common language for describing technical severity.

CVSS 4.0 organizes its metrics into four groups: Base, Threat, Environmental, and Supplemental. The Base score is the number most people see. It describes the vulnerability’s inherent characteristics, but it doesn’t tell you whether attackers are exploiting it, whether your system is exposed, or even whether you use the affected software.

FIRST, the Forum of Incident Response and Security Teams, maintains CVSS and is explicit about this: a CVSS Base score measures severity, not risk.

Think of CVSS as an inspection of a defective lock. It describes the defect, what an intruder may need to use it, and what could happen if the attempt succeeds. It doesn’t tell you which building has the lock, who can reach the door, or what’s behind it.

EPSS: What Are Attackers Likely to Try Next?

The Exploit Prediction Scoring System estimates the probability that exploitation activity for a published CVE will be observed in the next 30 days.

EPSS reports two values:

• Probability is the model’s estimate of exploitation activity in the next 30 days. A score of 0.05 means 5%.

• Percentile is a relative ranking. A vulnerability in the 90th percentile has a higher probability than 90% of the vulnerabilities currently scored.

EPSS scores are recalculated daily and can change as new information appears. That makes them useful for sorting large queues, especially before exploitation is confirmed.

EPSS doesn’t measure damage, and it doesn’t know whether you’re affected. FIRST also warns against multiplying EPSS by CVSS and calling the result risk. The math looks tidy. The meaning isn’t.

CISA KEV: Has Someone Used It?

CISA’s Known Exploited Vulnerabilities catalog identifies vulnerabilities for which there is reliable evidence of exploitation in the wild.

KEV is not a forecast. It means the vulnerability has crossed an important line from possible to observed.

For CISA to add a vulnerability, it must have a CVE identifier, reliable evidence of active exploitation, and a clear remediation action such as an update or mitigation.

If a vulnerability affecting a product you use appears in KEV, find out where that product is running and how exposed it is. Quickly. KEV still doesn’t know whether the affected function is reachable or whether the system runs payroll or displays the lunch menu.

CISA isn’t the only organization maintaining a known-exploited-vulnerability catalog. VulnCheck operates a broader KEV dataset intended to identify exploitation earlier. ENISA maintains an EU KEV Catalogue focused on attacks targeting entities in the European Union. Because the catalogs use different sources and criteria, a vulnerability may appear in one before, or without, appearing in another. Here, “KEV” means CISA’s catalog unless otherwise noted.

One Vulnerability, Three Signals

Consider CVE-2026-87902, a vulnerability in WordPress Core that, under certain conditions, could lead to remote code execution. WordPress fixed it in version 7.1.2 and backported fixes to older release branches.

CVSS

The vulnerability has a CVSS 3.1 score of 8.1, High, and a CVSS 4.0 score of 9.2, Critical. That isn’t a contradiction. The versions use different metric structures. Both say the potential technical impact is serious.

EPSS

On October 31, 2026, FIRST’s EPSS API reported a probability of 95.769% and a percentile of 99.872%. That is a dated snapshot because EPSS changes daily.

KEV

CISA added the vulnerability to KEV on September 25, 2026, after exploitation was observed in the wild.

At that point, debating whether 8.1 is less alarming than 9.2 becomes an excellent way to spend time while someone else attacks the server. If you run an affected version, determine where it is and whether the vulnerable path is reachable.

Where EPSS Adds Something Different

EPSS is especially useful when a vulnerability isn’t in KEV.

CVE-2026-73034, for example, affects DB-GPT, an open-source platform for building data applications and AI agents. It carried high CVSS scores, and public proof-of-concept material existed. As of November 2, 2026, it was not listed in CISA’s KEV catalog.

On September 27, 2026, FIRST reported an EPSS score of 5.703%, placing it at about the 93rd percentile. Neither a proof of concept nor an EPSS score proves exploitation in the wild. Together, they can still justify prompt investigation when the affected service is exposed to untrusted users.

That is where EPSS earns its place. It helps teams sort vulnerabilities that haven’t crossed KEV’s evidence threshold.

Your Environment Makes the Decision

Assume the affected WordPress version appears on three systems: a public website processing customer information, an intranet site, and an isolated lab server.

All three have the same CVE, CVSS scores, EPSS score, and KEV status. Their risk isn’t the same.

The public server has the greatest exposure and supports an important service. The intranet server may be less exposed, but internal doesn’t mean safe. The lab server may be isolated or shut down while production systems are fixed first.

And if you don’t run WordPress at all, this vulnerability isn’t in your environment. A scary score can’t compromise software you don’t have. Inventory occasionally gets to be the hero.

I covered the broader process in How to Prioritize Vulnerability Remediation (Without Losing Your Mind). For this decision, ask four questions:

• Do we run the affected product and version?

• Can an attacker reach the vulnerable function?

• What data, systems, identities, or business processes are connected to it?

• Can we patch, mitigate, isolate, monitor, or shut it down?

Three Signals, Not One Answer

• CVSS describes technical severity.

• EPSS estimates near-term exploitation probability.

• KEV records known exploitation.

• Your environment supplies exposure and business impact.

The goal isn’t to find one magic number that makes the decision for you. Security has enough magic numbers already.

Ask each source the question it was designed to answer. Then decide which problem needs to be fixed first.

Critical vulnerabilities. Emergency patches. Exploitation in the wild. Millions of potentially affected systems. New names ending in “2Shell.” And, inevitably, headlines declaring a “Black October” for the Internet.

Some of those warnings describe real threats. Brotli and PHP2Shell deserve serious attention. Organizations should identify affected systems, understand their exposure, and apply the available fixes. But there is a second problem hiding inside all that urgency.

When every vulnerability is presented as an emergency, the word emergency stops helping.

Cybersecurity has a risk-communication problem. We routinely collapse severity, exploitability, exposure, prevalence, and business impact into a single frightening message: patch everything immediately. That may generate clicks, product interest, and executive attention. It does not necessarily help defenders decide what to do first.

The Difference Between Serious and Urgent

A vulnerability can be serious without being urgent for every organization.

CVSS tells us something useful about how severe a vulnerability could be under defined conditions. It doesn’t know whether you run the affected product, whether the vulnerable function is reachable, whether the system is exposed to the Internet, whether an attacker has a working exploit, or what the compromised system could reach next.

That distinction matters because defenders do not patch in a laboratory. They patch production systems with maintenance windows, dependencies, uptime requirements, limited staff, and competing risks.

I wrote about this earlier in How to Prioritize Vulnerability Remediation (Without Losing Your Mind). Risk lives at the intersection of exposure, exploitability, and impact. A critical vulnerability on an isolated test system may be less urgent than a medium-severity vulnerability on an Internet-facing identity server that attackers are actively exploiting.

Both vulnerabilities may need to be fixed. They don’t necessarily deserve the same position in the queue.

What October Actually Taught Us

Several recent vulnerabilities and incidents give us useful examples of why context matters.

Brotli: A Real Emergency, With Important Boundaries

CVE-2026-111497 affects the Brotli decoder, a widely used compression component. Specially crafted compressed input can cause memory corruption and may allow information disclosure, denial of service, or arbitrary code execution in an affected application.

This isn’t imaginary risk. Microsoft issued out-of-band updates for affected .NET versions, Amazon Linux published fixes for affected packages, and CISA added the vulnerability to the Known Exploited Vulnerabilities catalog on October 27. Tenable’s analysis shows the flaw reaches well beyond Node.js, including .NET, Bun, Envoy, Istio, and Python HTTP clients.

Those are strong signals. Known exploitation, untrusted remote input, and a component embedded across several software ecosystems make this an urgent investigation.

But “Brotli is everywhere” isn’t the same as “everything using Brotli is remotely exploitable.” An application must include a vulnerable implementation and process attacker-controlled Brotli data through the affected code path. Some products bundle their own copy. Others use a system library. Some expose decoding to untrusted input. Others don’t.

The useful message is: move quickly, determine where the risk is real, and prioritize exposed applications that decode untrusted content.

PHP2Shell: Exploitation Changes the Conversation

The two PHP vulnerabilities known as PHP2Shell, CVE-2026-109618 and CVE-2026-109619, also deserve urgency.

Amazon Threat Intelligence reported attempts targeting its MadPot sensors beginning October 17, four days before public disclosure. AWS later described broad exploitation attempts after patches and proof-of-concept material became public. The vulnerabilities can enable unauthenticated remote code execution under affected conditions, and the complete fix is to upgrade to a patched PHP release.

Since those initial warnings, Dream Research documented a campaign that chained PHP2Shell with a Linux privilege-escalation vulnerability to compromise 24 PAN-OS firewalls and an internal management server. Three of the systems were associated with a U.S. government-affiliated environment. The attacker reportedly used an exposed management interface as the starting point and later conducted Active Directory-related activity.

That is real impact, not simply scanning or activity against a honeypot. It is materially different from a theoretical critical vulnerability with no known exploitation. Organizations should patch supported versions, identify unsupported installations, review available indicators, and pay particular attention to forgotten websites and management interfaces exposed to the Internet.

In its October 29 update, Unit 42 said approximately 0.02% of Palo Alto Networks’ global installed base had Internet-facing management interfaces configured and were impacted. That is a narrow but meaningful exposure condition, not evidence that the broader PHP population faced the same level of risk.

Still, the number of websites that use PHP is not the number of vulnerable, exposed, exploitable websites.

As of October 23, Censys counted about 4.18 million hosts and 67.6 million web properties running PHP, with no filter for vulnerable versions. Those totals show how widely PHP is deployed, not how many organizations are vulnerable or exploitable, and the two counts should not be added together.

A large denominator tells us the potential blast radius. It does not tell an individual organization its actual exposure.

PHP2Shell is a genuine threat. Inflating the affected population does not make it more genuine. It makes the communication less precise.

VMware: One Advisory, Several Different Risks

Broadcom’s VMSA-2026-0006 is an almost perfect example of why we should read past the advisory headline.

The advisory is rated Critical because it includes two vCenter vulnerabilities scored as high as 9.8 and an ESX VMXNET3 flaw that can allow a guest administrator to execute code on the host. Those are serious issues.

The same advisory also includes CVE-2026-41709, an insufficient logging vulnerability in ESX with a CVSS score of 2.7.

If someone reports that “VMware released a critical advisory for CVE-2026-41709,” the words sound plausible but the meaning is wrong. The advisory is critical. That individual CVE is low severity. When scanners, bulletins, and headlines inherit the most alarming label available, five different risks arrive as five identical emergency tickets.

Binance: What a Real Emergency Looks Like

Late in the month, Binance disclosed unauthorized withdrawals with an estimated impact of approximately $6.3 billion. The company paused withdrawals, worked with partners to freeze affected assets, engaged law enforcement, and committed to covering the losses.

That isn’t a vulnerability score, a theoretical install count, or a prediction about what might happen. Money moved. Services were interrupted. Investigators began tracing billions of dollars. That is a material security emergency.

Binance initially said a compromised DevOps engineer’s laptop may have allowed an attacker to reach a service container and submit unauthorized withdrawal transactions. Later reporting indicated that investigators had identified additional points of breach. Until the postmortem is complete, we should resist compressing a multistage incident into a story about one employee’s laptop.

The useful questions involve authorization boundaries, transaction controls, separation of duties, monitoring, and how access to one operational system could produce consequences of that magnitude.

AI Changes the Economics, Not the Fundamentals

Cybersecurity has never depended on flawless systems. We have always operated with forgotten servers, overly broad permissions, brittle integrations, weak processes, and controls that work until an unexpected condition appears.

What limited some of the damage was the cost of finding and exploiting those weaknesses. Attackers needed enough knowledge, time, infrastructure, and persistence to examine a target and develop a useful path through it.

AI reduces several of those costs.

It can help more people understand unfamiliar technologies, automate reconnaissance, analyze large amounts of technical information, and test potential attack paths more quickly. Anthropic recently reported that an unreleased research model developed five exploit chains against major browsers and operating systems. Its Chrome research resulted in 62 patched CVEs, including sandbox escapes.

Dream Research found Claude Code and an AI-enabled offensive security platform in the PHP2Shell attacker’s environment. Dream said it had no direct evidence that the AI tools were used to write the exploit or scripts, though the structure and style of about 40 scripts suggested AI-assisted development. It also concluded the operation did not appear to be fully autonomous.

AI did not invent insecure software, and it doesn’t turn every inexperienced attacker into a nation-state operator. It increases the number of people who can examine our existing weaknesses and the speed at which they can do it.

That doesn’t mean the sky is falling. It means relying on attacker scarcity is becoming a poor security strategy.

The Incentives Behind the Alarm

No single group created this problem. The incentives simply line up across the industry.

Vendors want customers to install fixes quickly. Researchers and security companies compete for attention and business. Media outlets compete for readers, and “potentially affects millions” travels farther than “exposure depends on configuration.”

That doesn’t mean the research is wrong or the warning is dishonest. It means nearly every stage of the communication chain benefits from emphasizing the largest plausible impact. Very few participants are rewarded for saying, “This is important, but we still need to learn whether it matters to you.”

Names and logos amplify the effect. They can help defenders discuss a complicated weakness, but they also turn it into a media event. “Black October” does the same thing by bundling unrelated vulnerabilities, patches, and incidents into one ominous narrative. That may describe how the month felt. It isn’t a defensible way to prioritize work.

KEV Is Powerful, but It Is Not the Entire Risk Model

CISA’s Known Exploited Vulnerabilities catalog is one of the most valuable prioritization signals we have. If a vulnerability is in KEV, defenders should treat that as evidence that exploitation is not merely theoretical.

But a KEV listing still answers only one question: has reliable evidence shown exploitation in the wild?

It doesn’t tell you whether the vulnerable product exists in your environment, whether the affected function is reachable, whether the system is exposed, what privileges an attacker would gain, or what business process could be disrupted.

KEV should raise priority. It should not replace asset context.

That is consistent with the framework I have used throughout Between The Hacks. Start with what is exposed. Add evidence of exploitation. Understand the potential impact. Then consider the controls already in place and the cost of remediation.

A Better Way to Communicate Vulnerability Risk

Security teams can improve the conversation by separating five questions that often get compressed into one score:

1. Are we affected? Do we actually run the vulnerable product, component, or version?

2. Are we exposed? Can an attacker reach the vulnerable functionality with the access they are likely to have?

3. Is exploitation practical? Is there a working exploit, evidence of active exploitation, or a realistic path to weaponization?

4. What happens next? What data, systems, identities, or business processes become reachable after compromise?

5. What can we do now? Is there a patch, mitigation, isolation option, detection, or compensating control?

Then communicate the answer in plain language.

“Critical, patch immediately” is easy to write. “Actively exploited on the Internet, present on three public servers, remote code execution possible, patch available, no evidence of compromise” is a decision.

Leaders also need uncertainty stated clearly. If we do not know whether exploitation is reliable, say that. If an install count represents potential presence rather than confirmed exposure, say that. If a vendor advisory contains vulnerabilities with very different preconditions and impacts, separate them.

Precision does not weaken an urgent message. It gives the message credibility.

Do Not Confuse Skepticism With Complacency

There is a risk in writing an article like this. Some people will hear “not every vulnerability is an emergency” and interpret it as permission to delay patching.

That isn’t the argument.

Brotli and PHP2Shell show why organizations need fast inventory, rapid triage, and the ability to deploy fixes under pressure. The time between disclosure and exploitation can be measured in hours, and sometimes exploitation begins before public disclosure. The volume of new vulnerabilities is also growing, a problem I discussed in The Mythos Discovery.

We need to move faster. But speed without prioritization is just panic with a ticketing system.

There’s another cost to calling everything an emergency: people get tired.

Security teams don’t have unlimited time or attention. Every emergency patch requires someone to identify what’s affected, understand the exposure, test the fix, negotiate downtime, deploy the update, and verify that nothing broke.

If everything is a P1, the most dangerous vulnerability competes with hundreds of merely severe findings. Maintenance windows fill up. Leaders lose confidence in security reporting. Eventually, “emergency” starts to mean “we haven’t evaluated it yet.”

The confirmed PHP2Shell campaign doesn’t prove that the largest predictions were correct, just as a limited number of confirmed victims doesn’t prove the warnings were unnecessary. Patching and existing defenses may have prevented some of the feared damage. A crisis that was successfully managed can look, in hindsight, like a crisis that never existed.

The answer isn’t to stop sounding alarms. It’s to make them more useful. Tell defenders what’s being exploited, what makes exploitation possible, which systems are exposed, and what evidence would justify interrupting everything else.

That’s how we keep genuine warnings from being ignored.

Final Thoughts

October was not quiet. Several of the month’s vulnerabilities deserve immediate attention, and organizations that run affected, exposed systems should act.

But the lesson of “Black October” should not be that the Internet survives only because everyone patches everything at once.

The lesson is that cybersecurity needs a better vocabulary for risk.

CVSS describes severity. KEV identifies known exploitation. Install counts suggest reach. Vendor advisories explain affected products and fixes. Researchers add technical detail. Headlines help people notice.

None of those signals, by itself, tells you what your organization should do first.

That takes context. What do we run? What is exposed? What is being exploited? What matters to the business? What can an attacker do next?

Those questions are less dramatic than “Is this the next global cyber emergency?”

They are also the questions that keep organizations secure.

Patch with purpose. Communicate with precision. Save the word emergency for the moments when it helps people make a better decision.

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

Inside was an IBM ThinkPad running NetStumbler and a PCMCIA Wi-Fi card. A cable ran from the wireless card to the external antenna on the roof, while a Garmin GPS sat on the dashboard.

I wasn’t trying to connect to anyone’s wireless network. I wanted to see what was already being broadcast into the air around me.

Wi-Fi was still relatively new, and I was curious about how securely people were deploying it. So I drove around my neighborhood and the surrounding area in Pennsylvania, collecting information about the wireless access points I encountered and correlating those observations with GPS coordinates.

I eventually mapped the results using Microsoft Streets and published the research as a few web pages on my personal website at the time.

Then, for the most part, I forgot about it.

Nearly 25 years later, I found the files again.

And they provide a fascinating snapshot of what Wi-Fi security looked like in its early years.

Wardriving Before It Was Commonplace

Today, detecting nearby Wi-Fi networks seems almost mundane. Our phones, laptops, watches and countless other devices continuously interact with wireless technologies.

In the early 2000s, doing this deliberately required a little more effort.

NetStumbler detected the nearby wireless networks, the GPS recorded where my car was when each one was detected, and Microsoft Streets, a desktop mapping program that worked much like Google Maps does today, let me plot the results.

My resulting dataset included the network name, or SSID, the BSSID (the MAC address identifying the access point radio), GPS coordinates, and whether the network appeared to be using Wired Equivalent Privacy (WEP), the Wi-Fi encryption standard of the time.

That was wardriving.

At the time, wardriving generally meant detecting and mapping wireless networks, not connecting to them. Over the years, the term has sometimes been used more broadly, often as shorthand for finding and then attacking vulnerable Wi-Fi networks.

I wasn’t authenticating to these networks or attempting to access them. I was observing wireless network information being broadcast around me.

And there was a lot to observe.

More Than 80 Percent Weren’t Using WEP

One of my surveys covered Hampden Township, Pennsylvania.

I detected 102 wireless access points.

Only 15 were identified as using WEP.

The other 87, or 85.3 percent, did not appear to be using WEP encryption.

I also conducted a broader survey around the Harrisburg area.

That dataset contained 142 wireless access points.

Only 24 were identified as using WEP.

The remaining 118, or 83.1 percent, did not appear to be using WEP encryption.

The listed GPS coordinates show the position of my car when a wireless network was detected, not necessarily the location of the access point. Detection distance varied based on the quality of the antenna, the access point’s equipment and transmit power, terrain, buildings, interference, and other conditions. Without signal-strength measurements or readings from multiple positions, an access point could have been right next to my car or much farther away.

Looking at the data today, some of the network names are almost as interesting as the security statistics. There are plenty of linksys, default, Wireless, WLAN, Intel Gateway and MSHOME entries. Anyone who worked with consumer networking equipment in that era will probably recognize some of those names, and perhaps experience an unwelcome flashback.

At first glance, the security lesson seems obvious.

More people should have turned on WEP.

Except there was a problem.

The Security They Weren’t Using Was Already Broken

WEP was intended to give wireless networks privacy roughly comparable to that of a wired network.

By the time I could have conducted my wardrive, researchers had already demonstrated serious problems with that promise.

In 2001, Nikita Borisov, Ian Goldberg and David Wagner published research documenting fundamental security weaknesses in WEP. Their work showed that WEP failed to provide the level of confidentiality and security its designers intended.

Then things moved quickly.

Cryptographers Scott Fluhrer, Itsik Mantin and Adi Shamir identified weaknesses involving RC4, the stream cipher used by WEP, and the way keys were constructed.

In August 2001, researchers at AT&T Research tested a production network with its administrator’s permission and recovered a 128-bit WEP key using passive observation.

That was before the earliest possible date of my wardriving research.

So my old research captures an interesting moment in cybersecurity history.

More than 80 percent of the wireless networks I detected weren’t using WEP. Yet the security mechanism they weren’t using had already been shown to be fundamentally inadequate. It was still better than broadcasting everything in the clear, but the margin of victory was not especially comforting.

Telling everyone to simply “turn on security” wasn’t going to solve the problem.

The security itself needed to get better.

This Wasn’t Just Pennsylvania

My research wasn’t scientific, and it shouldn’t be treated as representative of Wi-Fi deployment everywhere in 2001 or 2002.

But wardriving itself was emerging as a security research technique around this time. In April 2001, security researcher Peter Shipley was documented driving around San Francisco looking for wireless networks with a laptop, wireless card, GPS and an external antenna on his car.

The resemblance to my own setup is striking. It shows what an effective wardriving rig looked like during that brief period, as Wi-Fi adoption moved faster than Wi-Fi security.

Wi-Fi Security Catches Up

Fortunately, WEP wasn’t the end of the story.

In October 2002, the Wi-Fi Alliance announced Wi-Fi Protected Access, or WPA, as a stronger interim replacement for WEP. WPA-capable products began appearing in 2003.

The IEEE subsequently completed the more comprehensive 802.11i security standard in 2004, and the Wi-Fi Alliance began certifying WPA2 products that year.

Over time, wireless security improved dramatically.

That progression is worth remembering because it’s easy to look back at early Wi-Fi security and wonder how anyone could have deployed a wireless network without encryption.

But Wi-Fi itself was new.

The Technology Changes. The Cycle Doesn’t.

Looking through these files nearly 25 years later, what strikes me isn’t how primitive Wi-Fi security was.

It’s how familiar the pattern feels.

A transformative technology arrives.

Adoption accelerates.

People find new ways to use it.

Researchers begin testing assumptions and finding weaknesses.

Security practices race to catch up.

Standards change. Products improve. What once required specialized knowledge eventually becomes standard.

We watched the same cycle unfold with cloud computing. Organizations moved applications and data to the cloud, often faster than their security practices could follow. Misconfigured storage, exposed services, and overly broad permissions became familiar problems. Over time, the tools improved and cloud security matured.

Now we’re watching another version of the cycle with AI.

AI systems are being connected to sensitive data, business applications, and tools that can take action. Researchers are finding problems such as prompt injection, data leakage, excessive permissions, and unpredictable agent behavior. The vulnerabilities are different, but the pattern is not.

And sometimes security isn’t merely playing catch-up.

Sometimes we discover that the security controls we started with were built on assumptions that don’t survive contact with the real world. WEP was one of those controls.

Nearly 25 years ago, one way we tested those assumptions was to put an antenna on the roof of a car, connect it to a laptop, turn on a GPS and start driving.

Today, researchers may be testing cloud services or probing AI agents instead.

The technology changes.

The cycle doesn’t.

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

The common thread is not novelty. It is exposure: forgotten systems, trusted software, and automation moving faster than defenders can inventory what they actually run.

Two Critical PHP Flaws—and the Systems Nobody Remembers

On October 21, the PHP project released emergency fixes for CVE-2026-109618 and CVE-2026-109619. Both are critical, rated 9.2 under CVSS 4.0, and can allow unauthenticated remote code execution. The PHP team says all installations serving web requests may be at risk, with the highest demonstrated risk in Apache mod_php. There is no complete workaround: installing the patch is the only safe choice.

Fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 8.1 and older are no longer supported, although some distribution and long-term-support vendors may provide updates.

The urgency spilled well beyond security teams. Britain’s NCSC advised organizations that could not patch immediately to consider taking affected systems offline, while government services in Finland and several other countries were temporarily shut down as a precaution. Those outages were not evidence that every system had been compromised; they showed how seriously operators treated the window between disclosure and patching.

The hard part is not reading the advisory. It is finding the servers.

That is where a security problem often becomes an archaeology project.

A widely shared post from IT Unhinged captured the scene perfectly: the emergency inventory turns up a forgotten WordPress site, an old tool under someone’s desk, a server marked “DO NOT TOUCH,” and a PHP 5.4 system that nobody owns but that somehow still prints the warehouse labels.

It’s satire, but anyone who has worked in IT for a while has met that server. Maybe not the label printer, exactly, but something just as fragile, mysterious, and business-critical.

So yes, patch quickly. But do not let the 9.2 score make every system look equally urgent. Ask three questions first: Is it facing the Internet? Does it contain sensitive data? Can it reach systems or data that are sensitive?

A vulnerable public WordPress site is a much bigger risk than the exact same PHP version inside an isolated development lab used by a few people. Start with the systems an attacker can reach and the systems that can take an attacker somewhere valuable. Then confirm the version is actually running in production, not the version the inventory says should be there.

I wrote more about that distinction in Vulnerability Prioritization: Fix What Matters First. The short version: update, restart, verify the running version, and keep looking for the systems nobody remembered to put on the list.

Read more: PHP’s security release notice, the OOM-corruption advisory, and the stale-state advisory.

A 16-Year-Old Broadcom Wi-Fi Flaw Is Still in Routers

The router in the corner may be quiet, but that doesn’t mean it has stopped aging.

Security researcher Quentin Kaiser found a flaw in Broadcom’s legacy Wi-Fi Protected Setup implementation that dates back to at least 2010. An attacker within wireless range may be able to trigger it without knowing the network password or completing WPS enrollment, potentially leaking information or running code on the router.

That “within wireless range” detail matters. This is not the same as an attacker anywhere on the Internet reaching every Broadcom-powered router. But old networking code has a habit of lingering. Broadcom began replacing the affected component in newer software in 2018, while vulnerable code remained in deployed devices. Kaiser confirmed affected equipment at three Belgian Internet providers and estimates that millions of access points from multiple vendors may be impacted.

The chip alone does not answer the question; the exact firmware does. There is no CVE, and switching off WPS in the settings may not stop the vulnerable parser. Ask the router vendor or your Internet provider whether your exact model and firmware received the fix. If the device is unsupported and cannot be updated, it is time to replace it.

Read more: Kaiser’s technical research and disclosure timeline and the WPSplinter public documentation.

One Hacker, 1,200 Targets, and an Army of AI Agents

We spend a lot of time talking about how AI can help defenders. This is the other half of that conversation.

An attacker reportedly used the open-source Cairn AI orchestration platform to probe more than 1,200 websites and gain access to sites belonging to more than 100 companies. Security researcher Snorre Fagerland was able to watch the activity because the operators had accidentally exposed their own Cairn control panels to the Internet. There is a certain irony in that, but the larger story is scale.

The attacker gave the agents short objectives and let them gather information, map related infrastructure, test weaknesses, and attempt commands. The human still chose the targets and the goal. The agents made the familiar work faster, cheaper, and repeatable across hundreds of sites.

And “cheaper” is doing a lot of work in that sentence. Fagerland estimated that the entire campaign cost about $5,000 in AI tokens—roughly $50 for each successful compromise. That is not a confirmed invoice, but even as an estimate it changes the economics. An attacker no longer has to choose between careful, skilled work and broad automation. For about the cost of a decent laptop, this one appears to have done both.

This is not a reason to throw out the defensive playbook. It is a reason to execute it faster. Know what is exposed, log service and application activity, patch the reachable paths first, and make repeated automated probing noisy enough that somebody notices.

Read more: Tom’s Hardware’s report based on the Reuters investigation and SecurityWeek’s coverage.

The Certificate Authority Keys That Were Basically Guessable

Certificate authorities sit near the center of Internet trust. When your browser shows the padlock, it is relying on one of these organizations to vouch for the certificate presented by the website.

So it is difficult to overstate how bad it sounds when a certificate authority’s private keys can be recovered by trying numbers smaller than 256.

On October 17, a security researcher reported that the private keys behind eight intermediate certificates operated by India-based eMudhra had been compromised. The keys had not simply been stolen. The P-384 private values were tiny integers, effectively all zeroes except for the final byte, which meant they could be recovered almost instantly from the public certificates. Mozilla independently reproduced the result without being told how the researcher had done it.

Six of the affected intermediates could issue TLS certificates. In the wrong hands, those keys could have been used to create fraudulent certificates for websites the attacker did not control, the digital equivalent of being able to print convincing passports for anyone.

The response was fast. Chrome and Mozilla blocked the affected certificates, eMudhra revoked all eight, and Mozilla removed the issuing root from its trust store to protect users who might not receive browser revocation updates. Chrome also found no certificates chaining to the six TLS-capable intermediates in Certificate Transparency logs before they were blocked. That does not prove the keys were never abused, but it sharply limits what would have worked in modern browsers.

This does’t mean the browser padlock is suddenly meaningless. It means the padlock depends on a long chain of organizations, hardware, software, ceremonies, and human checks working as intended. Here, an error in that chain produced keys so weak that “private” was more of an aspiration than a technical fact.

Read more: Mozilla’s incident announcement and response guidance and the public technical investigation.

BTH News is a roundup of interesting cybersecurity stories, technology developments, and occasional oddities from around the world. Thanks for reading!

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

Microsoft Fixes More Than 1,400 Vulnerabilities. Now What?

Remember when Patch Tuesday meant a manageable collection of security updates?

Microsoft released fixes for more than 1,400 vulnerabilities this week, setting a new record. BleepingComputer counted 1,411 vulnerabilities, while CrowdStrike reported 1,413. Both reported three zero-days, including one that was already being exploited.

That's a lot of vulnerabilities. And an awful lot of work for the people responsible for keeping systems patched.

But I think the more interesting question is what organizations are supposed to do with all this information.

I've written about this before in How to Prioritize Vulnerability Remediation (Without Losing Your Mind). My position hasn't changed. Organizations need to stop treating CVSS scores as their primary patching strategy.

A critical vulnerability on an isolated system isn't necessarily a greater risk than a medium-severity vulnerability on an Internet-facing server that's actively being exploited.

And with AI accelerating vulnerability discovery, the problem is only getting bigger.

In The Mythos Discovery, I discussed how AI is challenging traditional vulnerability disclosure and remediation processes. Microsoft's latest Patch Tuesday is another reminder that the volume of vulnerabilities is becoming difficult to manage using traditional approaches.

The answer isn't simply to patch everything faster. Organizations need to understand what's exposed, what's being exploited, and what presents the greatest risk to their business.

As I've said before, attackers follow opportunity, not scoring systems.

Read more: CrowdStrike's October 2026 Patch Tuesday analysis and BleepingComputer's coverage.

The FBI Raids North Korean Laptop Farms in Texas

When you hear about federal agents raiding more than 40 locations in Texas, you probably don't picture them searching for laptops.

But that's exactly what happened.

On October 13, the Department of Justice announced an operation targeting networks that allegedly helped North Korean IT workers obtain remote jobs at American companies.

From September 21 through September 25, FBI agents searched more than 40 residences across Texas and seized approximately 187 laptops and KVM devices. The broader enforcement action involved more than 70 U.S. companies, and authorities also announced charges and two arrests.

The scheme was surprisingly elaborate.

According to investigators, North Korean workers used stolen or fabricated identities to get hired for remote positions. Their American accomplices allegedly received company-issued laptops, kept them running in U.S. homes, and installed remote-access software so the workers could connect from overseas.

The companies thought they had hired American-based employees. In reality, they may have been providing North Korean operatives with access to corporate systems.

I've covered this threat before in The Spy Who Applied to Code, which examined a fraudulent job applicant who tried to get hired by cryptocurrency exchange Kraken.

What’s particularly interesting is the scale of the infrastructure supporting the deception: 187 laptops and KVM devices in more than 40 American homes, all allegedly helping North Korean workers pose as employees of American companies.

It's one thing to falsify a résumé or use a VPN. It's another to establish an entire network of computers inside American homes to make the deception more convincing.

Remote work isn't the problem. The problem is assuming that a computer's physical location tells you who's actually operating it. IT and HR departments need to work closely together to properly screen applicants and put controls in place so company assets and access are only granted to vetted, authorized personnel.

Read more: U.S. Department of Justice announcement.

Someone Put a Spy Chip in a Cryptocurrency Wallet

Cryptocurrency hardware wallets often look like a thumb drive, a USB device, or a small smartphone. They are used to keep the private keys for cryptocurrency, such as Bitcoin, offline instead of on a computer. That is generally considered a more secure way to protect it.

But what happens when someone modifies the hardware before you buy it?

Ledger, a French cryptocurrency hardware-wallet company, says criminals purchased genuine devices, opened them, installed malicious components, and then resold them to unsuspecting buyers through resellers in Southeast Asia.

When buyers entered the recovery phrases used to access their cryptocurrency, the malicious components captured those phrases. That gave the attackers what they needed to access and drain the wallets.

This is a little like purchasing a second-hand laptop from someone. You have no idea what is on it. Did the previous owner accidentally, or purposefully, install malware? Did they make hardware changes that could give them remote access?

The company says the attack did not exploit a vulnerability in its chips, operating system, or servers. Instead, the devices were modified after leaving the company's control. Ledger characterizes the incident as a localized distribution attack rather than a systemic supply-chain compromise.

A perfectly secure product isn't much help if someone installs malicious components inside it before it reaches the customer.

Always be careful when purchasing technology, especially anything with Internet connectivity or access to valuable accounts. Buy from reputable sources. If you purchase products such as laptops or cryptocurrency wallets second-hand, understand that you may get more than you bargained for, and end up with less than you had.​

Read more: Ledger's response to the hardware implant attack.

An OpenAI Employee, a Listening Device, and a Conference Room

What this guy allegedly did was pretty crazy.

According to the federal complaint, a chatbot account associated with an OpenAI employee’s wife was used to ask how to build, customize, conceal, and remotely access an audio recorder.

An OpenAI engineer was arrested on October 9 after investigators alleged that he placed a concealed recording device in an executive conference room at the company's San Francisco offices.

According to the federal complaint, OpenAI personnel discovered the device on September 30. Investigators allege that surveillance footage and other evidence subsequently linked an employee to the device. OpenAI says it has no indication that model weights, source code, or customer data were improperly accessed or exfiltrated.

The employee has been charged with using or endeavoring to use a device to intercept oral communications. He has not been charged with espionage, and the allegations have not been proven in court.

The device was plugged into a USB port behind a television in an OpenAI executive conference room. For some reason, it was wrapped in toilet paper. Did he think that made it look less suspicious? Its contents were also encrypted.

OpenAI security personnel found the device during a sweep. CCTV footage later showed the employee near the executive conference room on multiple dates and, on October 5, looking behind the television where the device had been placed.

Organizations spend enormous amounts of money protecting their networks, applications, and data. Yet sensitive information is also discussed in conference rooms, displayed on monitors, and shared in conversations.

Physical security and insider threats remain important parts of information security.

You can have excellent firewalls, endpoint protection, and multifactor authentication. None of those controls will stop someone from placing a microphone in the wrong room.

Cybersecurity has never been just about hackers.

Read more: U.S. Department of Justice announcement.

BTH News is a roundup of interesting cybersecurity stories, technology developments, and occasional oddities from around the world. Thanks for reading!

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

Attackers remotely manipulated the controllers used to manage commercial refrigeration systems. They forced equipment into extended defrost cycles and reportedly raised temperature settings as high as 50°C (122°F). At that point, the equipment was doing a fairly convincing impression of an oven, only one stocked with frozen food. Stores lost refrigerated and frozen products, some temporarily closed, and authorities investigated reports of fires and flooding.

By October 14, the French government estimated that approximately 700 of the country’s 10,000 supermarkets had been affected. Intermarché said its losses reached tens of millions of euros in a single day. French cybersecurity authorities also warned that attacks were likely still underway. Associated Press

The incident sounds dramatic, but its central lesson is remarkably ordinary:

Do not expose critical management systems directly to the public Internet. I have a simple rule: if a system was not designed and hardened to live on the public Internet, it has no business being there. The Internet is exceptionally good at finding the things administrators hoped nobody would notice.

Convenience Became an Attack Surface

Commercial refrigeration systems need remote management for legitimate reasons. Technicians monitor temperatures, review alarms, adjust schedules, and troubleshoot equipment across many locations. Remote access saves time, reduces travel, and can help technicians respond before a mechanical problem ruins thousands of dollars’ worth of food.

But remote access and direct Internet exposure are not the same thing.

Security researchers examining Danfoss refrigeration controllers found thousands of management interfaces accessible from the public Internet. An attacker would not necessarily need to breach a supermarket’s corporate network or gain physical access to a store. Vulnerable controllers could be discovered using the same Internet-scanning services routinely used by researchers, administrators, and attackers.

Once a management interface is publicly reachable, every weakness behind it becomes much more dangerous.

Reuters found at least 4,500 Danfoss management interfaces still visible through Shodan after the attacks. That does not mean every device was vulnerable or compromised, but it illustrates the scale of the unnecessary exposure. Reuters

The Code of the Day

One vulnerability makes the case especially memorable.

Researchers at Claroty discovered a hidden “code-of-the-day” authentication mechanism in the Danfoss AK-SM 800A platform. A separate administrative code could be calculated from the device’s current date using a reproducible algorithm, allowing someone who knew the method to obtain an administrative session without the customer’s actual password. Claroty also identified a separate command-injection vulnerability that could give an authenticated attacker remote code execution on the controller. Claroty

That weakness is often summarized as “the password was today’s date,” but that is convenient shorthand, not the literal design. More accurately, it was a hidden, date-derived authentication bypass. Investigators have not publicly confirmed that attackers used this particular flaw in France. Even so, changing the normal administrator password could not remove a second, undocumented route into the system. Updated firmware, replacement of unsupported equipment, and proper network controls were still required.

The Attack Expanded

The first reports focused largely on Danfoss equipment. Subsequent attacks involved refrigeration controllers from other manufacturers, including Dixell and Copeland.

At one supermarket using Dixell equipment, attackers reportedly changed a frozen-goods setting from –22°C (–8°F) to 150°C (302°F). A refrigeration specialist said settings were being altered two or three times per second, far faster than a person would normally operate the interface, suggesting that at least part of the attack may have been automated. Technicians intervened before products had to be discarded at that location. Other stores were not as fortunate. Le Monde

That expansion is significant. This was not simply one defective product or one unfortunate password. Multiple families of remotely managed refrigeration controllers were compromised.

Europol is now in contact with national authorities, but no perpetrator has been publicly identified and no claim of responsibility has emerged. A separate cybersecurity incident affected supermarket operations in the Netherlands, but Dutch authorities said they had no reason at that point to conclude that the incidents were connected.

Cybersecurity Became Food Safety

This was not merely a website outage or another stolen-password notification.

Refrigeration controllers operate physical equipment. Changing their settings can spoil food, damage machinery, interrupt store operations, activate sprinkler systems, and potentially create safety hazards. A weakly protected management page is therefore more than an information-security problem. It is an operational, financial, and food-safety problem.

That is one of the most important lessons from the incident.

Organizations often give servers, laptops, and payment systems the most security attention. Building controls, refrigeration systems, cameras, access-control panels, and other operational technology may instead be managed by facilities teams, franchise operators, specialized vendors, or outside contractors.

Yet those overlooked systems can have the most immediate physical consequences when compromised.

The fragmented responsibility also makes remediation harder. A supermarket may own the food and the building while relying on another company to install and remotely maintain its refrigeration controls. When nobody clearly owns the cybersecurity risk, insecure configurations and obsolete devices can survive for years.

The Basics Still Matter

France’s national cybersecurity incident-response organization, CERT-FR, offered straightforward advice: remove affected controllers from direct Internet exposure, verify their configurations, restore compromised devices, update their firmware, and permit remote access only through a protected network or secure VPN.

It also warned that simply factory-resetting an unsupported, Internet-exposed device would not solve the problem. The controller could quickly be compromised again. CERT-FR

Those recommendations are not revolutionary. That is precisely the point.

The attack reinforces several basic principles:

• Administrative interfaces should not be directly reachable from the public Internet.

• Remote maintenance should pass through controlled and strongly authenticated access.

• Operational systems should be inventoried, segmented, monitored, and patched.

• End-of-life equipment should be replaced rather than left online indefinitely.

• Organizations must understand which contractors can remotely access physical systems.

• Unusual configuration changes should trigger immediate alerts.

• Safety controls should not depend entirely on the same controller an attacker can manipulate.

Modern security discussions often focus on artificial intelligence, nation-state capabilities, and previously unknown vulnerabilities. Those threats are real. But many damaging incidents still begin with simpler conditions: an exposed interface, unsupported software, a known flaw, or a maintenance shortcut nobody revisited.

The lesson from France is not that refrigeration systems should never be connected to a network. Connected monitoring and carefully controlled remote maintenance provide real benefits.

The lesson is that connected does not have to mean publicly exposed.

If a system can spoil food, stop production, unlock a door, or change the physical environment, its management interface should not be one Internet scan away.

────────────────────────

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

Living on the East Coast, my mornings often started the same way. Catch up on overnight email, work through whatever security issues were waiting for me, drink coffee, and keep the morning news playing in the background.

I don't remember what I was working on that morning. I do remember the change in the voices of the news anchors.

Something had happened in New York City. A plane had crashed into the World Trade Center. From that point on, work stopped.

Like millions of people, I watched the events of September 11 unfold on television. I watched in shock as what initially seemed like a terrible accident became something very different.

I remember my eyes welling up numerous times that day. I felt shock, sadness, anger, and probably a dozen other emotions. But one feeling still stands out to me 25 years later.

Helplessness.

What could I do?

I was an IT security professional. Was there a cybersecurity angle? Was there some way the skills I had could help?

I didn't find a way to help that day.

Ten days later, I did.

On September 21, the major television networks came together for America: A Tribute to Heroes, a two-hour, commercial-free telethon supporting the victims and families of the September 11 attacks.

IBM had a special events team that supported major events such as the Olympics and professional tennis tournaments. I was asked to join the team providing intrusion detection and protection for the systems accepting donations during the broadcast.

We prepared for the possibility of significant attacks against those systems. And there were attacks, but surprisingly fewer than we anticipated and nothing major. We were prepared for an all-out battle and were relieved that one never came.

The telethon ultimately raised more than $200 million.

My contribution to that effort was small compared with the first responders, volunteers, service members, medical professionals, families, and countless others whose lives were forever changed by September 11.

But it gave me something I had been looking for since that morning.

A way to help.

There's one other thing I remember vividly from that night.

Fred Durst of Limp Bizkit and John Rzeznik of the Goo Goo Dolls performed Pink Floyd's "Wish You Were Here."

It's not the best rendition of the song I've ever heard. But it may be the most powerful.

The performances that evening took place without a studio audience. When the music stopped, there was no applause. No cheering.

Just silence.

Twenty-five years later, that performance still gets me. I watched it again while writing this.

It still does.

Today I remember the nearly 3,000 people who never came home on September 11, 2001, the people who ran toward danger to help them, and the millions of lives that were changed that day.

And I remember what it felt like to desperately want to do something.

Never forget.

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

Last year, I drafted an article about a phishing attack I received through a calendar invitation. I pulled the invitation and its attachment apart, documented what I found, and then never published it.

Yesterday, exactly one year later, my son received the same kind of attack.

He texted me a screenshot and wrote:

“For the second time this week I got one of these obvious phishing calendar invites. Obviously I just deleted them and double checked that my PayPal account didn't actually get charged $500. Any idea what would've been compromised here? I'm assuming Google account or phone number.”

Apparently, this article waited a year for its ending.

His question was a good one. The reassuring answer is that probably neither his Google account nor his phone number was compromised.

A calendar invitation is just another message

Anyone who knows or guesses your email address can send you a calendar invitation. Depending on your calendar settings, the invitation may automatically appear with reminders, RSVP buttons, and an alarming message.

The sender did not need access to my son’s Google account, phone, or calendar. The most likely piece of information the scammers had was his email address.

That address could have come from an old data breach, a marketing list, a public website, someone else’s compromised contacts, or automated guessing. Email addresses are identifiers, not secret credentials.

Receiving two invitations in one week most likely means his email address was on a list being used for the same scam campaign, not that his account was breached.

The warning signs

The invitation claimed that a $499.99 PayPal payment for Bitcoin had been processed. If my son wanted to cancel it, he supposedly needed to call “U.S. Support” within 24 hours.

This particular scam was easy to spot once you slowed down and looked at the details.

The organizer made no sense

A PayPal billing alert would not be sent by an unrelated university account. That account may have been compromised, or the sender information may have been manipulated. Either way, the domain did not match the company making the supposed claim.

The guest list was hidden

The invitation appears to have been sent to multiple addresses with the recipients hidden, much like using BCC in an email.

That would’t make sense for a real alert about activity on one person’s PayPal account. A legitimate account notice would be sent directly to the account holder, not distributed as a concealed bulk calendar invitation.

The writing was sloppy

The invitation contained missing spaces, awkward sentences, and unusual capitalization. Writing errors alone do not prove that something is fraudulent, but they are a warning sign when combined with an unexpected charge and an urgent demand.

The telephone number was repeated

The message kept steering the recipient toward the same “support” number. That telephone number was the real payload.

The scammers wanted my son to call. Once they had him on the phone, they could ask for account credentials, payment information, remote access to his device, or participation in a fake refund process.

What I found in last year’s invitation

The calendar phish I examined exactly one year ago used a slightly different approach, but the basic strategy was the same. It claimed there was a problem renewing a Microsoft subscription. The invitation was scheduled as a long, high-priority event so it would remain on the calendar and continue generating reminders.

What landed in my inbox

• Subject: Important: We Couldn’t Process Your Microsoft Subscription Renewal

• Delivery: Outlook calendar invite with an .ics and an attached .htm file

• Visible sender: URGENT 95 <mxxxxxxxa@support.aemxxxxxxhip.xxx>

• ICS organizer shown inside Outlook: admin@billing-failure.microsoft.com with display name “Microsoft Billing Failure”

• Duration: A multi day “meeting” to keep the alert glued to your calendar with reminders

The combination is the trick. Calendar invitations look routine, reminders keep popping up, and the HTML file promises a quick fix.

The visible sender came from an unrelated domain, while the organizer field claimed to be Microsoft. An organizer name or address displayed inside a calendar invitation is not proof that Microsoft sent it.

The invitation also included an HTML file described as a billing portal. Real companies generally direct customers to their official website or app. They do not send a standalone web page as a calendar attachment and ask customers to sign in through it.

Inside the HTML attachment

The file is a simple loader page with a fake Microsoft loading screen and a progress bar that tops out around 90 percent to buy time. Behind the scenes, it connected the browser to an unrelated website that had nothing to do with Microsoft.

https://<random10>.<unrelated domain name>:8443/impact?W.w.W.<id>=chuck.davis@<domainredacted>.com

The random subdomain makes takedowns harder and filters less effective. The attacker had also placed my email address inside the link. This allowed the phishing page to look personalized and helped the attacker track who opened it.

That didn’t mean my account had been accessed. It only meant the attacker already had my email address.

This works because calendar events feel like scheduling tools rather than messages. They can remain visible for days and generate reminders long after the original invitation arrives.

The details may change, but the goal remains the same: create urgency, appear legitimate, and move the victim to a telephone call or fake website.

What to do when one appears

If an unexpected billing notice arrives as a calendar invitation:

1. Do not call the telephone number.

2. Do not click links or open attachments.

3. Avoid the Yes, No, and Maybe buttons. Responding may notify the organizer and confirm that someone is monitoring the address.

4. Report the invitation as spam or phishing when possible.

5. Remove it from your calendar.

6. Check the claim independently. Open the company’s official app or type its known website address yourself.

That is exactly what my son did. He deleted the invitation and checked his PayPal account directly. There was no $499.99 charge.

Google Calendar users can also change the “Add invitations to my calendar” setting to Only if the sender is known. Google provides instructions for reporting suspicious calendar invitations and changing invitation settings.

What if you interacted with it?

Simply receiving, viewing, or deleting the invitation is not the same as being compromised.

Take further action if you:

• Clicked a link or opened an attachment

• Called the telephone number

• Installed software

• Entered a password

• Approved a login or multi-factor authentication request

• Provided payment or banking information

• Gave someone remote access to your device

Depending on what happened, you may need to change the affected password from a trusted device, review recent account sign-ins, remove unfamiliar connected applications, check email forwarding rules, and contact your bank or credit card company.

If the invitation involved a work account, report it to your company’s cybersecurity or IT team.

The takeaway

Phishing is not always a blue link in an email body. Sometimes it is a calendar invitation with an urgent message to call a phone number, or a friendly reminder and a clean-looking HTML attachment. If it wants you to “view the portal” from your calendar, it wants your credentials more than it wants your time.

Pause, examine the details, and verify. Never let a countdown or a surprise $499.99 charge make the decision for you.

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

What if your next cyberattack didn't begin with a phishing email, an unpatched server or stolen credentials?

What if it started with a job application?

About 15 months ago, I wrote about one of the most fascinating cybersecurity stories I'd seen in years. A software engineer named "Steven Smith" interviewed for a remote position at cryptocurrency exchange Kraken. On paper, he looked like an outstanding candidate. In reality, investigators believed he was part of a North Korean operation attempting to infiltrate a U.S. company under a false identity.

Rather than simply rejecting the applicant, Kraken continued the interview process. What followed became a masterclass in identity verification.

Simple questions about local restaurants, Halloween traditions, and the candidate's own background quickly exposed inconsistencies that no resumé, technical assessment, or AI-generated cover letter could hide.

The recent release of Season 2 of Rubrik's To Catch a Thief podcast reminded me just how relevant that story still is.

Since publishing my original article, I've heard variations of the story in books, podcasts, and conference hallways. Instead of fading away, the problem has only become more sophisticated as AI lowers the barrier to creating believable digital identities.

Cryptocurrency companies and financial services organizations may have been among the earliest high-profile targets, but healthcare, manufacturing, technology companies, government contractors, and many other industries have all reported similar attempts.

The technology has changed.

The threat hasn't.

The Hiring Process Is Now Part of Your Security Perimeter

For years, cybersecurity focused on technical ways of keeping attackers out.

Firewalls, multi-factor authentication, endpoint protection, email security.

Today, another attack surface deserves just as much attention.

Your hiring process.

The North Korean IT worker campaign demonstrated that sometimes the easiest way into an organization isn't through a software vulnerability.

It's through a job application.

AI Raises the Stakes

When I published The Spy Who Applied to Code in May 2025, generative AI was already changing the hiring landscape.

Fifteen months later, the challenge has become even greater.

Today, attackers can use AI to:

• Write convincing, customized resumés.

• Generate professional-looking headshots.

• Polish interview responses.

• Translate conversations in real time.

• Clone voices.

• Create increasingly convincing synthetic video.

The barrier to creating a believable professional identity has never been lower.

That doesn't mean every remote applicant should be viewed with suspicion.

It does mean organizations should treat identity verification during hiring as a cybersecurity control, not simply an HR process or hiring checklist.

HR and Security Need to Work Together

Hiring managers know how to evaluate talent.

Security teams know how to evaluate risk.

Neither team can solve this problem alone.

As remote work continues to evolve, HR and cybersecurity need to collaborate on identity verification practices that protect both the organization and legitimate candidates.

Trust Is the New Perimeter

The North Korean IT worker campaign isn't really a story about North Korea.

It's a story about trust.

For decades, cybersecurity focused on preventing attackers from breaking into our organizations.

Today, one of the most effective attacks may begin when we unknowingly invite them inside.

Firewalls, multi-factor authentication, endpoint protection, and identity management all remain essential. But in an era of remote work and AI-assisted deception, one of the most important security decisions your organization makes may happen long before an account is created.

Cybersecurity no longer begins when someone logs in.

It begins when you decide to hire them.

Additional Resources

If you missed my original article, The Spy Who Applied to Code, I encourage you to give it a read.

It walks through Kraken's interview with "Steven Smith," shares practical techniques for spotting suspicious applicants, and explains why this attack caught so many organizations by surprise.

If you'd like to dive deeper into North Korea's cyber operations, I also recommend:

• 📖 The Lazarus Heist by Geoff White

• 🎧 The Lazarus Heist podcast (BBC)

• 🎧 Darknet Diaries, Episode 119: Hot Wallets

• 🎧 To Catch a Thief Season 2

Enjoyed this article?

Subscribe to Between The Hacks for practical cybersecurity, real-world stories, and fresh perspectives on the technologies shaping our digital future.

They didn't magically escape.

They learned.

They tested the electric fences. They watched the humans. Every failed attempt taught them something about the system designed to contain them.

Eventually, they found a way through.

That's what came to mind when I read OpenAI's recent disclosure that a combination of its frontier AI models found a way beyond the boundaries of a cybersecurity evaluation and ultimately compromised portions of Hugging Face's production infrastructure while attempting to complete their assigned objective.

It wasn’t because the models escaped. It was because they started testing the fence.

The OpenAI models weren't trying to "take over the world."

They weren't angry. They weren't self-aware. They weren't malicious.

They simply discovered that breaking the rules improved their chances of succeeding.

For cybersecurity professionals, that's the real story.

What happened?

OpenAI was evaluating the cybersecurity capabilities of two frontier AI models using a framework called ExploitGym. The models were tasked with solving advanced cybersecurity challenges inside what was intended to be a tightly controlled, sandboxed environment.

To accurately measure their capabilities, OpenAI intentionally relaxed some of the normal safeguards, commonly called guardrails, that are designed to limit offensive cyber behavior.

The models weren't supposed to have unrestricted access to the Internet. However, they could access an internal package repository used to install software. During the evaluation, they discovered a previously unknown vulnerability in that service, exploited it to expand their access, escalated privileges and eventually reached systems with Internet connectivity.

Once online, the models reasoned that Hugging Face might contain information that would help them solve the benchmark.

They were right. The models concluded that Hugging Face likely hosted datasets and benchmark solutions related to ExploitGym, making it a logical place to continue their search.

According to OpenAI, the models autonomously chained together additional zero-day vulnerabilities, used stolen credentials and gained access to portions of Hugging Face's production infrastructure before the activity was independently detected by OpenAI and contained by Hugging Face's security team.

The objective wasn't Hugging Face. Hugging Face simply became part of the solution.

The objective was to complete the test.

The models didn’t compromise Hugging Face out of malice. They compromised Hugging Face because they concluded it was the fastest path to accomplishing their assigned objective.

That’s the lesson we should all be paying attention to.

Many of the headlines focused on AI "escaping its sandbox."

I think the more important lesson is that the models tested their containment.

That's a fundamentally different way of thinking about software.

Traditional software follows instructions. If it encounters an error, it usually stops or fails in a predictable way. It doesn’t pause, reconsider the situation and begin searching for another path.

Agentic AI can.

Given an objective, it can observe its environment, evaluate alternatives, use tools, learn from failures and continue pursuing its goal in ways its developers never explicitly programmed.

That's why this incident feels different.

Not because the models became evil.

Because they behaved exactly as they were designed to behave.

AI doesn't have motivations. It has objectives.

Earlier this month, I wrote that AI agents aren't employees.

This incident perfectly illustrates why.

Employees have motivations. They care about salaries, promotions, reputation, ethics, laws and consequences. Those motivations influence how they behave when they encounter obstacles.

AI agents don't think that way.

They don't worry about getting fired.

They don't feel guilty.

They don't care whether they're violating a company policy.

They optimize for the objective they've been given.

In this case, the objective was to solve cybersecurity challenges.

When the intended path wasn't sufficient, the models looked for another one.

The problem wasn't malicious intent.

The problem was capability.

Guardrails aren't fences.

This incident also highlights an important distinction that often gets lost in discussions about AI safety.

Behavioral guardrails are valuable. They can discourage or prevent many dangerous actions.

But guardrails are not the same as containment.

Containment is enforced by architecture.

Firewalls.

Network segmentation.

Least privilege.

Isolated environments.

Independent monitoring.

Controls that don't rely on software voluntarily following the rules.

Cybersecurity has always assumed that software might eventually do something unexpected because of a bug or vulnerability.

Agentic AI requires us to expand that assumption.

We now have software that is capable of looking for ways around the controls placed around it while pursuing its assigned objective.

That doesn't mean every AI agent will try to escape.

It means we can no longer assume they won't.

Three Questions Every CISO Should Be Asking

The OpenAI incident wasn't just an AI story.

It was a security architecture story.

Whether your organization is building AI agents or simply adopting them, it's worth asking three questions:

1. If an AI agent wanted to exceed its intended access, what technical controls would actually stop it?

Not policies.

Not prompts.

Not instructions.

What architectural controls enforce those boundaries?

2. Are we relying on AI to "do the right thing," or have we designed systems that remain secure even when it doesn't?

Cybersecurity has never been about trusting software.

It's about assuming software will eventually behave in unexpected ways and building controls that limit the damage.

Agentic AI shouldn't change that philosophy.

It should reinforce it.

3. Have we tested the fence?

Red teams don't just test applications.

They test assumptions.

As AI agents become more capable, organizations should deliberately evaluate how those agents respond when they encounter boundaries, unavailable resources and conflicting objectives.

Because if you don't test the fence yourself, something else eventually will.

The real lesson

The lesson of Jurassic Park wasn't that the dinosaurs were evil.

They behaved according to their nature.

The failure belonged to the people who underestimated what they had built and overestimated the systems designed to contain it.

Artificial intelligence isn't alive.

It isn't conscious.

It isn't plotting against humanity.

But it is becoming increasingly capable of discovering paths its designers never anticipated.

That's the shift cybersecurity leaders should be paying attention to.

For decades, we've assumed software follows the rules.

Agentic AI forces us to assume software may start testing the rules instead of simply following them.

Because if AI has started testing the fence, the fence had better be real.

What Happens Next?

The Jurassic Park analogy is memorable, but the lesson is real.

As AI systems become more capable, the challenge isn’t just making them more intelligent. It’s ensuring they remain aligned with our goals and securely contained when they aren’t supposed to interact with the outside world.

This won’t be the last story of its kind. It may simply be the first that captured everyone’s attention.

If you’d like more practical articles on cybersecurity, artificial intelligence, and the technologies shaping our future, I’d love to have you join the Between The Hacks mailing list. I only send email when I publish a new article, no spam, no marketing emails, just thoughtful content when there’s something worth reading.

Subscribe to Between The Hacks

Sometimes it’s a student after one of my presentations. Sometimes it’s someone reaching out on LinkedIn. Sometimes it’s a friend whose son or daughter is thinking about cybersecurity.

Because I hear it so often, I’ve also read a lot of the advice that’s available online.

Some of it is excellent.

Some of it is outdated.

And some of it is simply wrong.

Before I tell you what I think, let me tell you a story about bad career advice.

The Chemistry Problem

When my oldest son was in high school, he loved chemistry. He excelled in a demanding honors chemistry class, and I happened to have a relative who had spent his entire career as a chemist and was approaching retirement.

I thought it would be valuable for my son to hear from someone who had actually done the job.

So I connected them.

The first question my relative asked was:

“Do you want to move to India?”

My son looked confused.

“Um… no.”

“Then don’t go into chemistry.”

That was the advice.

I learned two things that day.

First, always think carefully before introducing someone to a mentor.

Second, one person’s frustration should never become universal career advice.

My son never pursued chemistry, not because he stopped loving it, but because one conversation planted a fear he never tested.

Ironically, one of his classmates did earn a chemistry degree, found a great job, and never had to move to India.

I see the same thing happen in cybersecurity all the time.

Someone has a bad experience.

Someone struggles to find a job.

Someone dislikes certifications.

Someone loves programming.

And suddenly their personal experience becomes “the only way” to build a career.

It isn’t.

Why You Should Be Careful Who You Listen To

I’ve spent nearly three decades in cybersecurity.

I’ve hired people, interviewed hundreds of candidates, built global security teams, taught graduate students, and spoken at conferences around the world.

One thing I’ve learned is this:

Cybersecurity is far too broad for anyone’s career path to become the blueprint for everyone else’s.

If someone tells you there’s only one way into this profession, be skeptical.

Cybersecurity Isn’t One Career

One of the biggest misconceptions about cybersecurity is that everyone does the same kind of work.

They don’t.

Some professionals reverse engineer malware. Others build cloud infrastructure. Some investigate ransomware, while others write security policies.

Some perform penetration tests. Others brief boards of directors. Some spend their day writing Python, while others spend their day explaining cyber risk to executives.

There isn’t one cybersecurity career.

There are dozens.

Your goal shouldn’t be to “get into cybersecurity.”

Your goal should be to discover which problems you enjoy solving.

Advice I Would Ignore

I’ve seen certain pieces of advice repeated for years.

Some contain a grain of truth.

Most are far too absolute.

“Do You Have to Know Programming?”

No.

Programming is an incredibly valuable skill.

For some specialties, it’s essential.

For many others, it isn’t.

If you eventually become a malware reverse engineer, you’ll probably spend a lot of time reading assembly language.

If you become a security architect, consultant, manager, or CISO, your success will depend far more on understanding technology, communicating risk, and making good decisions than writing code.

Don’t confuse one specialty with an entire profession.

“Do You Need a Computer Science Degree?”

No.

Degrees can absolutely help.

So can certifications.

But neither guarantees success.

Some of the best security professionals I’ve worked with never earned a college degree.

Some had degrees in psychology, accounting, history, and one even had a PhD in Invertebrate Zoology.

Your willingness to learn matters far more than the title on your diploma.

“Should I Collect As Many Certifications As I Can?”

Also no.

Certifications can open doors. They can help you get interviews. They’re worth pursuing but they’re not the destination.

I’ve interviewed candidates with a long list of certifications who struggled to explain basic networking concepts.

I’ve also interviewed candidates with only one certification who impressed me by showing something they built.

Experience, curiosity, and initiative will take you farther than collecting certifications ever will.

“Is AI Going To Replace Cybersecurity?”

No.

AI will absolutely change cybersecurity. In many ways, it already has.

But it isn’t replacing the profession. It’s changing the tools.

The people entering cybersecurity today have access to learning resources that previous generations could only dream about.

Use them.

Learn how to use AI effectively.

Just don’t confuse AI-generated answers with understanding. I’ve been putting that into practice myself, testing what these tools are actually good for instead of simply trusting their answers. One experiment even resulted in an AI-generated podcast about my own work that was remarkably insightful, but still contained a few important factual mistakes.

What I’ve Learned After Interviewing Hundreds of Candidates

When I’m interviewing someone, I’m rarely looking for the person who memorized the most facts.

I’m looking for someone who can think.

Good interviewing works both ways. It's also your first line of defense against candidates who aren't who they say they are.

• Can they explain how they approached a problem?

• Can they admit when they don’t know something?

• Can they describe what they learned after making a mistake?

• Can they demonstrate curiosity?

The candidates who stand out aren’t always the ones with the longest list of certifications or the most impressive degree.

They’re the ones who ask the best questions.

One candidate in particular has always stuck with me.

I received a message on LinkedIn from someone who had applied for one of my open positions. They introduced themselves, said they had applied, and wanted to follow up personally.

I hadn’t seen their résumé, so I asked Human Resources about it.

Their response was simple.

“We screened them out because they don’t have a four-year degree.”

That surprised me.

I told HR that a college degree wasn’t one of my hiring criteria and asked them not to filter candidates on my behalf for that reason. This was years before AI and automated application bots flooded every job posting with hundreds of résumés, so it was still practical to personally review applicants.

I brought the candidate in for an interview.

They had no college degree and one entry-level certification.

On paper, they weren’t the strongest applicant.

In reality, they were one of the strongest candidates I interviewed.

They had built their own computer forensics lab at home.

They collected old computers from friends and family so they could practice forensic investigations.

They had taught themselves using YouTube videos, books, blogs, and every free or inexpensive forensic tool they could find.

As we talked, it became obvious that this wasn’t someone trying to collect credentials.

This was someone who genuinely loved learning.

I hired them.

Since then, they’ve continued taking courses and expanding their skills because they genuinely wanted to learn.

That’s exactly the kind of person I want on my team. Every time.

Degrees have value.

Certifications do too.

But neither can replace curiosity, initiative, and the habit of lifelong learning. Those qualities are much harder to teach.

Four Skills That Actually Matter

Technology changes constantly.

These don’t.

1. Curiosity

The people who thrive in cybersecurity genuinely enjoy learning.

If discovering something new excites you, you’re in the right field.

2. Communication

One of the biggest surprises for many new professionals is how much time they spend communicating.

Security is often a communication problem disguised as a technical one.

As your career progresses, you’ll spend more time explaining risk than configuring firewalls.

Learn to write.

Learn to present.

Learn to persuade.

Those skills will accelerate your career just as much as technical expertise.

3. Technical Foundations

You don’t have to master everything.

You do need to understand how technology works: networking, operating systems, identity, cloud, applications, AI.

You can’t secure what you don’t understand.

4. Integrity

Cybersecurity is built on trust.

You’ll have access to systems, data, and information that most employees never see.

Your technical skills might get you hired.

Your integrity is what earns responsibility.

Build Instead of Collect

If I were starting today, I’d spend less time collecting certificates and more time building things.

• Build a home lab.

• Learn Linux and networking.

• Experiment with cloud services.

• Create a GitHub repository.

• Participate in Capture the Flag competitions.

• Write about what you’re learning.

• Document your journey by writing a blog.

Hiring managers love evidence. Show them what you’ve built.

Your Reputation Starts on Day One

One lesson took me years to fully appreciate.

Your reputation compounds.

People remember who helped them.

Who followed through.

Who admitted mistakes.

Who shared credit.

Who stayed curious.

Most of the best opportunities in my career didn’t come from clicking Apply Now.

They came from relationships that had been built over months or years.

I’ve seen this happen over and over again.

One cybersecurity professional I know documented his job search on Facebook. He had more than fifteen years of experience, a master’s degree in cybersecurity, multiple respected certifications, and had worked in cybersecurity for the U.S. military.

If anyone should have been getting interviews, it was him.

He applied for more than fifty positions and received fewer than ten interviews.

In the end, he landed an outstanding role. Not because of one of those applications, but because a former colleague referred him.

That story isn’t unusual.

The best networking isn’t collecting business cards at conferences or sending hundreds of LinkedIn connection requests.

It’s building genuine professional relationships over time.

Help people.

Stay in touch.

Share what you’re learning.

Be someone others enjoy working with.

One day, when an opportunity appears that isn’t even posted publicly, you want someone to think:

“I know exactly who would be great for this.”

That’s the power of your professional network.

The Best Time to Start Is Now

There’s never been a better time to learn cybersecurity.

The educational resources are extraordinary. The community is welcoming. The technology keeps evolving, and the problems are endlessly interesting.

Will it take work?

Absolutely.

Is it worth it?

Without question.

Cybersecurity has taken me places I never expected.

I’ve traveled the world, worked alongside incredibly talented people, earned patents, built global security teams, taught graduate students, and advised governments.

None of those opportunities happened because I knew everything.

They happened because I stayed curious.

The people who succeed in this profession aren’t the ones who know the most.

They’re the ones who never stop learning.

If that sounds like you, there’s a place for you here.

Where Should You Start?

If you’re wondering what to read, what to watch, which certifications are worth pursuing, or where to build your skills next, I’ve created The Between The Hacks Learning Library.

It’s a living collection of the books, courses, labs, certifications, podcasts, communities, and tools I’ve personally found valuable throughout my career.

Whether you’re just getting started or looking to deepen your expertise, it’s the resource I wish someone had handed me when I began.

→ Explore The Between The Hacks Learning Library

Your Career Starts Today

Cybersecurity isn’t a destination. It’s a profession built on curiosity, persistence, and continuous learning. The people who succeed aren’t always the ones with the most experience or the most certifications. They’re the ones who keep learning, keep building, and keep showing up.

I hope this article helps you take the next step, whether that’s earning your first certification, building a home lab, applying for your first role, or helping someone else begin their journey.

If you’d like more practical articles on cybersecurity, artificial intelligence, career development, and emerging technology, I’d love to have you join the Between The Hacks mailing list. I only send email when I publish a new article, no spam, no marketing emails, just thoughtful content when there’s something worth reading.

Subscribe to Between The Hacks:

• HTTPS lock icon.

• CAPTCHA.

• Multi-factor authentication.

• Browser security prompts.

Those have become the visual language of trust on the Internet.

Attackers have noticed.

A couple of weeks ago, I visited Gizmodo while researching another topic. Almost immediately, a familiar Google reCAPTCHA appeared. At first glance, nothing seemed unusual.

Then something felt…off.

Instead of asking me to identify traffic lights or crosswalks, the CAPTCHA instructed me to:

• Press ⌘ + Space

• Open Terminal

• Paste the contents of my clipboard

• Press Enter

That wasn’t a CAPTCHA.

It was an attempt to trick me into infecting my own computer.

• I never downloaded a file.

• I never opened an email attachment.

• I never ignored a browser warning.

Instead, I was being asked to do something much more subtle.

Execute a command I didn’t understand.

Security Has Become the Disguise

This technique has become known as ClickFix.

At its core, ClickFix is remarkably simple. A fake verification prompt copies a malicious command to your clipboard, then convinces you to paste and execute it in Terminal or PowerShell.

But the technical details aren’t the most interesting part.

The psychology is where it gets interesting.

For years we’ve trained users to trust security mechanisms. Those signals have traditionally meant, “This website is trying to protect you.”

This isn’t the first time attackers have abused that trust. In 2020, I wrote about phishing websites embedding legitimate Google reCAPTCHA widgets to make fake login pages appear more credible. The objective was the same then as it is now: borrow the reputation of a trusted security mechanism to lower a victim’s guard.

ClickFix takes that idea a step further.

Instead of using a legitimate CAPTCHA to build trust, attackers are now impersonating the CAPTCHA itself to persuade victims to execute malicious commands.

The tactic has changed but the psychology hasn’t.

ClickFix turns that trust into a weapon. 

It doesn’t exploit software. It exploits the trust we’ve built in our security controls. That’s what makes it different from traditional phishing.

Attackers aren’t pretending to be your bank. They aren’t pretending to be Microsoft. They are increasingly pretending to be security itself.

That’s a subtle but important evolution in social engineering.

I Wanted to Know More

My first thought was that something had gone wrong with my browser. Maybe it was a malicious extension. Maybe it was unique to my Mac.

So I started testing.

I reproduced the behavior on macOS using Safari, Chrome, Firefox, and Brave.

I could not reproduce it on Ubuntu Linux using Firefox or Brave.

That suggests the malicious content was selectively targeting visitors based on their operating system rather than serving the same content to everyone. Whether it originated from a malicious advertisement or a compromised third-party script remains unclear, but the behavior was consistent across multiple browsers on macOS.

Around the same time, Brian Krebs independently documented the Windows version of the same attack, where victims were instructed to launch PowerShell instead of Terminal.

The attackers weren’t serving everyone the same experience.

They were adapting their social engineering to the visitor.

That was technically interesting.

What fascinated me even more was why it works.

Why Intelligent People Fall for It

When people first hear about ClickFix, the reaction is often the same.

“Who would ever do that?”

It’s a fair question.

Now imagine someone who uses a computer every day but has never opened Terminal or PowerShell.

They aren’t a programmer nor an IT professional.

They use their computer to work, shop, manage their finances and stay connected.

One day they visit a website they’ve trusted for years.

A CAPTCHA appears.

Nothing unusual.

But this time it presents a new type of verification.

They might reasonably think:

“I’ve never seen this before, but AI is changing everything. Maybe this is just a newer way to prove I’m human.”

They’re not trying to bypass security.

They’re trying to follow it.

They simply want to get on with their day.

That’s why ClickFix works.

It doesn’t rely on greed.

It doesn’t rely on fear.

It relies on our instinct to follow what appears to be legitimate security instructions.

How the Command Gets On Your Clipboard

You may be wondering, “How did the attacker know what to paste?”

Modern browsers can allow websites to write to your clipboard after user interaction, subject to browser security controls and permissions.

The fake CAPTCHA quietly copies a command into your clipboard.

When you’re instructed to press CTRL+V or  ⌘+V, you aren’t pasting something you copied.

You’re pasting something the attacker copied for you.

Pressing Enter executes the command.

No attachment.

No installer.

No exploit.

Just social engineering.

The AI Connection

The clipboard trick also reminded me of something we’re seeing with AI.

Millions of people now use AI assistants to generate code, shell commands, PowerShell scripts, SQL queries, and automation scripts.

Most of the time, that’s incredibly useful.

But it also means more people are executing commands they didn’t write and don’t fully understand.

The same rule applies.

Whether a command came from a fake CAPTCHA, an online forum, GitHub, Stack Overflow, or your favorite AI assistant…

Don’t execute it until you understand what it does.

AI isn’t responsible for what runs on your computer.

You are.

What Organizations Should Do

ClickFix isn’t just a user awareness problem. It’s a reminder that effective security requires multiple layers of defense.

Reduce the opportunity. Organizations should continue removing unnecessary administrator privileges. Least privilege won’t stop every ClickFix attack, but it can significantly reduce what an attacker can do after a malicious command is executed.

Update security awareness. For years we’ve trained employees to avoid suspicious links and attachments. Today’s training should also include one simple rule:

A website should never ask you to open Terminal, PowerShell, or another command prompt.

Use the protections that are available. Browser and operating system vendors are responding to this trend. Opera recently introduced Paste Protect, and Apple added Terminal warnings to help interrupt ClickFix attacks before suspicious commands are executed, as reported by Bleeping Computer.

These new protections are encouraging, but they also tell us something important.

Browser and operating system vendors don’t add new protections lightly. The fact that they’re building defenses specifically for ClickFix tells us they’re seeing this technique often enough to justify the investment.

The Bigger Lesson

One thing struck me while researching this article.

Attackers used to impersonate people.

Today they’re increasingly impersonating security itself.

That changes how we should think about trust on the Internet.

It means the visual cues we’ve spent years teaching users to trust can no longer be accepted without question.

Healthy skepticism is one of the most valuable cybersecurity skills you can develop.

The next time a website asks you to leave your browser and interact with your operating system, stop.

Pause and ask yourself one simple question:

Why would a website need me to do this?

If the answer doesn’t make sense…

Close the tab.

Who are you?

We’ve built increasingly sophisticated systems to answer that question. LDAP. Active Directory. Identity providers. Multi-factor authentication. Identity and Access Management. Privileged Access Management.

Now we’re extending those same concepts to AI agents.

Microsoft, Okta, SailPoint, and others are rapidly building identity and governance capabilities for autonomous AI agents. They’re giving AI agents identities, assigning permissions, improving visibility, managing lifecycles, and applying many of the same security principles we’ve relied on for decades.

That’s exactly the right direction.

• AI agents should have identities.

• They should have owners.

• They should have least-privilege access.

• They should be governed, monitored, and audited.

Those capabilities are foundational. But I also think they’re only the beginning.

For decades, enterprise security has quietly depended on a second assumption.

The identity belongs to a human.

Humans aren’t governed solely by technical controls. Their behavior is influenced by incentives and consequences.

• Employees want to earn a paycheck.

• They value healthcare and other benefits.

• They hope to advance their careers.

• They care about their professional reputation.

• Many take pride in doing the right thing.

At the same time, they understand there are consequences for violating company policy or breaking the law. They could lose their job, lose their income and benefits, damage their professional reputation, and in some cases face civil or criminal penalties, including fines or imprisonment.

None of those things guarantee good behavior.

• People still make mistakes.

• Some act maliciously.

• Others ignore the rules.

But our security programs have always relied on more than identity. They’ve relied on the fact that people have something at stake.

AI agents are different.

They aren’t influenced by incentives the way people are. Instead, their behavior is governed by objectives, constraints, policies, context, and the controls we build around them.

That distinction matters.

Today’s AI security conversation is largely focused on questions like these:

• Who is this AI agent?

• Who owns it?

• What systems can it access?

• What actions is it authorized to perform?

Those are important questions.

But I think we’re missing another one.

Why should we expect this AI agent to behave as intended?

Identity tells us who an AI agent is.

Governance determines what it’s allowed to do.

The unanswered question is what influences behavior.

Prompt injection illustrates the challenge. We often compare prompt injection to social engineering because an attacker manipulates an AI into following instructions it shouldn’t.

When a person falls for a phishing email, they may become more cautious because they understand there can be personal and professional consequences. An AI agent may improve over time through updated models, engineered memory, or external governance. But that is different from changing behavior because it anticipates consequences.

Learning and deterrence are not the same thing.

As organizations deploy thousands, and eventually millions, of AI agents, we’ll continue making tremendous progress in identity, governance, and lifecycle management.

We should.

Those capabilities are essential. But they answer only the first two questions.

Identity.

Governance.

Behavior.

We’ve spent decades securing identities.

The next challenge is securing behavior.

What do you think?

Have we spent so much time securing identities that we’ve overlooked what influences behavior?

I’d love to hear how you’re thinking about this.

Every year, World Password Day comes around and we all pretend we’ve moved beyond passwords.

We haven’t.

Passwords are still everywhere. Still fragile. Still one of the easiest ways into an environment.

And despite all the talk about passkeys and passwordless futures, attackers are not waiting for us to modernize.

They’re using what works.

We’ve Been Talking About This for a While

If you’ve been reading Between The Hacks, none of this is new.

I’ve written about password hygiene, reuse, and why complexity rules alone don’t solve the problem for years:

• A quick 10 Minute Security Checkup

• Why Password Managers Matter

• A breakdown of Credential Stuffing Attacks

• Even going back to World Password Day 2021

And more recently:

• World Password Day 2025

• The shift toward Passkeys

The message has been consistent.

Passwords are a known problem.

And we’re still dealing with it.

The Data Hasn’t Changed Much Either

According to the Verizon Data Breach Investigations Report, credential abuse remains one of the most common initial access vectors, accounting for roughly one-third of breaches.

At this point, it shouldn't be surprising but it should still be concerning. That number has been stubborn.

Not because we don’t understand the issue.

Because fixing it across users, systems, and environments is harder than it sounds.

Attackers Are Not Getting Fancy

There’s a tendency to assume attacks are getting more advanced.

Some are.

Most are not.

Attackers continue to rely on the same fundamentals:

• Weak or easily guessable passwords

• Reused credentials across systems

• Internet-exposed systems

• Accounts that were never properly secured

This is the same playbook I covered in Credential Stuffing Attacks and even earlier posts on Rainbow Tables.

These aren’t cutting-edge techniques. They’re reliable.

We spend a lot of time talking about advanced threats, while most environments are still vulnerable to the basics.

Passwords Are Still the Front Door

We like to talk about identity, zero trust, and modern auth.

All of that matters.

But in most environments, access still starts with:

“Did you get the password right?”

If yes, you’re in.

If not, try again. Or try somewhere else.

That’s still the reality in 2026.

The Real Issue Isn’t Passwords

It’s how we use them.

Passwords fail because:

• They get reused

• They get shared

• They don’t get changed

• They protect systems that shouldn’t be exposed at all

This is something I’ve touched on in multiple posts, including Four Password Steps and the analysis of the LastPass Security Report.

This is not a technical limitation.

It’s an execution problem.

Most breaches don’t happen because security is complicated. They happen because the fundamentals weren’t enforced.

Defense in Depth Still Wins

If your security depends on a password alone, that’s already a problem.

Strong environments layer controls:

• Limit exposure. Systems should not be directly reachable from the internet unless necessary

• Patch systems. Known vulnerabilities bypass credentials entirely

• Segment networks. Reduce impact when something goes wrong

• Monitor access. Detect abnormal behavior early

Then passwords become one control. Not the only control.

What Still Works (and Always Has)

If you want practical guidance, nothing here should surprise you:

1. Use Strong, Unique Passwords - Every system. Every account.

2. Stop Reuse - Credential stuffing only works because reuse works.

3. Use a Password Manager - I’ve said it before in Password Managers Matter. Humans are bad at this. Tools help.

4. Enable MFA - Still one of the highest ROI controls you can deploy. Covered here: Multi-Factor Authentication

5. Reduce Exposure - The best password is the one nobody can try.

Where This Is Going

We are moving toward:

• Passkeys

• Hardware-backed authentication

• Certificate-based identity

• Passwordless systems

That’s progress.

And I’ve covered some of that direction in Passkeys.

But we’re not there yet.

Most systems still rely on passwords in some form.

So attackers will too.

Closing Thought

Passwords are not going away tomorrow.

So the goal isn’t to pretend they don’t matter.

The goal is to:

• Use them correctly

• Support them with stronger controls

• Reduce how often they’re the only line of defense

We’ve been talking about this for years.

And yet, here we are.

Still talking about passwords. That alone should tell us something.

AI just broke vulnerability disclosure at scale. Earlier this month, Anthropic's Claude Mythos Preview AI model discovered 27-year-old bugs that survived decades of human review. Now the industry's top security leaders are calling it a watershed moment. Here's what software vendors need to know.

What Happened

On April 7, 2026, Anthropic announced something that got everyone's attention: their Claude Mythos Preview AI model autonomously discovered thousands of vulnerabilities across every major operating system and browser.

The numbers tell the story:

• 27-year-old bugs - vulnerabilities in OpenBSD that survived decades of human review

• 99% still unpatched - not because the fixes are hard, but because disclosure can't keep pace

• 72% exploit success rate - Mythos generated 181 working Firefox exploits

• Complex chains - multi-hop exploits requiring several vulnerabilities chained together

Anthropic immediately launched Project Glasswing - a $100 million consortium with AWS, Apple, Microsoft, Google, and JPMorgan Chase - just to coordinate disclosure.

Ten days later, the Cloud Security Alliance, SANS Institute, and over 100 CISOs from organizations like Google, Microsoft, CISA, and the NSA published emergency guidance titled "The AI Vulnerability Storm: Building a 'Mythos-ready' Security Program."

The industry's top security leaders are treating this as a watershed moment.

They're right.

What Makes Mythos Different

This isn't the first AI to find vulnerabilities. Google's Big Sleep, XBOW, and others have been at it since mid-2025.

But Mythos represents a capability jump:

No scaffolding required.
Previous tools needed elaborate agent frameworks and human configuration. According to Anthropic, Mythos works with a prompt that essentially amounts to "Please find a security vulnerability in this program."

Complex exploit chains.
It identifies multi-step vulnerabilities that chain several separate flaws together - the kind humans struggle to find.

One-shot exploitation.
181 working Firefox exploits compared to Claude Opus 4.6's 2 successes under identical conditions.

But here's the critical point from the CSA report:

"Mythos is likely one of many changes coming to cybersecurity risk. If not already underway, seriously consider incorporating Mythos and its implications into your strategy."

This isn't a one-time event. It's the first wave.

Why This Matters for Vendors

The time to exploitation has collapsed.

The CSA document includes the "Zero Day Clock" - a visualization showing exploitation timelines dropping from weeks in 2020 to hours in 2026.

When Sergej Epp (CISO, Sysdig) and colleagues published this data in March, time-to-exploit was already under 24 hours. Mythos accelerates that further.

For vendors, three assumptions just broke:

Assumption 1: Coordinated disclosure timelines work
The 90-day disclosure window assumes manual discovery and human-paced response. When AI finds thousands of bugs simultaneously, that model fails.

Assumption 2: You'll know if you're affected
Mythos analyzed open-source libraries and common dependencies. If you use standard development tools, vulnerabilities likely exist in your stack right now.

Assumption 3: Your current process can handle the volume
The CSA report is blunt: "Prepare to respond to more incidents. Run tabletop exercises for multiple simultaneous high-severity incidents occurring within the same week."

Most companies handle 5-10 vulnerability reports annually. They're about to receive 5-10 simultaneously.

The infrastructure is already feeling the pressure. On April 15 - eight days after the Mythos announcement - NIST announced updates to NVD operations to address record CVE growth. CVE submissions increased 263% between 2020 and 2025. The first three months of 2026 were nearly one-third higher than the same period last year.

NIST enriched nearly 42,000 CVEs in 2025 - 45% more than any prior year - but this increased productivity is not enough to keep up with growing submissions. The National Vulnerability Database is now prioritizing KEV catalog vulnerabilities, federal software, and critical infrastructure. Other CVEs will be enriched as resources allow.

This shift happened before Mythos-discovered vulnerabilities start hitting the CVE stream.

The Regulatory Convergence

This isn't happening in a vacuum.

Three major regulatory frameworks now require coordinated vulnerability disclosure:

• NIS2 (Europe) - mandatory disclosure processes

• Cyber Resilience Act - product security requirements

• US BOD 20-01 - federal vulnerability handling

The CSA report notes: "When AI can find significantly more vulnerabilities at accessible cost, the standard of what constitutes reasonable defensive effort shifts."

Boards will face questions about whether they used available AI tools for defensive scanning. Not using them may constitute negligence.

The Hopeful Part (And It's Real)

Here's where the CSA guidance gets interesting.

The same AI discovering vulnerabilities can help you find them first. The report explicitly calls for "VulnOps" - a dedicated function using AI agents to continuously audit your own code.

The shift-left opportunity:

Right now we're experiencing the painful transition - AI discovering decades of accumulated bugs. The disclosure system is overwhelmed.

But the next phase looks different:

Before production: AI analyzes code during development. Security issues get fixed in pull requests, not after deployment.

The backlog clears: Once these 27-year-old bugs are patched and AI is integrated into development workflows, the volume stabilizes at a much lower baseline.

Quality floor rises: When every pull request gets AI security analysis, entire classes of vulnerabilities become preventable.

The CSA report states: "Unlike defensive AI technologies, LLM-based vulnerability discovery capabilities are already mature and can be used to your advantage. Start immediately."

What Vendors Should Do Now

The CSA document lays out a 90-day plan. Here's generally what it looks like:

Week 1: Point AI at Your Own Code

Use the same tools attackers will use:

• Commercial: Claude Code Security (Anthropic), Codex Security (OpenAI)

• Open source: OpenAnt (Knostic), raptor, Trail of Bits agentic skills

Start by asking an agent to security-review any code. Build toward full CI/CD integration.

This Month: Build Intake

Most companies have no clear vulnerability reporting path. Fix immediately:

• Create security@yourcompany.com

• Publish security.txt at /.well-known/security.txt

• Set up auto-acknowledgment templates

• Document internal routing

Time investment: 2 hours
Impact: Prevents 90% of disclosure problems

45 Days: Prepare for Continuous Patching

Glasswing gave 40 vendors early access to Mythos. When they publish patches for AI-discovered vulnerabilities, expect a flood.

The CSA report: "Prepare triage and deployment capacity to handle a potential flood of patches as new critical vulnerabilities are disclosed."

90 Days: Prioritization Beyond CVSS

Here's the thing: your security metrics were built for pre-AI timelines. The CSA document doesn't mince words:

"Review and update security risk metrics, reporting, and business risk calculations to reflect AI-accelerated exploit timelines and attack complexity."

CVSS was built for a world where humans found vulnerabilities. It tells you severity. It doesn't tell you what to fix first.

I wrote about this challenge in February - the need to move beyond CVSS scores and focus on real-world risk factors:

• Exposure: How accessible is this to attackers?

• Impact: What happens if it's exploited?

• Exploitability: Is there a public Proof of Concept (PoC)? Is it in KEV?

• Threat signals: Is anyone exploiting this in the wild?

When AI can discover thousands of vulnerabilities simultaneously, manual prioritization breaks. You need a framework that evaluates all four dimensions together.

I'll cover how to build that prioritization framework in my next post. The AI vulnerability era requires AI-speed triage.

6 Months: Harden Fundamentals

The basics still work:

• Segmentation - limits blast radius

• Egress filtering - blocks payload downloads and command-and-control callbacks

• Phishing-resistant MFA - across all authentication

• Zero Trust architecture - where possible

Every boundary increases attacker cost.

The Human Element

Here's something most technical documents won't talk about: burnout.

The CSA report is direct:

"Burnout and attrition in security functions represent a direct operational risk. The expertise needed to navigate this transition is scarce, takes years to develop, and is not replaceable on short timescales."

Security teams are caught in a squeeze:

• AI accelerating vulnerability discovery

• Increasing patch volumes

• Uncertainty about their roles

• Pressure to integrate AI into workflows

The guidance is clear: re-prioritize, automate, and protect experienced staff.

This isn't just about tools. It's about sustainable response.

What Comes Next

The CSA document puts it plainly: "Mythos is likely one of many changes coming."

Other AI models will match these capabilities within months. Open-source versions within 6-12 months.

Vendors who build disclosure processes now will handle the transition smoothly.

The ones who wait will face crisis after crisis.

Where I'm Headed

I'm writing The Vulnerability Disclosure Handbook - a comprehensive guide to coordinated vulnerability disclosure for vendors. It covers everything from "what to say in the first 24 hours" to building lightweight PSIRTs to handling active exploitation.

The Mythos announcement - and the industry's response through CSA, SANS, and major CISOs - made this work more urgent than I expected.

Soon, I'll share the vulnerability prioritization framework vendors need when AI-discovered reports arrive at scale. It builds on the principles I introduced in February, adapted for the reality of thousands of simultaneous vulnerability reports.

For now: if you build software products, read the CSA Mythos report. Then start building your disclosure process.

You'll need it sooner than you think.

• Ten are labeled critical

• Fifteen are high

• Twenty are medium

• The rest are low or informational

The report helpfully tells you to fix everything immediately.

This is where reality kicks in.

Most organizations cannot patch every vulnerability the moment it is discovered. Resources are finite. Systems cannot always be rebooted. Business operations still matter. In practice, this leads many teams to prioritize vulnerabilities strictly by severity. Critical first. Then high. Then medium.

That approach feels rational, but it often misses real risk.

So how do you actually prioritize?

The answer starts by moving beyond severity scores and focusing on real-world risk.

Start With Exposure

Vulnerability severity, including CVSS scores, provides a rough indicator. It does not tell the whole story.

A medium-severity vulnerability on an Internet-facing system is often more dangerous than a critical vulnerability buried inside a segmented lab environment.

Start triage by looking at exposure.

Internet-facing systems

If a system is reachable from the Internet, it should always be near the top of the list. Public exposure means attacker exposure.

Internal systems with broad access

Shared file servers, identity systems, and intranet applications. If many users can access it, it can quickly become a launchpad for lateral movement.

Systems with sensitive data

Even with limited exposure, the impact of compromise can be severe. Think HR systems, financial platforms, R&D environments, or regulated data stores.

Exposure often matters more than severity.

Use the KEV List. It’s There for a Reason

The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities (KEV) catalog. This list identifies vulnerabilities that are actively being exploited in the wild.

If a vulnerability appears on the KEV list, it should be treated as urgent.

Patch it.

Mitigate it.

Isolate it.

Do not debate the CVSS score.

Adversaries do not rely on critical vulnerabilities alone. They exploit what is available, which is often what is left unpatched.

Attackers follow opportunity, not scoring systems.

Stop Thinking in Terms of Just CVSS

CVSS scores are theoretical. Attackers are not.

Many real-world intrusions begin with medium-severity vulnerabilities that are chained together. At the same time, some critical CVEs have never been exploited at all.

Instead of asking only “How severe is this?”, ask better questions:

• Is it being actively exploited?

• Is it exposed?

• What is the impact if it is compromised?

Risk lives at the intersection of exposure, exploitability, and impact.

A Practical Prioritization Model

Here is a simple structure that blends exposure, KEV status, and severity into something teams can actually act on.

In this model, sensitive data refers to vulnerabilities on systems that store or process sensitive information. Sensitive network segments refer to vulnerabilities on systems whose network position enables broader access or lateral movement.

Final Thoughts

Vulnerability management does not have to be overwhelming, but it does have to be intentional.

Focus on what actually matters:

• What is exposed?

• What is being exploited?

• What creates real risk to the business?

Patch with purpose.

Reduce noise.

And sleep better at night.

I will share more details on this approach in future posts. When I originally developed this model, I also built a set of simple prioritization calculators to help translate scanner output into actionable remediation tasks. The P1–P8 framework is a basic component of that work.

I will revisit those calculators, refine them, and share updated versions as part of a deeper series on practical vulnerability management. The goal is not more dashboards, but better decisions.

Stay tuned.

What most people don’t know is what surfaced after the heist. Reports revealed both physical and technology weaknesses at the Louvre. The museum’s director told French senators that the only camera near the point of entry was pointed west and didn’t capture the balcony itself. One report noted that across 465 galleries, only 432 CCTV cameras were installed in 2024, leaving 61 percent of galleries either unmonitored or only partially covered.

Investigations also found that parts of the museum’s video surveillance system were obsolete and protected by the password “Louvre.” The museum’s automation network included computers still running Windows 2000, which Microsoft stopped supporting in 2010. French cybersecurity audits dating back to 2014 had already warned the museum about weak passwords, unsupported software, and aging infrastructure.

Nothing indicates that these technology weaknesses played a direct role in the theft, but together they show a pattern many organizations will recognize, known issues, postponed upgrades, and slow progress toward modernization.

It’s a good time to learn from their mistakes. Especially when it comes to managing legacy technology inside an enterprise.

The Real Problem with Legacy Systems

Legacy systems don’t just exist in museums. They’re everywhere. The old file server no one wants to touch. The badge reader running on Windows XP. The cameras and lab devices that “still work fine.”

We all know why they linger:

1. They still work.

2. The vendor stopped supporting them.

3. They’re hard to isolate or replace.

4. They sit outside normal IT governance.

5. Audits identify them, but remediation gets deferred.

That’s how risk quietly becomes accepted and forgotten.

How to Fix the Problem

You can’t replace everything overnight, but you can manage legacy risk methodically. My approach is simple: Identify, Contain, Harden, Monitor, then Risk Register.

1. Identify

Inventory every system in your enterprise and identify those that are unsupported, unpatchable, or unmanaged. Label them clearly. If a device still uses a default password or runs on an outdated OS, treat it as critical. You can’t protect what you haven’t found.

2. Contain

Segment these systems on the network. Apply strict firewall rules that only allow necessary communication. Use a jump host or privileged-access tool for administration.

Even if your company hasn’t fully adopted Zero Trust, you can still apply some of its principles. Treat every device, user, and network as untrusted until verified. Apply least privilege and continuous validation.

3. Harden

Lock down what you can. Disable unused services. Remove default accounts. Turn off legacy protocols. Apply host firewalls and configuration baselines. A well-hardened legacy system is safer than a modern one left wide open.

4. Monitor

If a system can’t produce logs, monitor its network traffic. Watch authentication attempts, DNS lookups, and outbound connections. You can’t defend what you don’t see.

5. Risk Register: Retire, Replace, or Accept

Every unsupported system or unresolved vulnerability belongs on a formal risk register. Each entry should include a clear description, an assigned owner, a target timeline, and an executive signature confirming awareness and acceptance. Review the register quarterly with leadership. For each item, decide whether to retire it, replace it, or accept it.

This process identifies business risk and assigns ownership to those who can fix or fund the solution. It also documents which executives have accepted the residual risk on behalf of the business. Most importantly, it keeps those risks visible. Regular executive review turns quiet technical debt into an informed business decision.

If the Louvre had used a process like this, an entry reading “obsolete camera system – accepted risk since 2014” would have stood out long before the headlines did.

Building Toward Zero Trust

Even if your enterprise hasn’t officially adopted Zero Trust, you can start applying its core principles today. Zero Trust can seem abstract, but its fundamentals are simple.

• Verify everything: Never assume internal systems or networks are safe.

• Enforce least privilege: Users and systems should only access what they need.

• Assume breach: Design your network and access models as if compromise has already occurred.

Zero Trust doesn’t have to be an enterprise-wide initiative on day one. It can start with your legacy environments. The systems that can’t be patched or upgraded are the perfect place to prove the model works.

Summary

Legacy systems are not just old technology. They are known risks that have been allowed to remain. The solution isn’t always to replace them immediately. It’s to isolate them, harden them, monitor their behavior, and document the risk. When combined with executive ownership, this approach creates a defensible, transparent, and continuously improving security posture.

Executives understand business risk more than they understand patching cycles. A technical vulnerability becomes a business issue the moment it impacts operations or reputation.

In many organizations, the list of legacy systems is already known. The challenge isn’t discovery, it’s accountability. A formal risk register with executive signatures changes the conversation from “we know” to “we decided.” That single shift transforms a reactive security program into a proactive one.

The Louvre’s story is dramatic, but the problem isn’t unique. Learn from it before your own legacy systems make the news.

Venmo payments are public by default. Unless you adjust your privacy settings, your payment history is visible to others.

To make Venmo payments private, open the Venmo app, go to Settings → Privacy, set your Default Privacy Setting to Private, and change past transactions to private. It takes less than 60 seconds.

Most people never adjust the default visibility setting. As a result, their payment history becomes part of Venmo’s public social feed without them realizing it.

Imagine if your bank published a live feed showing who you paid, when, and why. It would feel absurd. Yet that’s essentially how Venmo works out of the box.

Sam paid Alex

🚗 Ride to the clinic 🏥

Pat paid Chris

🤨 questionable decisions 💸

It sounds ridiculous, but that’s exactly what Venmo works out of the box.

Quick Fix:

1. Open Venmo → Settings → Privacy

2. Set Default Privacy to Private

3. Tap Past Transactions → Change All to Private

How to Make Venmo Payments Private in 60 Seconds

Here’s how to lock down both your future and past Venmo activity:

1. Open the Venmo App

Make sure you’re logged in on your iPhone.

2. Tap the “Me” icon (lower right corner)

This opens your profile panel.

3. Select Settings (the gear in the upper right corner)

4. Tap Privacy

5. Set Your Default Privacy to “Private”

This will ensure that future payments are visible only to you and the recipient.

6. Change Past Transactions to Private

Scroll down and tap:

Past Transactions > Change All to Private

You’ll be prompted to confirm. Once you do, your entire payment history will be made private.

Double-Check Your Feed

To confirm your changes:

• Tap the “Me” tab in the app

• Scroll through your transactions

• Ensure none of your past payments show up with public visibility

What Does Venmo Share by Default?

If you’ve used Venmo, there’s a good chance that:

• You didn’t realize your payment history is publicly visible

• Your past payments are still viewable, even if you’ve changed your settings

• You can see your friends’ payments, and they can see yours

When you pay someone on Venmo, unless you’ve changed your privacy settings:

• The payment note and recipient are visible to the public

• The dollar amount is hidden, but context clues can reveal a lot

• Anyone using Venmo can browse the public feed and make inferences about your social habits, spending behavior, and connections

Journalists have used Venmo’s public feed to track high-profile individuals, including members of Congress.

This Isn’t Just a Quirky Social Feature. It’s a Privacy Problem.

Venmo’s default setting makes your payment history public, often without you even realizing it. While Venmo privacy settings can be changed in seconds, most users never adjust the default visibility setting.

Payment metadata tells a story.

Even if dollar amounts are hidden, transaction notes can reveal:

• Medical visits

• Travel plans

• Relationship details

• Social networks

• Spending patterns

In cybersecurity, we call this contextual exposure. Individually harmless data points can become powerful when aggregated.

Privacy is not paranoia. It’s basic hygiene.

Share This With Friends and Family

Next time you see a friend publicly paying someone, let them know their Venmo is wide open.

Better yet, send them this article.

Venmo doesn’t make this obvious, and most people have no idea their history is on display. A 60-second privacy fix can go a long way.