DEV Community: Lav Kumar Vishwakarma

Two Traefik Bugs, One Broken Boundary

Lav Kumar Vishwakarma — Wed, 28 Oct 2026 00:00:00 +0000

How a router-name collision made another tenant’s application disappear, and a cached TLS option bypassed namespace restrictions.

A few weeks ago, while digging through Traefik’s Kubernetes Ingress NGINX provider, I came across something that didn’t look quite right.

The code was generating router names by joining different Kubernetes resource identifiers with hyphens.

Nothing unusual there. I’ve written plenty of similar code myself.

But then I had a thought: What happens if those identifiers already contain hyphens?

That question eventually led me to a cross-namespace routing issue that could make another tenant’s application disappear from Traefik’s configuration.

While investigating the provider further, I found another issue involving cached TLS options and cross-namespace authorization.

Two different bugs, both involving Kubernetes namespace isolation, both reported to Traefik.

Here’s what I found, how I reproduced the problems, and what happened after reporting them.

Discovery #1: How one Kubernetes tenant could make another tenant’s route disappear

GHSA-vm53-8m79-wq7m

Researcher-assessed severity: CVSS 8.5 (High)

Let’s say you’re running a Kubernetes cluster shared by multiple teams.

Each team has its own namespace, services, and Ingress resources.

Naturally, you’d expect a team to be unable to interfere with another team’s routing just by creating an Ingress in its own namespace.

But I discovered a way this could happen.

It started with a simple naming collision

Traefik’s Kubernetes Ingress NGINX provider converts Ingress resources into internal routers.

In the version I examined, it generated router identifiers using the namespace, Ingress name, and rule/path indices.

The relevant code was essentially:

routerKey = provider.Normalize(
    fmt.Sprintf(
        "%s-%s-rule-%d-path-%d",
        loc.Namespace,
        loc.IngressName,
        loc.RuleIndex,
        loc.LocationIndex,
    ),
)

Look at these two resources:

Namespace	Ingress name
`team`	`dev-web`
`team-dev`	`web`

Although they belong to completely different namespaces, both produce:

team-dev-web-rule-0-path-0

The separator doesn’t preserve where the namespace ends and the Ingress name begins.

That alone might seem like an ordinary naming bug.

But Traefik stores its generated routers in a shared map, and the generated name is the key.

When two routers have the same key, one replaces the other.

No collision check. No warning that another namespace’s configuration has been overwritten.

And that’s where the security implications begin.

Reproducing it with the official Traefik image

I didn’t want to stop at identifying a theoretical collision.

I wanted to see what happened to actual traffic.

So I created a local Kubernetes environment with two namespaces, two independent backend services, and two Ingress resources.

I used the official traefik:v3.7.13 image for testing.

Both Ingress resources were valid. Each had its own hostname and pointed to its own healthy backend.

I expected both hostnames to work.

Instead, I got:

attacker.local -> HTTP 200
victim.local -> HTTP 404

The victim’s Ingress hadn’t been deleted.

The backend wasn’t down.

The route had simply disappeared from Traefik’s generated configuration.

Even more interesting, the outcome could change across configuration rebuilds because of Go map iteration order.

One of the two routes was always lost, but which one survived wasn’t necessarily deterministic.

Imagine debugging that in a production cluster. Everything in Kubernetes looks correct, yet an application’s route mysteriously disappears.

But could this go beyond denial of service?

This was the more important question.

An Ingress router isn’t responsible only for sending requests to a backend.

It can also have authentication, IP allow-listing, and rate-limiting middlewares attached to it.

When that router is overwritten, its middleware configuration disappears with it.

I also tested a scenario where the attacker-controlled Ingress declared the victim’s hostname.

When the attacker’s router was the surviving one, requests intended for the victim were directed to the attacker’s backend.

The result:

Host: victim.local

Name: ATTACKER-BACKEND-team-dev
HTTP 200

That demonstrated a potential cross-namespace route takeover, not merely a missing page.

The attack still required suitable resource-name combinations and the attacker-controlled router to survive the collision. It wasn’t a universal takeover of arbitrary Kubernetes namespaces.

