Post cover image

September 23, 2026

Security Context Dies at Boundaries

Five real-world findings and a reusable method for finding vulnerabilities where trust gets lost between components.

By Berkan SAL

11 min read

Five real-world findings and a reusable method for finding vulnerabilities where trust gets lost between components.

After spending enough time reviewing security-sensitive systems, individual vulnerabilities start looking less individual.

The technologies change.

One bug is in a browser-facing development server.

Another is in a WebSocket stream.

Another appears in an identity platform.

Another lives inside SSRF protection.

Another is buried in a DeFi oracle calculation.

Yet the same structural failure keeps appearing:

A security property exists on one side of a boundary, but does not survive the transition to the other side.

Identity disappears.

Provenance disappears.

Network semantics become strings.

Graph relationships become local booleans.

Independent measurements collapse into the same value.

The security check may still exist.

But the context that gave the check meaning is gone.

I have started treating this as a distinct research pattern:

Boundary-State Auditing

The idea is simple:

Whenever data, authority, identity, or security evidence crosses a boundary, ask what gets lost, rewritten, merged, inherited, or silently defaulted.

This article develops that idea using five security findings I worked on:

  • Nuxt — CVE-2026–49993
  • Nezha — GHSA-q6xx-5vr8-p898
  • authentik — GHSA-h6c5-mpvq-j4jc
  • Formbricks — ENG-1326 / PR #8946
  • Olas — Code4rena H-02

They look unrelated.

I do not think they are.

Security Is Usually Correct Locally

The dangerous thing about boundary bugs is that each component often looks reasonable in isolation.

Consider a system with:

Component A
    ↓
Component B

Component A may correctly establish some security fact:

user = Alice

or:

request came from same origin

or:

price A is the current pool price

or:

this IP belongs to network X

Then information crosses a boundary.

And Component B receives a reduced representation:

stream UUID

or:

missing headers

or:

string prefix

or:

uint160

The security meaning existed before the transformation.

Afterward, only the representation remains.

That is where interesting bugs begin.

Case 1 — Browser → Server

CVE-2026–49993

The first example came from Nuxt's webpack/rspack development server.

The protection attempted to determine whether a request was same-origin using several browser signals:

Sec-Fetch-Site
Origin
Referer

This seems like redundancy.

If one signal is missing, another may still identify the initiator.

The interesting condition appeared when the browser crossed several behavioral boundaries simultaneously.

A request could arrive with:

Sec-Fetch-Site = absent
Origin         = absent
Referer        = absent

The previous logic treated the exhaustion of all security evidence as a compatibility case.

Conceptually:

if (securityMetadataExists) {
    validate();
}
return true;

The attacker did not need to forge trusted metadata.

The attacker needed the metadata to disappear.

The vulnerable transition was:

Browser security context
        ↓
HTTP request
        ↓
context missing

The server still had a request.

It no longer had enough evidence about where the request came from.

Yet the absence of evidence became permission.

The patch changed that boundary condition: when all origin signals are missing, requests are accepted only when the development server is loopback-bound.

The broader pattern is:

When provenance is optional in transit, audit the state produced when all provenance disappears.

Case 2 — Creation → Consumption

GHSA-q6xx-5vr8-p898

Nezha exposed another version of the same structural problem.

A user could create a terminal or file-manager stream.

At creation time, authorization existed:

Alice
  ↓ authorized for
Server X
  ↓ creates
Stream S

But the temporary stream stored essentially:

S

not:

S belongs to Alice

Later, another request attached to:

/ws/terminal/S

The application could answer:

Does S exist?

but it had lost the context necessary to answer:

Does S belong to the current principal?

The transition looked like:

Alice + authority + resource
            ↓
       stream creation
            ↓
          UUID

A rich security object had been compressed into an identifier.

The UUID survived.

The principal did not.

This is what I described as a principal-unbound capability.

The fix restored the missing relationship:

Stream
  └── creatorUserID

Now the second phase can reconstruct the original security invariant.

The broader pattern is:

Whenever authorization occurs in one request and an operation is consumed in another, trace which parts of the original principal context survive.

Case 3 — Object → Graph

GHSA-h6c5-mpvq-j4jc

authentik exposed a different boundary.

Here the information was not lost between requests.

It was lost between levels of abstraction.

A delegated administrator might legitimately have permission to modify:

Group A

A local authorization decision therefore asks:

Can Alice manage Group A?

But groups exist in a hierarchy.

