Beyond the Editing Canvas: Evidence Divergence in OOXML-to-LLM Ingestion

• An evidence fork is a specification-grounded construction in which Office and an ingestion path promote different task evidence from the same unchanged OOXML package.Each consumer treats its own view as authoritative; this operational plurality does not imply normative equivalence under OOXML.Source: §1 · pp. 1–2
• Across 8,400 API trials, models returned traps in 48–76% of runs depending on the API, and at least one tested interface did so for 20 of 21 mechanisms.Each document carried a task-relevant fact exposed by extraction but not shown in Office.Source: §1 · p. 2
• Across 13 extraction tools, seven mechanisms reached 11–33% of applicable tools and fourteen reached 67–100%, with none in between.Ordinary content was broadly exposed, while attributes, relationships, and alternate branches were tool-specific.Source: §1 · p. 2
• A specification-guided method yielded 21 confirmed evidence forks across Word, Excel, and PowerPoint, organized into a six-dimensional taxonomy of OOXML view construction.The dimensions are representation, state, compatibility, visibility, scope, and linearization.Source: §1 · p. 2
• Trap exposure varied with the ingestion path, including across interfaces identified by a provider as using the same model, so model choice alone did not determine exposure.Exposure patterns could also match services to candidate ingestion configurations that behaved identically on the probes.Source: §1 · p. 2
• A survey of sixteen popular open-source LLM projects found that their default OOXML ingestion paths concentrate on affected extractor families.The paper also assesses detectability across ordinary documents and the limits of presence-only screening for common OOXML channels.Source: §1 · p. 2

2.1 OOXML Documents

• OOXML files are ZIP-based OPC containers whose related XML and media parts hold document content and supporting state that applications resolve but extractors only partially parse.For example, the main Word story is in word/document.xml, while styles, numbering, fonts, and recalculation settings reside in sibling parts.Source: §2.1 · p. 2
• Excel shows the formula’s benign value 57,299, while a formula-less extractor can expose the attacker-planted cache value 92,874 as model evidence.The file opens cleanly without repair; the ingestion contract does not specify which representation becomes evidence or record that the value came from a cache.Source: §2.1 · p. 3, Figure 1 · p. 3

2.2 OOXML Consumers

• Microsoft Office’s default editing canvas is the human-facing oracle, while separate, partial-parser extraction tools produce LLM evidence and mainstream projects’ default paths concentrate on a small set of leaf extractors.These tools include format-specific parsers, converters, and meta-extractors; their loader choices can indicate potential exposure.Source: §2.2 · p. 3

2.3 Related Work

• Prior Office-security and DOCX-to-LLM studies examine masking, parser or rendering gaps, and selected carriers, whereas this work derives 21 view constructions across Word, Excel, and PowerPoint.The cited DOCX studies include Castagnaro et al. [17], Sîli et al., and Tomazini et al.; malformed containers and macros are outside this study’s threat model.Source: §2.3 · p. 3

2.4 Threat Model

• The threat model assumes an attacker-controlled, specification-valid file that opens without repair and shows benign content in Office, while the LLM returns task-relevant content absent from that review view.The attacker does not control the extractor, model, or prompt; malformed containers, macros, executable payloads, and forensic inspection through auxiliary views are excluded.Source: §2.4 · p. 4

3.1 Knowledge Base and Mining

• The authors built JSON indexes containing 15,884 schema records and 5,206 prose sections, then mined 23 chunks to produce 639 specification-anchored candidates.An LLM traversed element-anchored chunks of at most 500K characters; a deterministic parser consolidated records by specification anchor.Source: §3.1 · p. 4

3.2 Instantiation and Confirmation

• Of 639 candidates, 542 yielded runnable fixtures; the Office gate retained 412 and the 13-tool extraction gate retained 163 before 104 duplicates and 38 out-of-scope cases were removed, leaving 21.Gate 1 required BENIGN visible and TRAP absent; Gate 2 required at least one extractor to emit TRAP.Source: §3.2 · p. 5
• The workflow confirms 21 evidence forks across six view-construction dimensions: 12 in Excel, eight in Word, and one in PowerPoint.The classes are representation (5), state (6), visibility (3), compatibility (2), scope (3), and linearization (2). Representation forks can expose different task evidence without hiding or moving text.Source: §3.2 · pp. 5–6

3.3 A Realistic Test Set

• For realistic evaluation, the authors embedded one fork in each of 210 TAT-QA-derived Office files, ten per mechanism, and manually checked and validated every file.The task families substitute a queried fact or plant a fabricated disclosure for summarization.Source: §3.3 · p. 6

4.1 Experimental Setup

• The measurement tests 21 forks using 13 extraction tools, four native-ingestion APIs, and seven web chatbots across 210 document instances.API trials total 8,400 and web trials 1,470; matched-clean twins produce no traps in 0/840 API trials, while visible-positive controls surface the target in 24/24 trials.Source: §4.1 · p. 7, §4.3 · p. 9

4.2 RQ1: Extractor Reachability

• Across all six classes, mean extractor reach ranks exactly with the share of mechanisms carried inside main content, from representation (0.93) to scope (0.19).Reach also divides sharply by carrier: seven mechanisms fall between 11% and 33%, while fourteen fall between 67% and 100%; broad converters expose 17 and 16 mechanisms, respectively, but flatten channels without preserving their Office-assigned roles.Source: §4.2 · pp. 7–9, Table 5 · p. 8

