From mTLS to MCP: 8 Published CVEs From Vulnerabilities I Reported in May

A short reflection on a month of security research across Traefik, SimpleSAMLphp, rclone, and ProxySQL

In May, I reported several vulnerabilities across different open-source projects. Eight of them have already been published as CVEs.

The research covered a surprisingly broad set of areas: mutual TLS, SAML, HTTP-Artifact validation, file path handling, remote control interfaces, ProxySQL packet parsing, and newer MCP / GenAI-related attack surfaces.

What made this month especially interesting was not only the number of published issues, but also the variety of security boundaries involved. Some of the vulnerabilities were classic in nature, such as path traversal or memory corruption. Others were more subtle and appeared at the intersection of multiple layers, where different components made different assumptions about the same trust boundary.

This post is a short summary of what was published, what kinds of systems were affected, and what I found most interesting from a security research perspective.

The published CVEs

The eight CVEs published from my May reports were:

CVE-2026–53622 — Traefik

HTTP/3 mTLS bypass in router-specific TLSOptions selection

This issue affected Traefik deployments that relied on router-specific TLSOptions as an access-control boundary.

The interesting part here was the interaction between HTTP/3, TLS configuration, and router selection. When security decisions depend on the correct mapping between transport-layer properties and application-layer routing, even small inconsistencies can become security-relevant.

In this case, the trust boundary was not simply "does this endpoint require mTLS?" but rather "does the correct TLS policy get selected for this specific router under this protocol path?"

That distinction matters.

CVE-2026–48491 — Traefik

Domain-fronted mTLS bypass with wildcard TLSOptions

This was another Traefik mTLS-related issue, but with a different root cause.

The vulnerability involved wildcard TLSOptions and domain-fronting-style behavior. In practice, this kind of issue is interesting because the system may appear to enforce mutual TLS correctly when viewed from one layer, while another layer interprets hostnames, SNI, or routing metadata differently.

These bugs are a good example of why TLS policy, SNI handling, hostname validation, and routing logic need to be reasoned about together.

Security controls that look correct in isolation can fail when the surrounding assumptions do not line up.

CVE-2026–49980 — rclone

Missing authentication in rc --rc-serve, leading to dangerous backend instantiation

This vulnerability affected rclone's remote control file-serving functionality.

The issue was a missing-authentication bug in a path that could lead to dangerous backend instantiation. From a research perspective, this was interesting because remote-control interfaces often contain powerful primitives by design. They are meant to expose administrative or automation capabilities, so the difference between "authenticated" and "accidentally reachable" can be very significant.

The lesson here is straightforward: when an interface can instantiate backends, access files, or trigger behavior across different storage providers, authentication must be consistently enforced across every reachable path.

It is not enough for the main API surface to be protected if an alternate handler can reach sensitive functionality.

CVE-2026–49284 — SimpleSAMLphp

ExpectedIssuer and InResponseTo binding bypass

This issue affected SAML SP-initiated login flows, especially in multi-IdP environments.

SAML vulnerabilities are often subtle because the security model depends heavily on correct binding between identity provider metadata, request state, response state, issuer validation, and replay protections. The individual pieces may all exist, but the vulnerability appears when they are not bound together strongly enough.

The important question is not only "is the SAML response signed?" or "is the issuer known?" The important question is:

Is this the expected issuer for this specific authentication flow and this specific request state?

That is where these classes of bugs become interesting.

CVE-2026–49283 — SimpleSAMLphp SAML2

HTTP-Artifact TLS validator confusion

This issue was related to HTTP-Artifact validation in SimpleSAMLphp's SAML2 libraries.

HTTP-Artifact flows are a particularly interesting area because validation does not happen only in the browser-facing SAML response path. There is also a back-channel exchange, and that exchange may rely on TLS validation, artifact resolution, metadata, and trust decisions that are easy to reason about incorrectly.

Validator confusion bugs are often not about a missing check in the obvious place. Instead, they happen when the wrong validator, wrong trust assumption, or wrong context is applied to a security-sensitive operation.

That makes them harder to spot during normal code review, because the code may still appear to be "doing validation."

The real question is whether it is doing the right validation for the right peer in the right context.

CVE-2026–46491 — SimpleSAMLphp casserver

Path traversal in FileSystemTicketStore

This was a more classic vulnerability: path traversal in a file-based CAS ticket store.

Path traversal bugs are well-known, but they remain relevant because file-backed stores often sit close to sensitive application state. If user-controlled or attacker-influenced data can affect file paths without proper normalization and containment, the impact can become serious depending on deployment context.

What I like about these findings from a research perspective is that they are simple, concrete, and easy to underestimate.

Modern systems often contain complex cryptographic protocols and distributed trust models, but sometimes the bug is still: Can attacker-controlled input escape the intended directory?

The classics are still alive.

CVE-2026–48773 — ProxySQL

Pre-authentication first-packet heap overflow

This vulnerability affected ProxySQL's first-packet handling for database protocols.

Pre-authentication memory corruption is always an important class of bug, because the attack surface is reachable before the system has established who the client is. In network-facing infrastructure, parsing unauthenticated input safely is one of the most critical responsibilities of the software.

This kind of issue is also a reminder that protocol parsers deserve special attention. The first packet received by a service may look like a small implementation detail, but it often carries a lot of implicit trust assumptions:

• What minimum length is expected?
• What protocol variant is being parsed?
• Which fields are available before authentication?
• Are all length values checked before use?
• Are edge cases handled consistently across supported protocols?

Bugs in this area can have serious impact because they sit at the very edge of the system.

CVE-2026–48774 — ProxySQL

MCP run_sql_readonly multi-statement policy bypass

This was one of the most interesting findings from the month because it involved a newer type of attack surface: MCP / GenAI-related database tooling.

