<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T07:58:23.937771+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-54247</id>
    <title>fkie_cve-2026-54247</title>
    <updated>2026-09-28T07:58:25.018146+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Skipper is an HTTP router and reverse proxy for service composition. Prior to 0.26.22, Handler in dataclients/kubernetes/admission/admission.go passes the body of requests to the Kubernetes admission endpoint at :9443/admission directly to io.ReadAll(r.Body) without a size limit. An attacker with in-cluster network access and a valid Kubernetes client certificate can send a very large body that causes unbounded memory allocation and an out-of-memory termination of the Skipper process. The disruption is limited to Ingress and RouteGroup admission rather than pod creation or unrelated admission controllers, and Kubernetes normally restarts the process. This issue is fixed in version 0.26.22.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-54247"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-cwxq-rc9x-2jvv</id>
    <title>GHSA-cwxq-rc9x-2jvv — Skipper: Unbounded Request Body Read in Admission Webhook Causes Memory Exhaustion DoS</title>
    <updated>2026-09-28T07:58:25.018275+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/zalando/skipper</p>
<p>## Summary</p>
<p>The Kubernetes admission webhook handler reads the entire request body using `io.ReadAll(r.Body)` without any size limit. Any client that can reach the webhook port within the cluster can send a multi-GB payload, causing the skipper process to exhaust memory and be OOM-killed. This disrupts all Kubernetes admission control, potentially blocking all pod creation and updates.</p>
<p>## Vulnerable Code</p>
<p>```go
// dataclients/kubernetes/admission/admission.go:76
body, err := io.ReadAll(r.Body)  // &lt;-- NO SIZE LIMIT
if err != nil {
    log.Errorf("Failed to read request: %v", err)
    w.WriteHeader(http.StatusInternalServerError)
    invalidRequests.WithLabelValues(admitterName).Inc()
    return
}</p>
<p>var review admissionReview
err = json.Unmarshal(body, &amp;review)
```</p>
<p>For comparison, the OPA filter has a body size limit:</p>
<p>```go
// filters/openpolicyagent/openpolicyagent.go:68-70
const DefaultMaxRequestBodySize = 1 &lt;&lt; 20 // 1MB</p>
<p>// OPA uses a bufferedBodyReader with size limits
```</p>
<p>## Attack Path</p>
<p>1. Attacker identifies the admission webhook endpoint (default: `:9443/admission` or configured path)
2. Attacker sends: `POST /admission HTTP/1.1, Content-Type: application/json` with a multi-GB request body
3. `io.ReadAll(r.Body)` allocates unbounded memory for the entire body
4. Skipper process is OOM-killed by the Kubernetes kubelet</p>
<p>## Permission Boundary Analysis</p>
<p>- **Attacker**: Any client with network access to the admission webhook port within the Kubernetes cluster
- **Bound…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-cwxq-rc9x-2jvv"/>
  </entry>
</feed>
