Vulnerability-Lookup

GHSA-87M4-826X-3CRX

Vulnerability from github – Published: 2026-06-08 23:00 – Updated: 2026-06-08 23:00

Summary

PHPSpreadsheet has a patch bypass for CVE-2026-34084

Details

Summary

CVE-2026-34084 was patched by the helper File::prohibitWrappers. The helper calls parse_url($filename, PHP_URL_SCHEME) and then checks is_string($scheme) && strlen($scheme) > 1 to reject stream wrappers such as phar://, php://, data:// or expect://. The check is not equivalent to "does the path contain a wrapper". When the input has the form phar:///path/file.phar/inner with three or more slashes after the scheme, parse_url returns boolean false instead of returning the scheme string. The is_string($scheme) branch is therefore skipped, the helper returns without throwing, and the caller proceeds. PHP's stream layer, however, still treats phar:///... as a valid phar wrapper and opens the underlying phar file. The result is that IOFactory::load($attackerPath) walks past the patch and still touches the phar wrapper. On PHP 7.x, simply reaching the phar wrapper via is_file is enough for PHP to automatically deserialize the phar metadata, which in turn invokes the magic methods __wakeup and __destruct of an attacker controlled object and gives full RCE. On PHP 8.x, automatic metadata deserialization for plain file ops was removed, so the chain at the PhpSpreadsheet layer reduces to a phar wrapper file read primitive, and RCE only resurfaces if the downstream consumer ever calls Phar::getMetadata.

Vulnerable code

The file vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Shared/File.php is byte identical across all six latest tags listed below:

public static function prohibitWrappers(string $filename): void
{
    $scheme = parse_url($filename, PHP_URL_SCHEME);
    if (is_string($scheme) && strlen($scheme) > 1) {
        throw new Exception("Stream wrappers are not permitted as file paths: {$filename}");
    }
}

For input phar://x/dummy.csv the call returns the string "phar" and the throw fires correctly. For input phar:///work/exploit.phar/dummy.csv the same call returns false and the throw is skipped, which is the bypass.

Confirmed affected versions

Tested on 2026-05-03. The prohibitWrappers source on disk is identical across all six tags.

Branch	Latest tag	PHP under test	Result
1.x	1.30.4	7.4	bypass plus full RCE, gadget wrote marker file
2.1.x	2.1.16	8.3	bypass
2.4.x	2.4.5	8.3	bypass
3.10.x	3.10.5	8.3	bypass
5.6.x	5.6.0	8.3	bypass
5.7.x	5.7.0	8.3	bypass

Version 1.30.4 is the latest tag of the 1.x branch, which is the only branch that still supports PHP 7.x. Version 5.7.0 is the latest tag overall on Packagist at the time of testing.

No branch beyond 1.30.x allows any release before Php 8. For branches beyond 1.30.x, although the code identified above is in error, and will be corrected, it does not lead to any security exposure. That would require a Phar::getMetadata call, which is not present in PhpSpreadsheet. If possible and reasonable, the release notes for the fix on the other branches will include release-note: security.

Reproduction

Requires Docker only, no local PHP install. Run:

bash run.sh

The script does the following in order: build exploit.phar using php:7.4-cli with phar.readonly=0, install phpoffice/phpspreadsheet:5.7.0 through composer and run exploit.php on php:8.3-cli to show that the bypass still works against the latest tag, then install 1.30.4 and run again on php:7.4-cli to show the full RCE chain. All output is teed to evidence.txt.

exploit.php ships two controls. The negative control uses phar://x/dummy.csv to confirm that the patch still rejects the standard wrapper form. The positive control uses phar:///work/exploit.phar/dummy.csv to show that the three slash variant slips through. On PHP 7.4 the gadget writes the file pwned_marker containing the lines WAKEUP: phpspreadsheet-bypass and DESTRUCT: phpspreadsheet-bypass, which is the proof that attacker controlled code ran inside the victim process.

Suggested fix

Do not rely on parse_url to detect wrappers, because its behavior depends on the slash count and on the PHP version. Either of these is safe:

public static function prohibitWrappers(string $filename): void
{
    if (str_contains($filename, '://')) {
        throw new Exception("Stream wrappers are not permitted as file paths: {$filename}");
    }
}

Alternatively, run the path through realpath() first, since realpath returns false for any wrapper prefixed path.

Files in this report

build-phar.php: builds exploit.phar with a gadget object in its metadata.
exploit.php: main PoC, with the negative and positive controls.
exploit.phar: prebuilt phar, the gadget writes a marker when deserialized.
composer.json: spec used by composer to install the version under test.
run.sh: end to end reproducer through Docker.
evidence.txt: log captured from the most recent run.sh invocation.

Severity