Roles can be assigned.

Privileges can be inherited.

Membership creates new edges.

So the real security system looks more like:

Alice
  ↓ manages
Group A
  ↓ parent / role / membership
Group B
  ↓
Superuser privilege

The immediate object can be unprivileged while its reachable graph is highly privileged.

The boundary here is:

local object state
       ↓
graph-effective state

Checking only:

group.is_superuser

can miss:

group → parent → superuser group

Likewise, permission to edit a group does not necessarily imply permission to connect that group to a powerful role.

The vulnerable system reasoned locally.

The privilege system behaved transitively.

The broader pattern is:

Whenever security relationships form a graph, audit the privilege delta of the resulting graph — not only the object being modified.

Case 4 — Representation → Network Semantics

Formbricks ENG-1326 / PR #8946

Formbricks' webhook SSRF protection showed yet another boundary mismatch.

The security policy was about networks:

224.0.0.0/4
fe80::/10
100.64.0.0/10

But parts of the implementation represented those networks using regular expressions and string prefixes.

For example, conceptually:

/^224\./

was documented as:

224.0.0.0/4

But those are not equivalent.

The regex describes:

224.0.0.0/8

while the CIDR covers:

224.0.0.0
through
239.255.255.255

Likewise:

startsWith("fe80:")

does not represent the full semantics of:

fe80::/10

The policy lived in network space.

The implementation lived in string space.

The transition was:

network semantic object
        ↓
text representation
        ↓
security decision

Information was lost during representation.

The eventual remediation moved the classifier toward actual CIDR semantics using Node's net.BlockList.

The broader pattern is:

If a security property belongs to a structured semantic domain, audit every place it is reduced to text.

Strings do not inherently understand networks.

Just as they do not inherently understand paths, origins, domains, identities, or authorization.

Case 5 — Measurement → Decision

Olas Code4rena H-02

The Olas finding demonstrates perhaps the most subtle form.

A TWAP deviation check needed two independent values:

spot price

and:

historical TWAP

The security property exists because those measurements come from different temporal states.

Conceptually:

current market
     ↓
spot
historical market
     ↓
TWAP
spot vs TWAP
     ↓
security decision

But a variable overwrite caused the value representing the spot price to be replaced with the TWAP-derived value.

The program still had two variables.

The code still had a comparison.

But semantically:

TWAP
 ├──→ value A
 └──→ value B

The boundary between two independent measurements had collapsed.

So:

A vs B

became:

X vs X

and:

deviation = 0

The security check ran successfully.

It simply had no causal connection to market manipulation anymore.

The broader pattern is:

Whenever a security control compares independent observations, trace their provenance until the final decision and verify that independence survives.

Five Bugs, Five Things That Disappeared

Put these findings side by side.

Nuxt

Lost:

request provenance

Boundary:

browser → HTTP server

Nezha

Lost:

principal ownership

Boundary:

resource creation → resource consumption

authentik

Lost:

transitive privilege context

Boundary:

local object → authorization graph

Formbricks

Lost:

network semantics

Boundary:

CIDR/network → textual representation

Olas

Lost:

measurement independence

Boundary:

data acquisition → security comparison

Different software.

Same family of reasoning failure.

Security Context Compression

A useful way to think about this is security context compression.

Systems constantly compress rich objects into simpler representations.

For example:

Authenticated principal
→ user ID
Authorized terminal session
→ UUID
Network
→ string
Privilege graph
→ boolean flag
Verified measurement
→ integer

Compression is necessary.

Software cannot carry the entire universe of context everywhere.

The problem appears when the discarded information was necessary to preserve the security invariant.

Mathematically, imagine:

RichState = R

and a transformation:

f(R) = r

If two security-distinct states:

R1 ≠ R2

collapse into the same representation:

f(R1) = f(R2)

then downstream code may no longer be able to distinguish safe from unsafe behavior.

That is an extremely interesting audit boundary.

Ask What Became Indistinguishable

This gives us a useful vulnerability-research question:

Which two states that should have different security outcomes become indistinguishable after this transformation?

For Nuxt:

legitimate request with missing metadata

and:

cross-origin malicious request with suppressed metadata

could become:

no security headers

For Nezha:

Alice using stream S

and:

Bob using stream S

could become:

valid UUID S

For an authorization graph:

ordinary child group

and:

child group that reaches superuser privilege

may both locally appear:

is_superuser = false

For an SSRF classifier:

