<?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-29T03:00:00.893996+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-61795</id>
    <title>fkie_cve-2026-61795</title>
    <updated>2026-09-29T03:00:01.200402+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Capsule is a multi-tenancy and policy-based framework for Kubernetes. From 0.13.0 until 0.13.7, hostnameRegexHandler.OnUpdate in internal/webhook/tenant/validation/hostname_regex.go reverses the new and old Tenant parameters and validates the previous AllowedHostnames.Regex instead of the submitted value. A cluster administrator can therefore store a malformed AllowedHostnames.Regex after the webhook accepts the update based on stale valid state. Subsequent Ingress creation or update reaches validate_hostnames.go, which evaluates the malformed pattern, ignores the regular-expression error, and treats every hostname as unmatched, blocking Ingress operations for the affected tenant until an administrator repairs the Tenant configuration. This issue is fixed in version 0.13.7.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-61795"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-f94q-w3w8-cj67</id>
    <title>GHSA-f94q-w3w8-cj67 — Capsule: hostnameRegexHandler.OnUpdate validates stale (old) Tenant regex, allowing invalid AllowedHostnames regex to b…</title>
    <updated>2026-09-29T03:00:01.200541+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/projectcapsule/capsule</p>
<p>### Summary</p>
<p>A parameter order bug in `internal/webhook/tenant/validation/hostname_regex.go` causes the `hostnameRegexHandler.OnUpdate` webhook to validate the **old** Tenant object's `AllowedHostnames.Regex` instead of the **new** one being submitted. This allows an invalid (malformed) regex to bypass admission validation and be persisted to etcd, causing a Denial of Service for all Ingress operations within the affected tenant.</p>
<p>### Details</p>
<p>The `TypedHandler[T]` interface defines `OnUpdate` as:</p>
<p>```go
// handlers.go
OnUpdate(c client.Client, reader client.Reader, obj T, old T, decoder admission.Decoder, recorder events.EventRecorder) Func
//                                               ^^^ NEW  ^^^ OLD
```</p>
<p>The dispatcher in `handler.go:93` calls:
```go
hndl.OnUpdate(c, reader, tnt, old, decoder, recorder)
//                        ^^^ NEW  ^^^ OLD
```</p>
<p>However, `hostnameRegexHandler.OnUpdate` in `hostname_regex.go` declares its parameters in **reversed order**:</p>
<p>```go
// hostname_regex.go (BUGGY)
func (h *hostnameRegexHandler) OnUpdate(
    _ client.Client,
    _ client.Reader,
    old *capsulev1beta2.Tenant,   // ← receives NEW tenant (mislabeled as old)
    tnt *capsulev1beta2.Tenant,   // ← receives OLD tenant (mislabeled as tnt)
    ...
) handlers.Func {
    return func(...) *admission.Response {
        if err := h.validate(tnt, req); err != nil { // ← validates OLD, not NEW
            return err
        }
        return nil
    }
}
```</p>
<p>All 11 other handlers in t…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-f94q-w3w8-cj67"/>
  </entry>
</feed>
