An attacker can exploit this by crafting an XLSX file with multiple sheets where one of the sheet names contains a malicious JavaScript payload. When an application using this library renders the spreadsheet navigation for a victim user, the payload executes in the context of the victim's browser session. This can be used to exfiltrate sensitive data, such as session cookies, to an attacker-controlled server. The availability of a public Proof-of-Concept (PoC) increases the risk of exploitation for applications that process untrusted user-uploaded XLSX files.

Attack Chain

1. Attacker creates a legitimate XLSX file with at least two sheets.
2. Attacker modifies the internal XML structure of the XLSX file (e.g., xl/workbook.xml) to inject a JavaScript payload into a sheet name field.
3. Attacker re-packages the modified file as a valid XLSX archive.
4. Attacker uploads the malicious XLSX file to a target application that uses the vulnerable PhpSpreadsheet library.
5. The target application processes the XLSX file using the generateNavigation() method.
6. The application renders the malicious sheet name directly into an <a> tag within the navigation HTML.
7. A victim user views the rendered spreadsheet navigation, triggering the stored XSS payload in their browser.
8. The payload exfiltrates the victim's session cookies to an attacker-controlled destination.

Impact

Successful exploitation allows for arbitrary JavaScript execution in the context of the victim's browser. This enables attackers to perform unauthorized actions on behalf of the user, exfiltrate sensitive data including session cookies, or potentially hijack active user sessions. The scope of impact is limited to users who view the generated navigation HTML for an uploaded malicious spreadsheet.

Recommendation

1. Upgrade the PHPOffice PhpSpreadsheet library to versions 1.29.8, 2.3.6, 3.8.0, or later to incorporate the vendor's patch.
2. Implement strict input validation on all user-uploaded XLSX files, ensuring that sheet names comply with expected naming conventions before they are processed by the library.
3. If immediate patching is not possible, implement Content Security Policy (CSP) headers that restrict inline script execution to mitigate the impact of potential XSS attacks.
4. Review application logs for anomalous POST requests to document upload endpoints, focusing on files that contain suspicious characters (e.g., <script>, onerror, onload) within their internal XML metadata.