Two things set XLS apart from all the other Excel formats covered in this file format vulnerability series.

The first and most significant is file structure. XLS predates the Open XML model (XML inside a ZIP container) most folks are now accustomed to, instead storing content in an old-school binary container.

The second is the macro model: unlike XLSX (vanilla Excel) and XLTX (Excel’s template format), a standard XLS file can natively hold executable code – and not just one kind of executable code. XLS supports both VBA macros and a separate, older macro system called XLM that operates directly in spreadsheet cells. The latter is one of the more actively exploited features in the format.

Neither of these characteristics is visible from the file’s surface, of course. An XLS file can carry VBA code, XLM formulas configured to run on open, and/or crafted binary structures targeting XLS parser vulnerabilities, all while looking no different from a benign workbook.

What’s inside an XLS file?

XLS specifically uses the Binary Interchange File Format (BIFF), which is stored inside a Compound File Binary container. For context, that’s the same OLE2 structure used by DOC files (the legacy Word document format). That means there’s no convenient, readable XML to inspect, and there’s no ZIP archive to enumerate from. In XLS files, content, formatting, formulas, charts, and macro projects are all encoded in binary records organized into streams within that compound container.

If that sounds complex, we’re on the right track – the structure is complex by design. Each record type carries specific fields at defined byte offsets, and the format evolved across multiple BIFF versions spanning decades of Excel releases. As a result, parsing an XLS workbook means navigating that binary record structure directly, which puts parsing the code (not an XML processor) at the center of the format’s attack surface

Note that the above identifiers describe the container type only. The streams an XLS file carries, including the macros they store, the records they contain, and the binary structures they define, are a separate question that these surface details can’t answer.

Two macro systems, neither requiring a separate extension

To this point in our format vulnerability series, this section on macros has been dedicated to dispelling possible misconceptions about macro threats – largely in regard to which Open XML files have the actual capacity to carry macros. For the Word document family, DOCM bears that responsibility, and for the Excel family, the burden falls to XLSM.

XLS has no equivalent structure. A normal looking .xls file can carry a full VBA macro project and store it in its own container stream, and that project can be configured to execute automatically on workbook events like Auto_Open. There’s nothing on the surface of a macro-enabled XLS file to distinguish it from a non-executable version.

That characteristic alone would make XLS worth treating carefully. What makes it a distinct subject, however, is the second macro system: XLM, also called Excel 4.0 macros.

XLM formulas live in spreadsheet cells rather than in a VBA editor. A sheet containing XLM code can be set to very-hidden - which means “invisible through Excel’s normal sheet interface” – and a cell range named Auto_Open is all that’s required to execute those formulas when the workbook loads. Because XLM runs through the formula engine rather than the VBA runtime, it operates outside some of the controls that are put in place to govern VBA execution. As a result, security tooling build to detect VBA macro streams may not inspect XLM cell content at all. The formulas themselves can invoke Windows shell commands, read and write files, and download content from remote servers.

XLM has appeared in active malware campaigns specifically because it offers a code execution path that bypasses tooling calibrated for VBA.

How XLS content can expose software vulnerabilities

Reading XLS binary records has historically been one of the more vulnerability-prone operations in the entire Office stack. The format’s age, on top of the wild complexity of its record structure, and the staggering breadth of its BIFF version history have all contributed to a substantial documented CVE record. That covers both Excel releases and third-party parsing libraries, too.

Malformed record lengths, invalid field values, and unexpected binary arrangements can trigger memory errors in the applications processing them. Embedded objects also compound this problem: each object is handled by a separate application, introducing that application’s own parsing vulnerabilities into the chain. As a result, the attack surface is much wider than the XLS workbook itself.

The depth of the binary parsing CVE record also reflects a long tail of unpatched deployments. Organizations running older Excel versions, or processing XLS files through third-party libraries with their own patch cycles, may find themselves exposed to vulnerabilities that no longer exist in current Excel releases. Legacy format support and legacy patch levels tend to travel together.

