CISA’s required action for CVE-2023-7101 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Spreadsheet::ParseExcel Spreadsheet::ParseExcel in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.
What to do first when CVE-2023-7101 is on your list
The practical first step is exposure confirmation, not debate about exploitability. Use asset inventory, package manifests, and application dependency checks to find every place Spreadsheet::ParseExcel is installed or bundled, then treat any internet-facing or broadly reachable instance as urgent. When a vulnerability is on CISA’s KEV catalogue, response should be driven by confirmed exposure and the vendor’s remediation path, not by assumptions about current exploit activity.
Map the vulnerable package to the owning application or runtime, because the fix may be applied at the application layer, the dependency layer, or through replacement of the affected component. If the product is embedded in a larger system, validate whether the vendor update changes only the library version or requires a full application release. That distinction matters because incomplete remediation often leaves the exploitable code path in place.
Use the vendor advisory as the source of truth for the exact update or mitigation steps, and use the CISA Known Exploited Vulnerabilities Catalog to confirm the response urgency and any deadline-driven remediation expectations. For catalog context and record lookups, the CVE Program is the authoritative identifier source.
How to mitigate when patching is available
If the vendor provides a security update, apply it on the shortest feasible change window and verify the vulnerable version is no longer present in production, test, and build environments. For Perl dependencies, that means checking application dependencies, packaged deployments, containers, and any golden images or automation templates that could reintroduce the package later. A one-time patch is not enough if your delivery pipeline can redeploy the old component.
Where the vulnerable functionality is exposed to untrusted input, reduce attack surface while you patch. Remove unnecessary network reachability, disable the affected feature path if the vendor documents a safe workaround, and place compensating controls around the system if it must remain in service. If the update requires code changes or regression testing, prioritize anything that can execute the parser on externally supplied files, because that is the condition most likely to turn a library flaw into remote code execution.
For current prioritisation, pair the KEV listing with FIRST EPSS to understand whether the broader exploit climate supports accelerated treatment. Use that score as a triage input only, not as a substitute for the vendor fix or the KEV requirement.
What to do if mitigation must wait
If you cannot patch immediately, the safest option is to stop using the vulnerable product or remove the exposure that makes exploitation possible. CISA’s required action allows discontinuing use when mitigations are unavailable, and that is often the right call when the component is internet-facing, difficult to isolate, or embedded in a system you cannot quickly rework. Temporary risk acceptance should be explicit, time-bound, and tied to a real operational barrier, not to an open-ended plan to patch later.
While waiting, apply the strongest feasible containment: isolate the service, restrict file uploads or document ingestion to trusted sources only, and keep the vulnerable parser away from direct external traffic. If the component is part of an internal workflow, treat any path that accepts attacker-controlled spreadsheets as high risk until the fix is in place. Restricting exposure is especially important for parsing libraries because the payload is often a normal-looking file, which can bypass casual review.
For a broader playbook on exploited flaws, emergency mitigation, and post-patch verification, Zero-Day and Exploited Vulnerabilities Guide is the most relevant internal reference. For programme-level handling of scanning, prioritisation, and exception management, the Vulnerability Management Guide is the companion control path.
Risk and Threat Considerations
Spreadsheet parsers are attractive because they sit at a trust boundary: a routine file import can become code execution if the parser mishandles crafted content. That means the real exposure is not just the package itself, but every workflow that processes untrusted spreadsheets, especially where the service has filesystem, network, or application secrets access.
Failure mechanism: An attacker supplies a malicious spreadsheet or reaches a vulnerable parser through a file-processing workflow, causing the library to execute unintended code in the host process.
Impact: Remote code execution can lead to application takeover, credential theft, data access, lateral movement, and persistence if the affected system has broad privileges or connectivity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Directly applies to finding and remediating the exploited vulnerability across the estate. |
| CIS-12 — Network Infrastructure Management | Relevant because exposure reduction and isolation are key mitigations when patching must wait. | |
| Recommendation — Prioritise and remediate the vulnerable package through continuous vulnerability management. Restrict exposure paths and isolate systems that cannot be patched immediately. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Covers patching, mitigation, and verification for a known software flaw. |
| RA-5 — Vulnerability Monitoring and Scanning | Supports identifying every deployed instance and tracking remediation status. | |
| CM-8 — System Component Inventory | Needed to locate all instances of the affected library across systems and images. | |
| Recommendation — Apply the vendor fix or documented mitigation and verify the flaw is removed. Scan and inventory deployments to confirm where the vulnerable component exists. Maintain an accurate component inventory so every instance can be remediated. | ||
Practitioner Guidance
What to verify: Confirm the vulnerable package is fully removed or updated in every runtime that can invoke it, including containers, CI artifacts, and long-lived server images. If the same code is copied into multiple services, verify each deployment path separately rather than assuming one patch reached all instances.
Decision rule: If the system processes untrusted files and cannot be updated immediately, treat internet exposure or unrestricted user upload as the first thing to remove. If the component is deeply embedded and cannot be safely remediated in place, plan replacement rather than prolonging exception-based operation.
Practitioner takeaway: For exploitable parser flaws, the right order is inventory, patch or remove exposure, then prove the old code path is gone everywhere it could still execute.
Related resources from NHI Mgmt Group
- CVE-2023-7101 (Spreadsheet::ParseExcel Remote Code Execution)
- How do you patch or mitigate CVE-2021-1647 (Microsoft Defender Remote Code Execution)?
- How do you patch or mitigate CVE-2019-1579 (Palo Alto Networks PAN-OS Remote Code Execution)?
- How do you patch or mitigate CVE-2020-1350 (Microsoft Windows DNS Server Remote Code Execution)?