But a tenant with permission to create an Ingress only in its own namespace could interfere with routing belonging to another tenant.

To me, that was the most important part of the discovery.

What happened after I reported it?

I submitted the finding to Traefik through its private security reporting process, including the reproduction steps and demonstrated impact.

My report assessed the issue as High severity, with a CVSS score of 8.5.

The maintainers ultimately closed the security report and handled the underlying issue as a regular bug rather than publishing it as a security vulnerability.

The fix was released on October 28, 2026.

Although the report wasn’t accepted as a security advisory, I’m glad the underlying problem was addressed.

The technical lesson remains valuable: an internal identifier shouldn’t allow two resources from different tenants to overwrite each other.

And a Kubernetes namespace boundary is only useful if the software translating Kubernetes resources into runtime configuration preserves that boundary.

Discovery #2: A TLS cache that skipped the security check

GHSA-28hp-c82p-8vqj

Official severity: Low (CVSS 4.0 score 2.1)

The second finding was a different kind of issue.

This time, the problem wasn’t how Traefik named an object.

It was how Traefik reused one.

The feature was working as intended… initially

Traefik supports the nginx.ingress.kubernetes.io/auth-tls-secret annotation, which allows an Ingress to reference a Kubernetes Secret containing a certificate authority used for mutual TLS client authentication.

Normally, Traefik restricts cross-namespace access.

The relevant setting is:

allowCrossNamespaceResources = false

That’s the default.

An Ingress in one namespace shouldn’t be allowed to use another namespace’s CA Secret unless cross-namespace access is explicitly enabled.

The provider did have a check for this.

But the interesting part was when that check ran.

What happens when the TLS option already exists?

Traefik caches and reuses generated TLS options.

That’s a sensible optimization. If multiple resources need equivalent configuration, there’s no reason to rebuild everything unnecessarily.

However, I found that the cross-namespace authorization check happened when Traefik initially built a TLS option.

When the option was already present in the shared cache, a subsequent Ingress could reuse it without going through the same namespace authorization check.

Essentially:

First Ingress
    |
    v
Check namespace permissions
    |
    v
Build TLS option
    |
    v
Store in shared cache

Later Ingress
    |
    v
TLS option already cached?
    |
    v
Reuse existing option
    |
    v
Namespace check skipped

The issue was subtle because the original authorization logic existed.

It just wasn’t applied on every relevant path through the code.

Why that matters

Suppose an Ingress in Namespace A legitimately references a CA Secret.

Traefik builds the TLS option and stores it.

Later, someone with permission to create an Ingress in Namespace B references the same CA Secret.

Even with cross-namespace resources disabled, the existing cached option could be reused.

That meant the second namespace could use a CA configuration it wasn’t supposed to reference.

The issue also allowed limited information disclosure about whether the referenced CA Secret existed and was already in use.

It did not disclose the Secret’s contents or private keys.

This is why the official advisory classifies the issue as Low severity rather than High.

Still, I find this kind of bug particularly interesting because it points to a broader engineering problem.

Authorization is not a property of a cached object. It’s a decision about who is allowed to access that object.

Just because something was authorized for one requester doesn’t mean it’s authorized for everyone who references it later.

I’ve worked extensively with backend systems, caching, and distributed architectures, and this is exactly the sort of edge case that can be overlooked when optimizing code.

A cache hit feels harmless.

Until it skips a security decision.

Disclosure and official acknowledgement

I reported this issue to Traefik, and the maintainers investigated and addressed it.

The advisory was officially published on October 16, 2026 , under:

GHSA-28hp-c82p-8vqj

The affected versions were v3.7.11 through v3.7.14, and the fix was released in Traefik v3.7.15.

The published advisory credits me as the reporter.

A CVE identifier has been requested and is currently pending assignment. I’ll update this article once it’s assigned.

The interesting connection between these two findings

After investigating both issues, something stood out to me.

The vulnerabilities were technically different, but they shared a common theme.

In the first finding, Traefik treated two different resources as if they had the same identity.

In the second, Traefik reused an already-authorized configuration without checking whether the next resource was authorized to use it.

One involved generated names.

The other involved caching.

Neither required some exotic exploitation technique.

