AWS Puts Elastic Beanstalk on EKS, CrowdSec Supply-Chain Breach, Critical Next.js RCE, Microsoft Disrupts EvilTokens & Why Fixing the Initial Compromise Isn’t Enough

The thing that stuck with me most this week is how many of these stories are really about trust. Not necessarily whether you trust AWS, GitHub, Microsoft, or a particular open-source project, but what happens after your systems have decided something is trusted.

That is where a lot of the interesting infrastructure and security problems seem to live now.

Take the CrowdSec incident. The initial compromise was in the software supply chain, but that was not really the end result the attacker cared about. The valuable part was the credential they were able to get from it. Once that OAuth token existed outside the environment where it belonged, fixing the original package did not fix the larger problem.

According to CrowdSec, that stolen token was eventually used to copy roughly 170 private GitHub repositories in about nine minutes.

Nine minutes.

That is not much of an incident-response window.

By the time somebody realizes something is wrong, starts a Slack thread, pulls in security, checks the logs, figures out which account is involved, and starts revoking access, the actual data movement may have been over for hours, days, or longer.

And I think that changes how we should think about containment.

We spend a lot of time talking about initial access. Patch the vulnerability. Remove the malicious package. Reimage the developer laptop. Kill the process.

Obviously you need to do all of those things.

But the question immediately after that should be: what could this thing authenticate to?

If it was a developer workstation, that answer might be GitHub, AWS, Kubernetes clusters, package registries, CI systems, internal tooling, databases, artifact repositories, or half a dozen other things.

Then you have another question: what credentials were actually present?

That sounds simple until you try answering it during a real incident.

Some credentials are short-lived. Some are not. Some are sitting in environment variables. Some are managed by credential helpers. Some are PATs somebody created two years ago. Some exist in CI. Some belong to GitHub Apps. Some are SSH keys. Some are sessions that are already authenticated.

That is why the GitHub credential inventory announcement in the lightning round is more useful than it might initially sound.

Being able to ask, “Show me the credentials capable of accessing this enterprise, who owns them, what they can access, when they expire, and when they were last used,” is useful on a normal Tuesday.

During an incident, it can become one of the first questions you need answered.

The EvilTokens story approaches the same problem from a different direction.

The part that interests me is not really “hackers are using AI.”

We have heard some version of that story enough times already.

The more interesting part is what AI becomes useful for once an attacker already has access.

A compromised mailbox can contain years of information. Thousands or tens of thousands of emails. Vendor conversations. Invoices. Org charts. Travel schedules. Internal projects. Who approves payments. Who reports to whom. Which vendors regularly ask for money. How the CFO writes. How the CEO writes. Which conversations are already happening that an attacker might be able to insert themselves into.

Historically, that is incredibly valuable information, but there is a human cost to going through all of it.

Now you can classify it.

Instead of an attacker manually reading ten thousand messages trying to understand the company, a model can help answer much narrower questions.

Who has financial authority?

Which conversations involve payments?

Who does this person regularly trust?

Which identity would be useful to impersonate?

That does not fundamentally reinvent business email compromise. It makes the information gathered after compromise much easier to use.

The device-code phishing component is interesting for a similar reason because the victim can actually be interacting with Microsoft’s legitimate authentication infrastructure.

They are not necessarily typing their password into some terrible copy of a Microsoft login page hosted on a random domain.

They can authenticate normally. They can complete MFA. Microsoft can successfully verify that they are exactly who they claim to be.

The problem is what they authorized.

That distinction matters.

We sometimes reduce authentication security to “Do we have MFA?” when the actual system is more complicated than that. MFA can verify the identity of the person completing an authentication flow. It does not automatically mean that person understands what application, device, or session they are authorizing.

Again, the system established trust. The problem happened after that.

The Next.js vulnerability is a little different, but I think there is a related engineering lesson there too.

ImageResponse sounds harmless.

If somebody told me they were investigating a critical remote code execution vulnerability and then said the affected functionality generates Open Graph images, that would not be the first place I expected them to go.

But the server does not care whether we mentally categorize something as “just an image.”

It is still executing code.

It is still processing data.

And if attacker-controlled data reaches that processing path, it is part of your attack surface.

That is also why vulnerability scanners can only take you so far.

Knowing that you have an affected version of Next.js is important. Knowing whether your application actually uses the vulnerable Node.js ImageResponse implementation, where the input comes from, and whether an attacker can control that input is what tells you how the vulnerability relates to your environment.

The same principle applies well beyond Next.js.

A dependency inventory tells you what software exists.

It does not necessarily tell you how that software is being used.

Then there is Elastic Beanstalk Cluster Mode, which is almost the infrastructure version of the same abstraction problem.

AWS is taking something developers already understand as a PaaS experience and putting shared EKS infrastructure underneath it.

I actually like that direction.

I have spent enough of my career working with Kubernetes to know that most developers should not need to understand every detail of Kubernetes just to deploy an application.

A good platform should remove unnecessary complexity.

But abstraction does not make the underlying infrastructure stop existing.

If multiple applications are now sharing infrastructure, somebody still needs to understand what that means for isolation, resource contention, upgrades, capacity, and blast radius.

The developer experience can be:

“Here is my application. Please run it.”

That is great.

The platform engineering experience still has to include:

“What happens when the thing underneath all of these applications has a bad day?”

And that is probably the thread connecting most of this week’s stories for me.

We keep building better abstractions around infrastructure, authentication, dependencies, and developer workflows. That is generally a good thing. Engineers should not have to manually reason about every implementation detail every time they deploy an application or authenticate to a service.

But abstractions create boundaries where we can forget what is happening underneath them.

A valid token does not mean the person using it should still have it.

A successful MFA challenge does not mean the user intended to authorize that session.

An image-generation endpoint is not automatically harmless because its output is a PNG.

A managed platform running on Kubernetes does not eliminate Kubernetes failure modes.

And removing the thing that originally compromised you does not revoke everything the attacker may have already taken.

The abstraction can simplify the normal path.

You still need to understand the trust underneath it when the normal path breaks.

That is usually where the incident starts getting interesting.