fe80::1

and:

fe9f::1

may differ under a textual prefix despite sharing the same relevant network classification.

For Olas:

spot = manipulated
TWAP = historical

collapsed into:

TWAP vs TWAP

Security bugs often hide inside these equivalence classes.

Boundary-State Auditing

This suggests a systematic methodology.

When reviewing a security-sensitive system, identify every important boundary.

Examples:

browser → backend
frontend → API
API → worker
request 1 → request 2
tenant → shared service
parser → consumer
string → structured object
object → graph
oracle → protocol
agent → tool
tool → external service
sandbox → host

Then perform the following analysis.

Step 1 — Write the Security Invariant

Before looking for bypasses, state what must remain true.

Examples:

Only the creator may attach to this stream.
Cross-origin pages must not read development output.
A delegated administrator must not create greater privilege than they possess.
Webhook requests must not reach internal infrastructure.
Liquidity operations must stop when spot price deviates too far from TWAP.

If you cannot articulate the invariant, it is difficult to know which context matters.

Step 2 — Identify the Evidence Supporting It

For each invariant, determine which information makes the decision possible.

Example:

Only creator may attach

requires:

currentUser
streamOwner

Same-origin protection may require:

Sec-Fetch-Site
Origin
Referer
Host
network binding

TWAP protection requires:

spot measurement
historical reference

Graph authorization requires:

actor permissions
target node
reachable privilege edges

These are the security inputs.

Step 3 — Follow Them Across Boundaries

Now trace every transformation.

For example:

current user
↓
session middleware
↓
stream creation
↓
UUID
↓
WebSocket attachment

Ask at each step:

Does user identity still exist?

For SSRF:

URL
↓
URL parser
↓
hostname
↓
DNS
↓
address
↓
family classification
↓
CIDR classification
↓
socket

Ask:

Does the destination retain the same meaning at every layer?

Step 4 — Look for Six Boundary Failures

I currently find six transformations particularly interesting.

1. Drop

Security metadata disappears.

Origin → absent

2. Rewrite

A value changes semantic meaning.

spotPrice variable → TWAP price

3. Compress

A rich object becomes a weaker identifier.

authorized stream → UUID

4. Inherit

Privilege arrives indirectly.

child group → parent → admin

5. Reinterpret

Two components parse the same representation differently.

validator IP semantics ≠ network stack semantics

6. Fallback

Failure of the security mechanism selects a weaker mode.

TWAP unavailable → trust spot

These six operations are excellent places to hunt.

Step 5 — Test the Empty State

A large number of security bugs hide in absence.

Ask:

What if identity is missing?
What if the header is missing?
What if the role is missing?
What if the oracle fails?
What if the type cannot be classified?
What if there is no history?

Then determine whether the system behaves:

fail closed

or:

fall back to weaker assumptions

The empty state deserves first-class test coverage.

Step 6 — Test the Alias State

Another powerful test is aliasing.

Can two supposedly distinct security values become the same thing?

Examples:

expected == attacker-controlled
spot == TWAP
resource ID == credential
tenant ID == caller-supplied ID
validated path object == original unsafe string

Security comparisons depend on meaningful separation.

Aliasing destroys that separation.

Step 7 — Test the Transitive State

For graph-like systems, direct relationships are not enough.

Ask:

What becomes reachable?

Not:

What changed directly?

A mutation may create:

User → Group

which creates:

User → Group → Parent → Role → Admin

The dangerous state can be multiple hops away.

Step 8 — Prove the Guard Can Reject

This is one of my favorite checks.

Take every important security mechanism and ask:

Can I construct a realistic hostile state that causes this check to deny the operation?

A TWAP guard should demonstrably reject a manipulated spot price.

An authorization check should demonstrably reject the wrong user.

An SSRF classifier should reject addresses throughout the entire forbidden CIDR, including boundaries.

A same-origin guard should reject a browser-reachable cross-origin request.

If you cannot make the protection fire, you may have discovered something important.

Security Controls Need Causal Influence

A security control should have authority over the protected action.

Conceptually:

hostile state
     ↓
security observation
     ↓
decision
     ↓
dangerous operation

If hostile changes do not affect the decision:

hostile state changes
     ↓
decision stays constant

then the control may be disconnected.

Likewise, if the decision correctly rejects the operation but side effects already occurred before authorization, the control is too late.

A good security review therefore follows the entire chain:

source
→ representation
→ transformation
→ policy
→ decision
→ side effect