They came down to fairly ordinary backend implementation decisions.

And that’s exactly why I think they’re worth studying.

In a single-tenant application, these choices might not cause much trouble.

But in a multi-tenant system, a small mistake in how objects are identified, stored, or reused can cross a boundary between customers or teams.

That boundary needs to survive every layer of the implementation, not just the Kubernetes RBAC configuration.

What I’d look for in similar systems

These discoveries reinforced a few things I now pay particular attention to when reviewing shared infrastructure.

Generated identifiers: If a system builds unique keys by concatenating user-controlled values, can two different inputs produce the same key?

Shared configuration maps: Can one tenant’s resource silently overwrite another tenant’s entry?

Caching and authorization: Does the authorization check still happen when the requested object comes from a cache?

Security controls attached to generated resources: What happens to authentication and rate limiting when a router or configuration object gets replaced?

Non-deterministic processing: Could the order in which configuration is generated change the effective routing or security behavior?

None of these questions is specific to Traefik.

They’re equally relevant to API gateways, Kubernetes operators, service meshes, multi-tenant platforms, and ordinary backend applications.

Disclosure timeline and current status

Discovery	Outcome
Router-name collision	Reported privately, addressed as a regular bug, fix released October 28, 2026
TLS-option authorization bypass	Published as GHSA-28hp-c82p-8vqj on October 16, 2026; fixed in v3.7.15

For clarity, my original 8.5 severity assessment belongs to the first report and does not represent an official Traefik security rating.

The first security report was closed without a public advisory or CVE assignment.

For the second, publicly acknowledged vulnerability, a CVE has been requested and is awaiting assignment.

I appreciate the Traefik maintainers for reviewing the reports and addressing the underlying issues, even though the two findings went through different disclosure outcomes.

Final thoughts

One thing I like about security research is that you don’t always need to find a complicated vulnerability to uncover an important problem.

Sometimes it’s a string concatenation.

Sometimes it’s a cache lookup.

Sometimes it’s a security check that exists in the code but doesn’t execute in the path you expected.

The difficult part is often figuring out whether that small implementation detail actually changes the security boundary.

For me, these two Traefik findings were a good reminder of something I’ve learned from building distributed systems:

Isolation isn’t guaranteed just because you’ve separated resources at the infrastructure level. Every component that processes those resources has to maintain the separation.

And sometimes, the best place to start looking is the most ordinary-looking code.

References

GHSA-vm53-8m79-wq7m — Private router-name collision report; closed and addressed as a regular bug.
GHSA-28hp-c82p-8vqj — Official Traefik security advisory for the TLS-option authorization bypass.
Traefik v3.7.15 release — Patch for the published advisory.
Traefik GitHub repository

About the author

I’m Lav Kumar Vishwakarma, a backend engineer and independent security researcher with over 10 years of experience building distributed systems. My research focuses on cloud infrastructure, application security, AI agents, and MCP security.

You can find more of my engineering work and security research at lavkumar.dev.

The Server Was Up. Its Security Policy Wasn’t.

Lav Kumar Vishwakarma — Thu, 13 Aug 2026 14:08:48 +0000

What CVE-2026-16584 in the AWS API MCP Server taught me about MCP security, fail-open systems, and the controls we place between AI agents and real infrastructure.

On July 23, 2026, AWS published a security advisory for a vulnerability I reported in the AWS API MCP Server. It was assigned CVE-2026-16584, rated High, and given a CVSS v4.0 score of 7.3.

My name appears in the acknowledgement as the independent researcher who reported it. That was a meaningful moment for me. I have spent much of my career building backend systems, and more recently I have been looking closely at the security boundaries around AI agents and MCP servers.

Still, I do not want this post to be a victory lap. The interesting part is the failure itself because it is easy to understand, easy to underestimate, and relevant far beyond one open-source project.

Here is the short version:

The server could start even when the data required to enforce its security policy had failed to load. Once that happened, the policy check could be skipped for the lifetime of the process.

The server was running. The security policy was not.

Disclosure note: This article uses only information available in the public AWS security advisory. I am not publishing a proof of concept, step-by-step reproduction instructions, private communication, internal logs, or details that AWS has not made public.