9.2 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45034"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T23:00:14Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nCVE-2026-34084 was patched by the helper `File::prohibitWrappers`. The helper calls `parse_url($filename, PHP_URL_SCHEME)` and then checks `is_string($scheme) \u0026\u0026 strlen($scheme) \u003e 1` to reject stream wrappers such as `phar://`, `php://`, `data://` or `expect://`. The check is not equivalent to \"does the path contain a wrapper\". When the input has the form `phar:///path/file.phar/inner` with three or more slashes after the scheme, `parse_url` returns boolean `false` instead of returning the scheme string. The `is_string($scheme)` branch is therefore skipped, the helper returns without throwing, and the caller proceeds. PHP\u0027s stream layer, however, still treats `phar:///...` as a valid phar wrapper and opens the underlying phar file. The result is that `IOFactory::load($attackerPath)` walks past the patch and still touches the phar wrapper. On PHP 7.x, simply reaching the phar wrapper via `is_file` is enough for PHP to automatically deserialize the phar metadata, which in turn invokes the magic methods `__wakeup` and `__destruct` of an attacker controlled object and gives full RCE. On PHP 8.x, automatic metadata deserialization for plain file ops was removed, so the chain at the PhpSpreadsheet layer reduces to a phar wrapper file read primitive, and RCE only resurfaces if the downstream consumer ever calls `Phar::getMetadata`.\n\n## Vulnerable code\n\nThe file `vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Shared/File.php` is byte identical across all six latest tags listed below:\n\n```php\npublic static function prohibitWrappers(string $filename): void\n{\n    $scheme = parse_url($filename, PHP_URL_SCHEME);\n    if (is_string($scheme) \u0026\u0026 strlen($scheme) \u003e 1) {\n        throw new Exception(\"Stream wrappers are not permitted as file paths: {$filename}\");\n    }\n}\n```\n\nFor input `phar://x/dummy.csv` the call returns the string `\"phar\"` and the throw fires correctly. For input `phar:///work/exploit.phar/dummy.csv` the same call returns `false` and the throw is skipped, which is the bypass.\n\n## Confirmed affected versions\n\nTested on 2026-05-03. The `prohibitWrappers` source on disk is identical across all six tags.\n\n| Branch | Latest tag | PHP under test | Result |\n|---|---|---|---|\n| 1.x | 1.30.4 | 7.4 | bypass plus full RCE, gadget wrote marker file |\n| 2.1.x | 2.1.16 | 8.3 | bypass |\n| 2.4.x | 2.4.5 | 8.3 | bypass |\n| 3.10.x | 3.10.5 | 8.3 | bypass |\n| 5.6.x | 5.6.0 | 8.3 | bypass |\n| 5.7.x | 5.7.0 | 8.3 | bypass |\n\nVersion 1.30.4 is the latest tag of the 1.x branch, which is the only branch that still supports PHP 7.x. Version 5.7.0 is the latest tag overall on Packagist at the time of testing.\n\nNo branch beyond 1.30.x allows any release before Php 8. For branches beyond 1.30.x, although the code identified above is in error, and will be corrected, it does not lead to any security exposure. That would require a `Phar::getMetadata` call, which is not present in PhpSpreadsheet. If possible and reasonable, the release notes for the fix on the other branches will include `release-note: security`.\n\n## Reproduction\n\nRequires Docker only, no local PHP install. Run:\n\n```sh\nbash run.sh\n```\n\nThe script does the following in order: build `exploit.phar` using `php:7.4-cli` with `phar.readonly=0`, install `phpoffice/phpspreadsheet:5.7.0` through composer and run `exploit.php` on `php:8.3-cli` to show that the bypass still works against the latest tag, then install `1.30.4` and run again on `php:7.4-cli` to show the full RCE chain. All output is teed to `evidence.txt`.\n\n`exploit.php` ships two controls. The negative control uses `phar://x/dummy.csv` to confirm that the patch still rejects the standard wrapper form. The positive control uses `phar:///work/exploit.phar/dummy.csv` to show that the three slash variant slips through. On PHP 7.4 the gadget writes the file `pwned_marker` containing the lines `WAKEUP: phpspreadsheet-bypass` and `DESTRUCT: phpspreadsheet-bypass`, which is the proof that attacker controlled code ran inside the victim process.\n\n## Suggested fix\n\nDo not rely on `parse_url` to detect wrappers, because its behavior depends on the slash count and on the PHP version. Either of these is safe:\n\n```php\npublic static function prohibitWrappers(string $filename): void\n{\n    if (str_contains($filename, \u0027://\u0027)) {\n        throw new Exception(\"Stream wrappers are not permitted as file paths: {$filename}\");\n    }\n}\n```\n\nAlternatively, run the path through `realpath()` first, since `realpath` returns `false` for any wrapper prefixed path.\n\n## Files in this report\n- [build-phar.php](https://github.com/user-attachments/files/27317345/build-phar.php): builds `exploit.phar` with a gadget object in its metadata.\n- [exploit.php](https://github.com/user-attachments/files/27317343/exploit.php): main PoC, with the negative and positive controls.\n- [exploit.phar](https://github.com/user-attachments/files/27317356/exploit.phar.txt): prebuilt phar, the gadget writes a marker when deserialized.\n- [composer.json](https://github.com/user-attachments/files/27317341/composer.json): spec used by composer to install the version under test.\n- [run.sh](https://github.com/user-attachments/files/27317342/run.sh): end to end reproducer through Docker.\n- [evidence.txt](https://github.com/user-attachments/files/27317339/evidence.txt): log captured from the most recent `run.sh` invocation.",
  "id": "GHSA-87m4-826x-3crx",
  "modified": "2026-06-08T23:00:14Z",
  "published": "2026-06-08T23:00:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-87m4-826x-3crx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-q4q6-r8wh-5cgh"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PHPSpreadsheet has a patch bypass for CVE-2026-34084 "
}

