In August 2022, a security vulnerability was disclosed for Zalando Skipper, specifically version v.13.236, with the identifier CVE-2022-38580. This flaw opens up the risk of Server-Side Request Forgery (SSRF), which could let attackers manipulate Skipper into making requests to internal resources, leading to possible data leaks or network attacks. Here, we’ll break down what happened, why it’s dangerous, and how attackers can exploit it—laying it out in simple language, with real code so you can see the issue yourself.

What is Zalando Skipper?

Skipper is an HTTP reverse proxy and load balancer. It’s widely used in cloud setups, for routing traffic to the right services in a Kubernetes or microservices environment. Skipper supports powerful route definitions, rewrites, filters, and other proxy tasks.

The Vulnerability: How SSRF Occurred

Skipper’s route configuration can use variables that are influenced by data from incoming HTTP requests. In v.13.236, certain built-in filters let request data end up in backend URLs without proper validation.

For instance, a configuration like this would accept a backend query parameter from the incoming request and use it as the URL for the outgoing request:

r: Path("/api") && QueryParam("backend")
   -> setBackend(${backend})
   -> <other-filters>
   -> <your-upstream>

If an attacker can influence backend, they can redirect Skipper to any internal service, or even to the local file system (using file://), essentially abusing Skipper as a proxy into places it shouldn’t go.

Real-World Exploit Example

Let’s say Skipper is deployed on your company’s cloud infrastructure. Internally, you’ve got an HTTP service running at http://10...42:808/internal. This service should never be exposed to the internet. But if your Skipper is routing requests based on a URL from users, an attacker could send:

GET /api?backend=http://10...42:808/internal HTTP/1.1
Host: your-skipper.example.com

Skipper would read the backend query param, and—because unsupported validation in v.13.236—blindly forward the request to that internal resource. The attacker could now:

Read internal-only data.

- Interact with cloud infrastructure metadata endpoints (think AWS/GCP tokens).
- Access local files if Skipper’s filters/proxies allow file:// schemas.

Sample Exploit with curl

curl "https://your-skipper.example.com/api?backend=http://localhost:800/admin";

If unpatched and unfiltered, this would make Skipper send a request to localhost:800/admin on behalf of the attacker.

Why is SSRF Dangerous?

- Access to Internal Resources: Attackers can reach URLs only available inside your network or host.
- Cloud Credential Leak: On AWS, for example, hitting http://169.254.169.254/latest/meta-data/ could expose security credentials.
- Chaining with Other Bugs: SSRF can sometimes be extended to code execution or privilege escalation if internal services have further vulnerabilities.

How to Fix It

The Zalando Skipper team issued a patch and released version v.13.237. Upgrading closes the hole by adding proper validation to route filters, so that attackers can’t abuse request-controlled input as unrestricted URLs.

References

- CVE-2022-38580 in MITRE NVD
- Vulnerability Advisory from Skipper Team
- Pull request that fixes the bug

Final Thoughts

CVE-2022-38580 is a classic example of how trusting user input in backend routing can go wrong—especially in scalable platforms like Skipper. If you’re using Skipper < v.13.237, upgrade immediately. Never let users decide where your servers talk to, or you might be giving hackers a direct hotline to your deepest secrets.

Timeline

Published on: 10/25/2022 17:15:00 UTC
Last modified on: 03/28/2023 17:15:00 UTC