<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 10:00:14 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-342423</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-342423</link>
      <description>EUVD-2026-342423</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-342423</guid>
    </item>
    <item>
      <title>fkie_cve-2026-66064</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-66064</link>
      <description>&lt;p&gt;goshs is a feature-rich single-binary file server for red teamers and developers. Prior to 2.1.5, the httpserver/handler.go sendFile handler opened files using a cleaned path but derived the authorization filename from raw req.URL.Path, so a trailing slash could bypass .goshs ACL-file protection and block-list checks. This issue is fixed in version 2.1.5.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;goshs is a feature-rich single-binary file server for red teamers and developers. Prior to 2.1.5, the httpserver/handler.go sendFile handler opened files using a cleaned path but derived the authorization filename from raw req.URL.Path, so a trailing slash could bypass .goshs ACL-file protection and block-list checks. This issue is fixed in version 2.1.5.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-66064</guid>
    </item>
    <item>
      <title>GHSA-964w-f6gj-5236 — goshs has ACL Bypass &amp; Path Traversal</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-964w-f6gj-5236</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/patrickhener/goshs/v2, Go: goshs.de/goshs/v2, Go: github.com/patrickhener/goshs, Go: goshs.de/goshs&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`sendFile` derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.&lt;/p&gt;
&lt;p&gt;## Finding (Medium): trailing-slash ACL and hidden-file bypass&lt;/p&gt;
&lt;p&gt;httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.&lt;/p&gt;
&lt;p&gt;Measured, with negative controls:&lt;/p&gt;
&lt;p&gt;```
GET /blocked/secret.txt    -&amp;gt; 404          (control, correctly blocked)
GET /blocked/secret.txt/   -&amp;gt; 200 + contents
GET /blocked/.goshs/       -&amp;gt; 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash
```&lt;/p&gt;
&lt;p&gt;Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.&lt;/p&gt;
&lt;p&gt;## Suggested fixes…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/patrickhener/goshs/v2, Go: goshs.de/goshs/v2, Go: github.com/patrickhener/goshs, Go: goshs.de/goshs&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`sendFile` derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.&lt;/p&gt;
&lt;p&gt;## Finding (Medium): trailing-slash ACL and hidden-file bypass&lt;/p&gt;
&lt;p&gt;httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.&lt;/p&gt;
&lt;p&gt;Measured, with negative controls:&lt;/p&gt;
&lt;p&gt;```
GET /blocked/secret.txt    -&amp;gt; 404          (control, correctly blocked)
GET /blocked/secret.txt/   -&amp;gt; 200 + contents
GET /blocked/.goshs/       -&amp;gt; 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash
```&lt;/p&gt;
&lt;p&gt;Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.&lt;/p&gt;
&lt;p&gt;## Suggested fixes…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-964w-f6gj-5236</guid>
    </item>
  </channel>
</rss>