4.3 RQ2: Propagation into LLM Outputs

• API propagation ranges from 0.48 (GLM) to 0.76 (Kimi), while web-chatbot propagation ranges from 0.52 to 0.76; 20 of 21 mechanisms reach at least one interface.The rates are mechanism-balanced evaluation-set results, not real-world attack prevalence; the worksheet header is the sole mechanism no tested service surfaces as evidence.Source: §4.3 · p. 9, Figure 4 · p. 9

4.4 RQ3: Model or Ingestion Layer?

• Exposure tracks the full ingestion path more closely than model identity: same-vendor entry points can diverge, while three Claude models on one shared path expose the same 16 mechanisms.Version, output format, and read mode change which evidence reaches the model; the study also finds that model-version changes on a fixed OpenAI file-input path do not change exposure.Source: §4.4 · pp. 10–11, Table 6 · p. 11
• 8 of 11 interfaces match at least one tested DOCX extractor configuration, demonstrating candidate matching over probes rather than identification of a service’s backend.One pandoc-like vector matches pandoc 3.8.3 with Markdown output on all eight probes; the authors describe this as behavioral equivalence, not backend identity.Source: Figure 7 · p. 11, §4.4 · p. 11

4.5 RQ4: How Widely Do Affected Ingestion Paths Appear in Open-Source Projects?

• The sixteen surveyed projects converge on a few extractor families: four route through markitdown, while txtai alone reaches Apache Tika, which surfaces 16 of 21 mechanisms.The source survey maps default paths, not end-to-end application propagation; spreadsheet defaults all resolve to families with broad panel reach, while Word paths vary more in measured reach.Source: §4.5 · p. 12

4.6 RQ5: How Common Are These Mechanisms in Ordinary Documents?

• Six mechanisms were absent from the sampled files and ten appeared in under 2%, while five common signatures ranged from 2.75% to 16.5%.Across format-specific samples, 748 of 4,263 documents (17.5%) carried at least one signature, a descriptive aggregate rather than a population estimate; presence alone can triage rare constructions but cannot distinguish common benign uses from planted forks.Source: §4.6 · pp. 12–13, Figure 8 · p. 13

View Construction Is a Security Policy

• Entry point, extractor version, output mode, and arguments can change exposure, while models sharing one ingestion path can retain the same exposed set.The authors argue loader selection and upgrades should be treated as security-relevant policy changes, not interchangeable implementation details.Source: §5 · p. 13
• Stable evidence vectors across API repetitions and web instances suggest a fixed evidence-fork suite can regression-test evidence selection and detect drift without backend access.The authors also note that diverse projects repeatedly route OOXML through a small set of extractor families.Source: §5 · p. 13

Coverage Is Not Semantic Fidelity

• Recovering more strings can flatten more semantic roles, while narrow extraction does not restore fidelity to Office; text coverage and semantic fidelity are distinct objectives.A proposed future defense pairs cheap presence checks for rare constructions with role-aware consistency checks for common channels, retaining source and semantic role in emitted evidence and making representation selection explicit.Source: §5 · p. 13

Limitations

• Aggregate propagation rates describe a mechanism-balanced evaluation set, not deployment document prevalence; tool, service, and dependency mappings reflect dated configurations that may evolve.The evidence-fork catalog and analysis method do not depend on any one vendor configuration.Source: §5 · p. 13

6 Conclusion

• The study confirmed 21 specification-grounded evidence-fork mechanisms across Excel, Word, and PowerPoint.These mechanisms can make model evidence diverge from the Office view presented for review.Source: §6 · p. 13
• Exposure follows ingestion configuration, not model identity alone, and shared extractor families recur across open-source projects.Source: §6 · p. 13
• Secure ingestion needs an explicit contract defining the intended view, preserving evidence provenance and semantic roles, and surfacing disagreements rather than silently flattening them.Evidence-fork probes can test that contract as loaders evolve.Source: §6 · p. 13

Live-System Testing

• Live-service testing used only the authors’ accounts and the prespecified trial matrix, with benign factual tasks and no harmful payloads, access-control bypass, data exfiltration, or service disruption.The remaining provider impact was ordinary computation for uploads and queries; the services were not stress-tested or intentionally altered in shared state.Source: Ethical Considerations · pp. 16–17

Human Subjects and Data

• The study recruited no external participants or collected service-user data; fixtures used public TAT-QA excerpts [20] with synthetic traps, and the RQ5 scan reported aggregate structural findings.The authors did not collect private user documents or intentionally extract or publish personal information from public files.Source: Ethical Considerations · p. 17

Dual Use and Decision to Publish

• The catalog and fixture generator are functional dual-use artifacts, but the authors published them with benign traps, provenance-aware defenses, and provider notification, judging defensive benefits to outweigh residual risks.The authors note that publication cannot eliminate misuse risk and that the underlying OOXML features are already publicly documented.Source: Ethical Considerations · p. 17

Provider Feedback

• The authors do not characterize the measured behavior as a conventional software vulnerability or parser bug, and sent feedback to several providers before submission without treating responses as evidence.Any provider acknowledgment, scope decision, or lack of response neither validates nor refutes the measurements.Source: Ethical Considerations · p. 17