Legacy features that extend the attack surface

Dynamic Data Exchange (DDE) is present in XLS with the same mechanism it carries in DOC: a field that instructs the host application to contact an external program and pass it a command. In the context of a spreadsheet, DDE links can be embedded in cells on hidden sheets or outside the visible range, making them harder to encounter during a casual review of the document. DDE processing is entirely separate from the macro security model, so it doesn’t get blocked by macro settings in configurations where DDE-specific controls haven’t been applied.

Embedded OLE objects also carry the same risk in XLS as they do across all Office formats. The object and the document containing it are processed separately, each bringing its own application dependencies and vulnerability exposure into the chain.

Embedded content and features create different risks

XLS threats can operate through the parser, through VBA or XLM macros that run before a reader is aware of them, or through a decision further down the chain. Neither macro system requires an extension to signal its presence.

What XLS content validation can reveal

Validating an XLS document effectively means examining the Compound File Binary container. Validation needs to confirm that its streams are structurally intact, and that their contents conform to the BIFF specification. A thorough examination of an XLS file can flag VBA storage streams, surface XLM content in sheet data, and even identify embedded objects or DDE references that shouldn’t be present in some particular context.

The limit to XLS validation is consistent with other formats we’ve covered in this series: structural validity does not establish what the workbook does when evaluated. A well-formed XLS file can still carry a VBA project set to run on open, along with very-hidden XML formulas ready to run automatically. It can carry a DDE reference in a cell outside the visible range, or binary records crafted to trigger some specific as-of-yet-unknown parser flaw. What format conformance can tell us is that the container is readable, not that its contents are safe.

The XLM consideration is worth isolating in this conversation. Because XLM content lives in cell data rather than a dedicated macro storage stream, it sits closer to ordinary spreadsheet content than VBA does. Because of that, inspection focused on VBA streams may not surface XLM at all. Comprehensive XLS content verification needs to account for both macro systems the format supports.

The malware an XLS file can help deliver

The VBA and XLM capabilities we’ve discussed throughout this article give XLS a particular position in the malware delivery landscape. The former put it alongside DOC as a format that can run code on open without a macro-enabling signal; the latter extends that further into a code execution path that completely evades controls tuned for VBA detection.

In spite of its age and replacement by XLSX in 2007, XLM-based campaigns grew substantially in 2020 and 2021, driven largely by the gap between XLM’s capabilities and the detection coverage available at the time. Common techniques included hiding XLM sheets using the very-hidden status, encoding payload strings across multiple cells, and using XLM formula functions to download and execute second-stage malware without ever touching the VBA runtime. Organizations running security tooling that would’ve stopped equivalent VBA macros were finding it transparent to XLM.

The format’s continued presence in enterprise environments (as the legacy output format for older systems, long-running processes, and external data sources that haven’t been updated) keeps it relevant as a malware delivery vehicle. Workflows that must accept XLS files for compatibility can’t close that intake point, and a file type that has to be accepted is one that can be easily weaponized against the people accepting it.

Applying Cloudmersive 360-Degree Content Protection to XLS files

Cloudmersive’s Advanced Virus Scan API provides 360-Degree Content Protection, combining virus and malware detection with configurable content inspection in a single step. XLS (along with most Office formats) is supported for both malware scanning and internal content verification.

For XLS files, Advanced Virus Scan API controls can identify invalid container structures, detect VBA storage streams, flag XLM macro content in sheet data, surface DDE references, and identify embedded objects that conflict with a content policy. Coverage across both macro systems is directly relevant here; XLM is the less visible of the two and the one more likely to be missed by inspection that stops at VBA.

For services that continue to accept XLS files, content inspection alongside regular patching of XLS-capable readers addresses the format’s two independent risk dimensions: what its content will execute when evaluated, and what its binary structures might do to the parser before the evaluation begins.

To discuss the right controls for your XLS files, please feel free to contact a Cloudmersive security expert.