Malware

Old Macros, New Attack Paths: Why Documents Need Content Security

By FileDNA6 min read
Old Macros, New Attack

A spreadsheet can hold more than numbers and formulas. It can hold code. It can connect to a database. It can tell an application to fetch more content from somewhere else. Attackers can turn these ordinary capabilities into an attack path.

Recent LibreOffice and Apache OpenOffice research shows why this matters. A crafted spreadsheet can trigger Java code execution without ever showing a macro warning. Older Excel 4.0 macro attacks show another side of the same problem. A technology can be decades old and still dangerous, as long as current applications still support it.

The age of a feature does not decide its safety. What matters is what the content can make an application do.

A Spreadsheet That Loads Code Without a Macro

The reported by V12 a proof-of-concept attack starts when a user opens a crafted Calc spreadsheet from LibreOffice or Apache OpenOffice with Java support enabled. The spreadsheet contains a database range set to refresh automatically. That refresh pulls an external ODB database document from a remote address. The ODB document names a Java database driver and points to its code location. Calc then loads that driver and runs it. No macro warning ever appears.

The proof of concept simply opens the Calculator app to show that code execution works. The report does not describe any known use in real attacks. It should be treated as a demonstrated vulnerability, not an active malware campaign.

LibreOffice tracks this issue as CVE-2026-63277. The fix landed in versions 26.2.5 and 26.8.0, released on October 5, 2026. The fix works by requiring every Java class path entry to be a local file URL, so a document can no longer point to a remote location for its driver code. Apache OpenOffice tracks the same class of issue as CVE-2026-59265. As of this writing, every version through 4.1.16 remains affected, and a fix is expected in version 4.1.17, which is currently in release candidate testing. Until that update ships, Apache recommends disabling Java support entirely, under Tools, then Options, then OpenOffice, then Java, by unchecking “Use a Java runtime environment.”

The Dangerous Code Can Be Outside the File

This case exposes a gap in how people think about document threats. The spreadsheet itself does not need to contain the final malicious code. It only needs to contain instructions that make the application retrieve and run that code from somewhere else. HTML link in the sheet cell could trigger active content run without any warnings.

Removing macros alone does not close that gap. Removing embedded objects alone does not close it either. Security controls also need to examine data connections, automatic refresh definitions, and references to external resources.

A document’s visible content can look completely ordinary. Its internal configuration can still point the application toward an unsafe action.

Excel 4.0 Macros Show Why Old Features Still Matter

Excel 4.0 macros, also called XLM macros, date back to 1992, a full year before VBA existed. They store their instructions directly in cells on macro sheets. VBA code, by contrast, lives in its own dedicated code stream, which makes it easier to locate and extract. XLM formulas scattered across many cells are harder to spot, and XLM even supports commands like RUN, CALL, and GOTO that let execution jump around the sheet, which attackers use to scatter and hide malicious logic.

Microsoft documented attackers abusing XLM to run commands and call Windows APIs directly. Its 2021 research identified TrickBot, ZLoader, and Ursnif as examples of malware that moved to XLM once Microsoft’s 2018 antimalware scanning made older VBA-based obfuscation far less effective. In the ZLoader campaign, email attachments encouraged victims to enable content, and obfuscated macro formulas then decoded payload URLs and commands before launching a download through rundll32.exe.

These attacks did not depend on a newly invented macro language. They simply reused an old capability that remained available.

Microsoft’s current support documentation still lists XLM support in Excel for Microsoft 365, Excel 2024, and Excel 2021, while actively encouraging users to migrate to VBA instead. Microsoft has also restricted XLM execution by default through Trust Center macro settings, so these macros no longer run automatically unless a user explicitly re-enables them. Continued support should not be confused with unrestricted execution. Settings and policy still matter.

The lesson stays clear. Backward compatibility can preserve useful business functions. It can also preserve capabilities that attackers know how to abuse.

Old and New Content Need the Same Scrutiny

The Calc proof of concept and XLM malware use different mechanisms. One abuses document data connections and Java driver loading. The other uses a legacy macro language built into the spreadsheet grid itself. Both turn document content into actions performed by an application.

Defenders cannot assume an old feature is harmless. They also cannot assume a file without macros is safe. Inspection needs to cover every structure that enables execution, retrieval, or access to outside resources. That does not make every macro or external connection malicious on its own. It makes their presence a security decision that someone needs to make deliberately.

FileDNA CADR Role

FileDNA’s Content Analysis, Disarm, and Reconstruction approach puts this decision at the file boundary. Its focus is the content an application is about to receive, before that application ever acts on it.

For supported formats and content types, FileDNA analyzed internal structures, neutralized unsafe content, and reconstructed a usable file. This approach addresses a lasting problem. Attackers can reuse old capabilities, or find new ways to combine existing features, and a file inspection layer is accounted for both.

In the XLM example, FileDNA is recognizing macro sheets and neutralizing their executable instructions. In the Calc example, CADR is inspecting and disarming external data connections and  loading references that let the spreadsheet reach outside itself in the first place.

FileDNA’s broader position stays simple. Content security must account for both legacy active content and newly exposed attack paths. Protection should follow what a file can cause, regardless of when the underlying technology was introduced.

CSL Extends the Principle to Automated Workflows

The Content Security Layer applies the same principle before content ever reaches a consuming tool. People open documents directly. Automated services also process them. AI agents may pass files to office applications or conversion tools on their own. If those tools run an affected application with an affected configuration, document handling can expose the whole workflow to this kind of exploit, with no human ever clicking anything.

This is simply an extension of the risk described here, not a separate one. The reported proof of concept is not an AI prompt injection attack. It is a document exploit that happens to also threaten any pipeline, human or automated, that opens the file with a vulnerable application.

For FileDNA CSL, the objective is to enforce content policy before downstream tools ever open the file. CADR supplies the file analysis and reconstruction inside that protection model.

Keep Applications Updated and Control the Content

Patching and application settings remain essential on their own. Organizations should follow vendor guidance for their office suites and apply the LibreOffice fix or the Apache OpenOffice Java mitigation without delay. They should also restrict legacy macros wherever business needs allow it.

Content security adds another place to interrupt the attack. It examines the file before the application ever follows its instructions.

Old malicious content does not become safe with age. New malicious content does not need a new file format to work. FileDNA‘s CADR and CSL positioning brings both concerns to the same point: control what the file can make the next application do.

References:

Topics