Researchers Flag Java-Related Code Execution Risk in LibreOffice and OpenOffice

Key points

• Security researchers found a demonstration issue in LibreOffice and Apache OpenOffice.
• A malicious spreadsheet can execute code without the normal macro prompt if Java support is active.
• No CVE has been assigned, and there are no known exploitation reports.
• Severity is rated medium; users should treat untrusted documents cautiously.

Security analysts have uncovered a proof-of-concept weakness that affects both LibreOffice and Apache OpenOffice. The problem centers on Java integration within these office suites. When a user opens a specially crafted spreadsheet, the application can be made to execute code. Notably, this route does not trigger the macro warning that users normally see for macro-enabled documents. No CVE identifier has been assigned, and there is no evidence of real-world attacks at this time.

For K-12 and government offices that rely on these free office suites, the exposure depends on configuration. If Java support is turned on, the attack surface is broader; if Java is disabled or absent, the described path may not work. The malicious file would need to be opened by a user, so email attachments, shared drives, and downloads remain the likely delivery routes. The impact could include code execution with the same privileges as the logged-in user.

The medium severity rating reflects the current limits: this is a demonstration, not an active campaign. Even so, the lack of a macro prompt matters because macro warnings are a familiar last line of defense. A spreadsheet that runs code silently can bypass user suspicion and endpoint controls that focus only on macro-based documents. Until vendors publish fixes, risk is highest for users who routinely open files from outside the organization.

IT teams should watch for advisories from LibreOffice and Apache OpenOffice, and for any future CVE assignment. In the meantime, review whether Java is truly needed for daily document workflows. Restricting Java, filtering attachments, and reinforcing user reporting can reduce exposure without waiting for a patch. Because no exploitation has been observed, this is a preparedness issue rather than an emergency, but it deserves attention in K-12 environments where document sharing is common.

What to do now

1. Inventory all LibreOffice and Apache OpenOffice installations, and flag endpoints where Java support is enabled.
2. Disable Java integration in both office suites unless a documented business need requires it.
3. Block or quarantine spreadsheet attachments from external senders at email and web gateways.
4. Warn staff not to open unexpected spreadsheets, even when no macro warning appears.
5. Monitor vendor security advisories and apply patches as soon as they are released.
6. Use EDR or application controls to alert on office processes spawning unusual child processes.
7. If Java must remain on, isolate high-risk document opening in a sandbox or restricted virtual environment.

Original source

The Hacker News