<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T05:05:16.333803+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/euvd-2026-273586</id>
    <title>EUVD-2026-273586</title>
    <updated>2026-10-03T05:05:16.434705+00:00</updated>
    <content>EUVD-2026-273586</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-273586"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-27586</id>
    <title>fkie_cve-2026-27586</title>
    <updated>2026-10-03T05:05:16.434760+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Caddy is an extensible server platform that uses TLS by default. Prior to version 2.11.1, two swallowed errors in `ClientAuthentication.provision()` cause mTLS client certificate authentication to silently fail open when a CA certificate file is missing, unreadable, or malformed. The server starts without error but accepts any client certificate signed by any system-trusted CA, completely bypassing the intended private CA trust boundary. Any deployment using `trusted_ca_cert_file` or `trusted_ca_certs_pem_files` for mTLS will silently degrade to accepting any system-trusted client certificate if the CA file becomes unavailable. This can happen due to a typo in the path, file rotation, corruption, or permission changes. The server gives no indication that mTLS is misconfigured. Version 2.11.1 fixes the vulnerability.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-27586"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-hffm-g8v7-wrv7</id>
    <title>GHSA-hffm-g8v7-wrv7 — Caddy: mTLS client authentication silently fails open when CA certificate file is missing or malformed</title>
    <updated>2026-10-03T05:05:16.434806+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/caddyserver/caddy/v2</p>
<p>### Summary</p>
<p>Two swallowed errors in `ClientAuthentication.provision()` cause mTLS client certificate authentication to silently fail open when a CA certificate file is missing, unreadable, or malformed. The server starts without error but accepts any client certificate signed by any system-trusted CA, completely bypassing the intended private CA trust boundary.</p>
<p>### Details</p>
<p>In `modules/caddytls/connpolicy.go`, the `provision()` method has two `return nil` statements that should be `return err`:</p>
<p>**Bug #1 — line 787:**
```go
ders, err := convertPEMFilesToDER(fpath)
if err != nil {
    return nil  // BUG: should be "return err"
}
```</p>
<p>**Bug #2 — line 800:**
```go
err := caPool.Provision(ctx)
if err != nil {
    return nil  // BUG: should be "return err"
}
```</p>
<p>Compare with line 811 which correctly returns the error:
```go
caRaw, err := ctx.LoadModule(clientauth, "CARaw")
if err != nil {
    return err  // CORRECT
}
```</p>
<p>When the error is swallowed on line 787, the chain is:</p>
<p>1. `TrustedCACerts` remains empty (no DER data appended from the file)
2. The `len(clientauth.TrustedCACerts) &gt; 0` guard on line 794 is false — skipped
3. `clientauth.CARaw` is nil — line 806 returns nil
4. `clientauth.ca` remains nil — no CA pool was created
5. `provision()` returns nil — caller thinks provisioning succeeded</p>
<p>Then in `ConfigureTLSConfig()`:</p>
<p>6. `Active()` returns true because `TrustedCACertPEMFiles` is non-empty
7. Default mode is set to `RequireAndVerifyClientCert` (line 860)
8. But `c…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-hffm-g8v7-wrv7"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27586</id>
    <title>UBUNTU-CVE-2026-27586</title>
    <updated>2026-10-03T05:05:16.434883+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:24.04:LTS: caddy, Ubuntu:25.10: caddy, Ubuntu:Pro:26.04:LTS: caddy</p>
<p>Caddy is an extensible server platform that uses TLS by default. Prior to version 2.11.1, two swallowed errors in `ClientAuthentication.provision()` cause mTLS client certificate authentication to silently fail open when a CA certificate file is missing, unreadable, or malformed. The server starts without error but accepts any client certificate signed by any system-trusted CA, completely bypassing the intended private CA trust boundary. Any deployment using `trusted_ca_cert_file` or `trusted_ca_certs_pem_files` for mTLS will silently degrade to accepting any system-trusted client certificate if the CA file becomes unavailable. This can happen due to a typo in the path, file rotation, corruption, or permission changes. The server gives no indication that mTLS is misconfigured. Version 2.11.1 fixes the vulnerability.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-27586"/>
  </entry>
</feed>
