From Apache Struts to JWT bypasses, why the most dangerous bugs sit at the trust boundary

Every few years the software industry rediscovers the same uncomfortable truth:

The most catastrophic vulnerabilities are rarely memory corruption bugs or cryptographic failures.

They happen when a system misplaces trust.

When that happens, a single request can cross the boundary between untrusted input and trusted identity.

Once that boundary collapses, everything behind it collapses with it.

Over the past decade several major incidents have illustrated this pattern.

• The Apache Struts vulnerability that enabled the Equifax breach

• The Log4Shell vulnerability in Log4j that affected much of the internet

• Microsoft Entra actor tokens that enabled cross-tenant privilege escalation

• And recently, a JWT authentication bypass in the Java library pac4j

At first glance these incidents appear unrelated.

They involve different technologies, different languages, and different attack surfaces.

But technically they share the same root cause:

a failure at the trust boundary.

Understanding this pattern is far more valuable than understanding any single vulnerability.

Because these bugs will keep appearing.

The Apache Struts Lesson: When Input Becomes Code

In 2017 the Equifax breach exposed the personal data of roughly 147 million people.

The attack traced back to Apache Struts CVE-2017-5638, a vulnerability in the framework’s file upload parser.

The flaw allowed attackers to inject malicious expressions into the Content-Type header of HTTP requests.

That header passed through a component responsible for parsing multipart uploads.

Under certain conditions, the parser evaluated attacker-controlled expressions inside the Java OGNL expression language.

The result was remote code execution.

The boundary that failed was simple:

User input should never be executed as code.

But once that boundary broke, attackers gained full control of the system.

The Log4Shell Lesson: When Logging Becomes Execution

Fast forward to 2021.

Another boundary failure shook the software ecosystem.

The vulnerability known as Log4Shell (CVE-2021-44228) affected the widely used logging library Log4j.

The vulnerability occurred when Log4j attempted to resolve JNDI lookups embedded in log messages.

An attacker could send a string like:

When that string was logged, the library would perform a remote lookup.

In many environments this resulted in remote code execution.

The trust boundary that failed was:

Logging systems are supposed to record data.

Instead, Log4j treated input as instructions.

That mistake allowed attackers to execute code simply by causing a server to log a malicious string.

The vulnerability was so widespread that even Minecraft servers were vulnerable.

A chat message could trigger the exploit.

The Identity Layer: When Tokens Become Authority

More recently, researchers uncovered a critical vulnerability in Microsoft’s identity infrastructure involving Entra ID actor tokens.

The issue is documented as CVE-2025-55241.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241

Research by Dirk-Jan Mollema showed how actor tokens could be abused to obtain global administrator privileges across tenants.

https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/

The vulnerability emerged from the way identity delegation tokens were interpreted inside the authentication pipeline.

Actor tokens were meant to represent delegated actions performed on behalf of another identity.

But under certain conditions the system treated those tokens as fully authoritative identities.

The boundary that failed was:

Once that boundary collapsed, an attacker could escalate privileges across entire Entra tenants.

This is the same pattern again.

A small misinterpretation at the trust boundary leads to catastrophic impact.

The JWT Layer: When Encryption Becomes Authentication

Recently, our security research team encountered another example of this pattern while analyzing authentication flows in the Java ecosystem.

The vulnerability was discovered in pac4j-jwt, a module used for handling encrypted and signed JWT authentication tokens.

The issue has been assigned CVE-2026-29000.

At first glance the system appeared robust.

The authentication pipeline implemented two protections:

1. JWE encryption

2. JWS signatures

The intended validation flow looked like this:

But a subtle control-flow issue allowed attackers to skip signature verification entirely.

If the decrypted payload contained an unsigned JWT (PlainJWT), the library’s parser returned null.

The authentication code only verified the signature when the parsed token was not null.

Which meant the following execution path existed:

In other words, the authentication system authenticated a token that had never been authenticated.

A Recurring Security Pattern

Looking at these incidents side by side reveals a recurring pattern.

Different technologies.

Same structural flaw.

A system assumed something about its input that the specification did not guarantee.

Attackers exploit exactly those assumptions.

A Timeline of Trust Boundary Failures

Major security incidents over the past two decades show a recurring pattern: systems fail when untrusted input crosses a trust boundary without proper verification.

Below is a simplified timeline illustrating how this pattern has appeared across different technologies.

Each vulnerability appeared in a completely different system.

But each one failed at the same architectural boundary:

untrusted data↓assumed trusted↓system compromise

untrusted data↓assumed trusted↓system compromise

The technologies evolve.

The trust boundary failures remain the same.

Why These Bugs Are Hard to Detect

Traditional security analysis focuses on obvious failure modes:

• memory corruption

• cryptographic weaknesses

• access control mistakes

But trust boundary failures are harder to detect.

Because every individual component behaves correctly.

In the pac4j case:

• the JWT specification correctly allows PlainJWT

• the parsing library correctly returns null

• the authentication code correctly checks for null

Each line of code is reasonable.

The vulnerability emerges only when those pieces interact.

This class of bug is sometimes called a composition vulnerability.

And it is becoming more common as modern software stacks grow more complex.

The Security Industry Keeps Relearning This Lesson

What makes these incidents notable is not the individual vulnerabilities.

It’s the pattern.

Every few years, the industry encounters a vulnerability that exposes the fragility of its trust boundaries.

The Apache Struts exploit showed how input validation failures can lead to catastrophic breaches.

Log4Shell showed how seemingly harmless systems like logging infrastructure can become execution engines.

Identity token flaws demonstrated how authentication layers can misinterpret authority.

And JWT verification failures show how easily authentication guarantees can disappear.

The details change.

The lesson stays the same.

The Real Security Question

The most important question in any system design is not:

“Is this input valid?”

The real question is:

“What assumptions are we making about this input?”

Because attackers will always test the assumptions.

Not the obvious paths.

The edge cases.

The specification-allowed behaviors developers never expected.

That is where the trust boundary breaks.

Final Thought

Every critical vulnerability teaches the same architectural lesson.

Security systems do not fail when primitives fail.

They fail when trust is misplaced.

The moment a system assumes something about its inputs that the specification does not guarantee, attackers gain an opening.

And history shows that when the trust boundary breaks, the consequences can be enormous.

From Apache Struts.

To Log4Shell.

To identity token vulnerabilities.

To JWT authentication bypasses.

The technologies change.

The pattern does not.