not merely the if statement in the middle.

Boundaries in Modern AI Systems

I think this methodology becomes especially relevant for AI agents.

Agent infrastructure contains boundaries everywhere:

User
 ↓
Agent
 ↓
Planner
 ↓
Tool
 ↓
Connector
 ↓
Credential
 ↓
External system

Security context can disappear at any transition.

Examples:

Approval context

User approved operation X

becomes:

tool call ID

Does the executor still know exactly what was approved?

Principal context

User A started agent run R

becomes:

run_id = UUID

Can User B attach to R?

Sanitization boundary

policy engine validates sanitized arguments

but:

executor receives original arguments

Credential graph

User can edit Agent A
Agent A can attach Tool B
Tool B carries admin credential C

Can editing the agent make credential C reachable?

Provenance loss

trusted system instruction
untrusted retrieved text
user input
tool output

may all eventually become:

plain context tokens

The entire field is full of security-context compression.

A Boundary Audit Table

For complicated systems, I like the idea of maintaining something like:

BoundaryContext BeforeRepresentation AfterSecurity QuestionBrowser → serverorigin provenanceHTTP headersWhat if headers disappear?Session creation → WebSocketprincipal + authorityUUIDIs the UUID bound to creator?Group → hierarchylocal permissionsgraph edgesWhat privilege becomes reachable?URL → socketnetwork destinationtext/parser outputDoes interpretation change?Oracle → guardindependent measurementsnumeric variablesDid provenance collapse?Agent → toolapproval + principaltool requestDoes authority survive delegation?

This makes invisible assumptions visible.

And assumptions are usually where the interesting research lives.

Security Bugs Often Live Between Correct Components

This is perhaps the most useful conclusion.

Component A can be correct.

Component B can be correct.

The transformation between them can still be unsafe.

For example:

URL parser is correct.
CIDR library is correct.
But the application's conversion between them is wrong.

Or:

initial authorization is correct.
WebSocket implementation is correct.
But ownership is lost between creation and attachment.

Or:

oracle is correct.
deviation math is correct.
But a variable overwrite destroys independence between inputs.

This is why boundary auditing is powerful.

Traditional review often asks:

Which component contains the bug?

Boundary review asks:

Which security property failed to survive the handoff?

Those are not the same question.

From Bug Hunting to Invariant Hunting

Individual payloads are temporary.

Security invariants are reusable.

Instead of collecting:

SSRF payloads
header bypasses
IDOR parameters
oracle tricks

I want to collect questions.

Questions like:

What context disappears here?
What does this identifier actually authorize?
What privilege becomes reachable after this edge is created?
Do validator and consumer interpret this value identically?
Are these two supposedly independent values still independent?
What happens when the security mechanism fails?
Can the security guard ever reject a real hostile state?

Those questions transfer between technologies.

That is what makes them useful.

Conclusion

The five findings discussed here span web security, authorization, identity infrastructure, SSRF, and smart contracts.

Their implementation details are unrelated.

Their failure mode is not.

In every case, a security property depended on context.

Then some boundary changed that context:

provenance disappeared
ownership disappeared
privilege became transitive
network semantics became strings
independent measurements became aliases

The system continued operating.

The security invariant did not.

That leads to the research principle I now use:

Find boundaries where rich security context is transformed into a weaker representation, then test which security distinctions disappear during that transformation.

Do not only audit values.

Audit their provenance.

Do not only audit objects.

Audit relationships.

Do not only audit checks.

Audit whether hostile state can influence their decisions.

And whenever one subsystem hands something to another, ask the question that keeps producing interesting results:

What did we know before this boundary that we no longer know afterward?

That missing information may be the vulnerability.

Research referenced in this article

Nuxt — CVE-2026–49993 / GHSA-x6qj-4h56–5rj5 Same-origin protection bypass when Sec-Fetch-Site, Origin, and Referer are all absent.

Nezha — GHSA-q6xx-5vr8-p898 Cross-user terminal/file-manager stream hijacking caused by stream UUIDs without creator binding.

authentik — GHSA-h6c5-mpvq-j4jc Privilege escalation through delegated group/user management and effective authorization relationships.

Formbricks — ENG-1326 / PR #8946 Webhook SSRF classification gaps caused by regex/string-prefix representations of network ranges.

Olas — Code4rena H-02 TWAP deviation protection rendered ineffective after a variable overwrite caused the security comparison to collapse onto the same underlying value.