CVE-2026-45034 (GCVE-0-2026-45034)

Vulnerability from cvelistv5 – Published: 2026-06-22 20:32 – Updated: 2026-06-22 20:32

Title

PhpSpreadsheet: File::prohibitWrappers bypass

Summary

PhpSpreadsheet is a pure PHP library for reading and writing spreadsheet files. Prior to 1.30.5, CVE-2026-34084 was patched by the helper File::prohibitWrappers. The helper calls parse_url($filename, PHP_URL_SCHEME) and then checks is_string($scheme) && strlen($scheme) > 1 to reject stream wrappers such as phar://, php://, data:// or expect://. The check is not equivalent to "does the path contain a wrapper". When the input has the form phar:///path/file.phar/inner with three or more slashes after the scheme, parse_url returns boolean false instead of returning the scheme string. The is_string($scheme) branch is therefore skipped, the helper returns without throwing, and the caller proceeds. PHP's stream layer, however, still treats phar:///... as a valid phar wrapper and opens the underlying phar file. The result is that IOFactory::load($attackerPath) walks past the patch and still touches the phar wrapper. On PHP 7.x, simply reaching the phar wrapper via is_file is enough for PHP to automatically deserialize the phar metadata, which in turn invokes the magic methods __wakeup and __destruct of an attacker controlled object and gives full RCE. On PHP 8.x, automatic metadata deserialization for plain file ops was removed, so the chain at the PhpSpreadsheet layer reduces to a phar wrapper file read primitive, and RCE only resurfaces if the downstream consumer ever calls Phar::getMetadata. This vulnerability is fixed in 1.30.5.

Severity

9.2 (Critical)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

CWE

CWE-502 - Deserialization of Untrusted Data

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/PHPOffice/PhpSpreadsheet/secur…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
PHPOffice	PhpSpreadsheet	Affected: < 1.30.5

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "PhpSpreadsheet",
          "vendor": "PHPOffice",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.30.5"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "PhpSpreadsheet is a pure PHP library for reading and writing spreadsheet files. Prior to 1.30.5, CVE-2026-34084 was patched by the helper File::prohibitWrappers. The helper calls parse_url($filename, PHP_URL_SCHEME) and then checks is_string($scheme) \u0026\u0026 strlen($scheme) \u003e 1 to reject stream wrappers such as phar://, php://, data:// or expect://. The check is not equivalent to \"does the path contain a wrapper\". When the input has the form phar:///path/file.phar/inner with three or more slashes after the scheme, parse_url returns boolean false instead of returning the scheme string. The is_string($scheme) branch is therefore skipped, the helper returns without throwing, and the caller proceeds. PHP\u0027s stream layer, however, still treats phar:///... as a valid phar wrapper and opens the underlying phar file. The result is that IOFactory::load($attackerPath) walks past the patch and still touches the phar wrapper. On PHP 7.x, simply reaching the phar wrapper via is_file is enough for PHP to automatically deserialize the phar metadata, which in turn invokes the magic methods __wakeup and __destruct of an attacker controlled object and gives full RCE. On PHP 8.x, automatic metadata deserialization for plain file ops was removed, so the chain at the PhpSpreadsheet layer reduces to a phar wrapper file read primitive, and RCE only resurfaces if the downstream consumer ever calls Phar::getMetadata. This vulnerability is fixed in 1.30.5."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 9.2,
            "baseSeverity": "CRITICAL",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-502",
              "description": "CWE-502: Deserialization of Untrusted Data",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-22T20:32:32.011Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-87m4-826x-3crx",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-87m4-826x-3crx"
        }
      ],
      "source": {
        "advisory": "GHSA-87m4-826x-3crx",
        "discovery": "UNKNOWN"
      },
      "title": "PhpSpreadsheet: File::prohibitWrappers bypass"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-45034",
    "datePublished": "2026-06-22T20:32:32.011Z",
    "dateReserved": "2026-05-08T16:58:28.897Z",
    "dateUpdated": "2026-06-22T20:32:32.011Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-87M4-826X-3CRX

Summary

Vulnerable code

Confirmed affected versions

Reproduction

Suggested fix

Files in this report

CVE-2026-45034 (GCVE-0-2026-45034)

Tags

Sightings

Nomenclature