<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T11:36:37.512748+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/fkie_cve-2026-102601</id>
    <title>fkie_cve-2026-102601</title>
    <updated>2026-09-30T11:36:37.541452+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Flysystem is an open source file storage library for PHP. Prior to 3.35.3, the default WhitespacePathNormalizer in src/WhitespacePathNormalizer.php used by Filesystem across adapters calls preg_match with the u modifier and treats both false and 0 as falsy. A path containing malformed UTF-8 causes PCRE to return false, so paths that also contain control characters bypass CorruptedPathDetected::forPath() in normalizePath(). Filesystem::write() can store such names and Filesystem::listContents() can return the raw ANSI escape sequences, allowing hidden or spoofed terminal file listings when an administrator displays them. This issue is fixed in version 3.35.3.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-102601"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-cxf4-7mrp-vvpr</id>
    <title>GHSA-cxf4-7mrp-vvpr — Flysystem: WhitespacePathNormalizer's control-character (CorruptedPathDetected) check is bypassed by malformed UTF-8 in…</title>
    <updated>2026-09-30T11:36:37.541534+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Packagist: league/flysystem</p>
<p>## Related public issue (context, not a duplicate)</p>
<p>Closed issue #1429 ("Handle non-UTF-8 paths", 2024-03-24) raised exactly this general concern and
even suggested detection via `preg_match('//u', $path) !== 1` -- note the reporter's suggested check
explicitly compares `!== 1`, which *would* correctly treat PCRE's `false` return as "reject." The
maintainer's reply pointed to the `PathNormalizer` interface as the place to implement this. The
control-character check that ended up shipping in `WhitespacePathNormalizer`
(`if (preg_match('#\p{C}+#u', $unixPath))`) addresses the general concern but does **not** use the
`!== 1`-style comparison the original issue suggested -- it uses a bare truthy check, which is exactly
the gap this report demonstrates. So this is not a duplicate of #1429; it's a concrete bypass
surviving in the fix that issue's concern led to.</p>
<p>## Vulnerability Details</p>
<p>**File**: `src/WhitespacePathNormalizer.php`, lines 22-28 (`normalizePath()`) -- the **default**
`PathNormalizer` used by `Filesystem` for every adapter (Local, FTP, SFTP, S3, AsyncAwsS3, Azure, GCS,
ZipArchive, GridFS, InMemory) unless the application supplies a custom one.</p>
<p>### Root Cause</p>
<p>```php
public function normalizePath(string $path): string
{
    $unixPath = str_replace('\\', '/', $path);</p>
<p>if (preg_match('#\p{C}+#u', $unixPath)) {
        throw CorruptedPathDetected::forPath($path);
    }
    ...
```</p>
<p>`preg_match()` returns `false` (a PHP engine error) rather than `0` when the subjec…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-cxf4-7mrp-vvpr"/>
  </entry>
</feed>