What does the AWS API MCP Server do?

The Model Context Protocol, or MCP, gives AI assistants a standard way to connect to tools and external systems. The AWS API MCP Server allows an assistant to interact with AWS services through AWS CLI commands.

That is useful, but it also places the server on a sensitive boundary. A model is no longer only producing text. It can request an action against real cloud infrastructure.

The server includes an optional, user-configured security policy. Administrators can use that policy to deny or gate selected AWS operations before they are executed.

In normal operation, the flow is simple:

The server loads the data needed to enforce the configured policy.
A tool request arrives.
The requested AWS operation is checked against the policy.
The operation is allowed, denied, or sent through a gate.

CVE-2026-16584 affected the first step, which then changed what happened at the third.

What went wrong

The AWS API MCP Server loaded its policy-enforcement data during startup. According to the advisory, if that initialization failed, the process could continue running without the enforcement data being available.

When a request arrived later, the policy check could be skipped. When a security policy was configured without fail-closed modes enabled, configured deny and gate rules were not consulted. More importantly, this was not limited to a single request. The server could stay in that weaker state for the lifetime of the process.

Stage	Expected behaviour	Vulnerable behaviour
Startup	Policy data loads	Policy data is unavailable
Readiness	Server becomes ready after its controls are ready	Server keeps running
Request	Policy evaluates the AWS operation	Policy evaluation is skipped
Result	Deny or gate rules apply	That policy layer does not restrict the operation

Initialization failures happen in production. A dependency times out. A file is malformed. Permissions are wrong. Connectivity is degraded. None of that is unusual.

The security question is what the application does after the failure.

In this case, missing enforcement state could lead to permissive behaviour. That is a classic fail-open security problem: a control becomes unavailable, but the protected operation can continue.

The guard was not defeated during a request. It was missing before the request arrived.

Why this matters for AI agent security

When people discuss AI security, the conversation quickly moves to prompt injection, model manipulation, jailbreaks, and malicious tool descriptions. Those are real problems. But this vulnerability was not caused by the model doing something clever.

It was a conventional backend security failure at an AI execution boundary.

That distinction matters. MCP servers sit between an agent’s intent and an external action. If a permission check, approval gate, tenant boundary, tool allowlist, or sandbox is absent, the model does not need to break that control. The application may already be operating without it.

This is why agentic AI security cannot be reduced to better prompts. The full execution path matters:

Which credentials does the agent use?
Which operations are exposed as tools?
Where is authorization enforced?
What happens when enforcement cannot initialize?
Does the server remain healthy when a security dependency is unhealthy?
Can the system distinguish “policy disabled” from “policy failed to load”?

These are software architecture questions, not language-model questions.

What the vulnerability did not bypass

It is important to describe the impact accurately.

CVE-2026-16584 bypassed the optional security-policy layer under the affected MCP server condition. It did not remove AWS IAM permissions from the credentials configured for the server.

If those credentials allowed only read access to a small set of resources, IAM continued to enforce that boundary. If the credentials were broad, the missing MCP policy layer left a much larger set of actions available.

The effective risk therefore depended heavily on credential scope.

This is a practical example of why AWS IAM least privilege matters. Least privilege is not only about preventing an intended user from doing too much. It also limits the damage when another security layer fails in an unexpected way.

An MCP policy can add useful context-specific restrictions, but it should not be the only boundary between an AI agent and a high-impact cloud operation.

The uncomfortable part: what does `None` mean?

The advisory maps the issue to CWE-455: Non-exit on Failed Initialization. The name sounds dry, but the design problem behind it appears in many systems.

Imagine a security component with three possible states:

The policy loaded successfully.
The administrator intentionally disabled the policy.
The administrator configured a policy, but it failed to load.

The second and third states must never be treated as equivalent.

One is an explicit configuration decision. The other is a security failure. If both become the same empty, null, or false-like value in memory, request-handling code can easily interpret “not available” as “nothing to enforce.”

That is not just an MCP concern. The same pattern can affect:

authorization configuration;
tenant context;
policy caches;
tool allowlists;
approval workflows;
audit pipelines;
sandbox initialization; and
secret and identity providers.