The vulnerability affected ProxySQL's MCP run_sql_readonly tool for MySQL targets. The core problem was a read-only policy bypass through multi-statement behavior.

What made this issue notable was the gap between the declared security contract and the actual execution semantics.

A tool may be named run_sql_readonly. A surrounding system may assume it can only execute read-only queries. An AI agent or automation layer may treat it as safe.

But the database engine and SQL parser still decide what actually gets executed.

That mismatch is exactly where security problems emerge.

As more products expose operational capabilities to LLMs, agents, and MCP-style interfaces, these trust boundaries will become increasingly important. It is not enough to label a tool as safe. The implementation has to enforce that safety property under all relevant parsing and execution paths.

What connected these findings?

At first glance, these vulnerabilities look quite different.

They affected different projects. They involved different technologies. They ranged from SAML to mTLS, from file path handling to memory corruption, from reverse proxy routing to GenAI-related database tooling.

But there was a common pattern behind many of them:

The vulnerability appeared where two layers disagreed about a security boundary.

Some examples:

TLS vs HTTP routing

In the Traefik issues, the relevant question was not only whether mTLS existed as a feature. The important part was whether the correct TLS policy was selected and enforced for the correct route, hostname, and protocol path.

When transport-layer identity and application-layer routing interact, the boundary can become fragile.

SAML state vs issuer validation

In the SimpleSAMLphp findings, the security-sensitive question was not simply whether validation existed. The question was whether the response was validated in the correct state context, with the expected issuer and the expected request relationship.

SAML is full of situations where validating "something" is not enough. The validation has to be tied to the right authentication transaction.

Authenticated API vs alternate code paths

In the rclone issue, the interesting part was how a powerful capability became reachable through a path where authentication was not consistently enforced.

This is a common class of bug in administrative interfaces. The main API path may be well protected, but an alternate handler, compatibility path, file-serving mode, or helper feature can accidentally expose similar functionality.

Declared policy vs actual execution

In the ProxySQL MCP issue, the declared contract was read-only behavior. But the enforcement had to survive real SQL execution semantics, including multi-statement behavior.

This is especially important for AI-connected tools. A tool description is not a security boundary. Naming something "readonly" is not enforcement. The actual system must make unsafe execution impossible.

Parser assumptions before authentication

The ProxySQL memory corruption issue was a reminder that the first bytes received by a service can be some of the most security-critical bytes in the entire system.

Before authentication, the parser is the boundary.

Why these bugs are interesting

Security research often rewards looking at the places where abstractions meet.

A single component may look correct. A single function may appear to validate input. A single policy may seem clear.

But real systems are made of layers:

• TLS
• routing
• authentication
• authorization
• protocol parsing
• metadata
• state machines
• storage backends
• SQL execution
• agent/tool interfaces

Vulnerabilities often appear when those layers make different assumptions.

One layer believes a decision has already been made. Another layer believes the decision will happen later. A third layer exposes an alternate path that bypasses both.

That is where the interesting bugs tend to live.

A note on MCP and GenAI-related attack surfaces

The ProxySQL MCP finding stood out to me because it touches a broader trend.

As more systems expose tools to AI agents, MCP servers, automation workflows, and natural-language interfaces, we are creating new security boundaries around old primitives.

Running SQL is not new. Read-only database access is not new. Policy enforcement is not new.

But exposing those capabilities through agent-facing interfaces changes the way people reason about them.

The risk is that the tool description becomes a mental shortcut:

"This tool is read-only, so it is safe."

From a security perspective, that is not enough.

The implementation must enforce the policy regardless of how the query is phrased, how many statements are supplied, how the database parses the input, or how the calling layer describes the tool.

This will likely become a very important area of security research over the next few years.

Responsible disclosure and maintainers

All of these findings were reported through responsible disclosure processes.

I want to thank the maintainers involved for reviewing the reports, confirming the issues, coordinating fixes, and publishing advisories. Handling vulnerability reports takes time and effort, especially in open-source projects where maintainers often have limited resources.

Good vulnerability handling is not just about fixing a bug. It also requires understanding impact, preparing patches, coordinating disclosure timelines, communicating clearly with users, and sometimes improving tests or assumptions around the affected area.

That work matters.

Takeaways

For me, this month reinforced a few important lessons:

1. Trust boundaries are often cross-layer

Do not analyze TLS, routing, authentication, and authorization as completely separate systems when they are used together to enforce access control.

The boundary is the combination of all of them.

2. Validation must happen in the right context

A check is only meaningful if it validates the right thing against the right expectation.

This is especially true in SAML and other stateful authentication protocols.

3. Tool names are not security controls

A function called run_sql_readonly still needs hard enforcement behind it.

This becomes even more important when tools are exposed to agents, automation systems, or GenAI workflows.

4. Alternate code paths deserve attention

Bugs often hide in secondary handlers, compatibility modes, file-serving paths, helper functions, and less frequently used protocol flows.

These paths may reach powerful functionality without going through the same checks as the main interface.

5. Pre-authentication parsing is critical

Any parser reachable before authentication should be treated as high-risk attack surface.

Length checks, protocol assumptions, edge cases, and malformed inputs all matter.

Final thoughts

Publishing eight CVEs from reports submitted in May was a meaningful milestone for me.

But the most valuable part was not the number itself. It was the variety of systems, assumptions, and security boundaries involved.

From mTLS policy selection to SAML state validation, from file path handling to pre-auth packet parsing, from remote-control interfaces to MCP / GenAI database tooling — each finding was a reminder that security often breaks between layers.

That is where I plan to keep looking.

I published the technical write-ups here:

https://kamil-sawicki.github.io/

Thanks again to the maintainers who reviewed the reports and shipped fixes.