A missing value is not neutral when that value decides what a system is allowed to do.

Questions I would now ask in every MCP security review

This finding changed the way I think about reviewing agent infrastructure. I would not only test whether a deny rule works. I would also follow the control through its failure states.

These are the questions I would ask:

If the policy engine cannot initialize, can the server still report itself as ready?
Is “disabled by configuration” represented differently from “failed to load”?
Does the readiness check include security-critical dependencies?
What happens if policy data becomes unavailable after startup?
Are protected requests rejected while enforcement is degraded?
Is a startup error visible only in logs, or does it actually stop unsafe operation?
Do tests cover malformed configuration, timeouts, partial loading, and recovery?
Does the underlying IAM role contain only the permissions required for this agent?

The key test is not only:

Does the security control block the operation?

It is also:

Can the application continue when the security control is unable to block anything?

Fix and recommended action

AWS fixed the issue in awslabs.aws-api-mcp-server version 1.3.47.

Anyone using an affected version, from 0.2.13 up to 1.3.46, should upgrade to the latest version. Forks and derivative projects should confirm that they include the relevant fix rather than assuming their implementation is unaffected.

The AWS advisory also lists two measures for users who cannot upgrade immediately:

Run the server with least-privilege IAM credentials scoped to the specific task.
If the server started during degraded connectivity, restart it after connectivity is restored so the required policy data can load.

I would add one operational check: verify the version actually running in each environment. Updating a dependency declaration is not the same as confirming that every deployed instance has been replaced.

A note on responsible disclosure

I reported the issue privately and worked with AWS through the coordinated vulnerability-disclosure process. The vulnerability was fixed before I wrote publicly about its design implications.

Responsible disclosure is slower than posting a finding immediately, but the sequence matters. Users need a patch and clear mitigation guidance before a researcher turns a vulnerability into public content.

For the same reason, I am keeping this discussion at the architectural level. There is enough information here for engineers to recognize and test the failure pattern without turning the post into an exploitation guide.

I appreciate AWS for investigating the report, shipping the fix, publishing the advisory, and acknowledging my contribution.

The lesson I am taking from CVE-2026-16584

The most memorable security bugs are not always the most complicated ones.

Many reviews focus on finding a clever way around a running control. CVE-2026-16584 points to a simpler question:

What happens if the control never starts?

As MCP adoption grows, we will keep connecting AI agents to cloud platforms, databases, deployment systems, internal APIs, and other high-impact tools. The safety of those systems will depend on much more than model behaviour. It will depend on ordinary engineering details: initialization, state handling, readiness, credentials, error paths, and secure defaults.

My main takeaway is one line:

If the policy is not ready, the server is not ready.

That principle applies to far more than this one AWS API MCP Server vulnerability.

If you are building or reviewing an MCP server, check its startup failure paths. They may tell you more about its real security posture than the happy path does.

References

About the author

Lav Kumar Vishwakarma is a lead backend engineer and independent security researcher working on agentic AI security, MCP permission boundaries, secure tool execution, runtime isolation, and production AI systems. AWS credited him for responsibly reporting CVE-2026-16584.

DEV Community: Lav Kumar Vishwakarma

Two Traefik Bugs, One Broken Boundary

Discovery #1: How one Kubernetes tenant could make another tenant’s route disappear

It started with a simple naming collision

Reproducing it with the official Traefik image

But could this go beyond denial of service?

What happened after I reported it?

Discovery #2: A TLS cache that skipped the security check

The feature was working as intended… initially

What happens when the TLS option already exists?

Why that matters

Disclosure and official acknowledgement

The interesting connection between these two findings

What I’d look for in similar systems

Disclosure timeline and current status

Final thoughts

References

About the author

The Server Was Up. Its Security Policy Wasn’t.

What does the AWS API MCP Server do?

What went wrong

Why this matters for AI agent security

What the vulnerability did not bypass

The uncomfortable part: what does None mean?

Questions I would now ask in every MCP security review

Fix and recommended action

A note on responsible disclosure

The lesson I am taking from CVE-2026-16584

References

About the author

The uncomfortable part: what does `None` mean?