T09 · Insecure Skill Coding Practices
- Location
scripts/xlsx-write.py:27- Finding
Untrusted Spreadsheet Data Can Be Written as Executable Formulas
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a normal document-processing skill with some quality and dependency-safety caveats, but no evidence of hidden control, persistence, credential access, or exfiltration.
Use this only on documents and data you trust, and be careful with output paths because the scripts write files on disk. For safer installation, pin and audit the dependencies first, and avoid passing untrusted JSON into xlsx-write.py unless formula-like cell values are escaped or explicitly intended.
scripts/xlsx-write.py:27Untrusted Spreadsheet Data Can Be Written as Executable Formulas
requirements/base.txt:1Unnecessary and Unpinned PyPI Packages Shadow Standard-Library Modules
Yes, this is a mismatch based on the supplied code chunk. The description advertises a full-featured Office/PDF processing toolkit, but the actual code shown contains no functional implementation beyond metadata constants. There are no undeclared dangerous capabilities present; instead, the issue is that the declared purpose is far broader than what this code actually does.
The description presents a broad document-processing toolkit, but this code chunk only provides a limited command-line converter. Its real implemented capability is DOCX→PDF conversion when docx2pdf is installed. For PPTX→PDF, the function is only a placeholder that emits error/help text and returns failure. There is no code for document reading, writing, extraction, spreadsheet handling, PDF parsing/creation, or batch processing. This is a material description-versus-behavior mismatch due to substantial overstatement of capabilities, even though the implemented DOCX→PDF conversion partially overlaps with the declared convert feature.
The code chunk only implements DOCX text/table extraction. It does not write DOCX files, handle styles or images, process PowerPoint or Excel files, read or create PDFs, perform format conversion, or do batch processing. This is a materially narrower actual behavior than the declared description of a comprehensive Office/PDF toolkit. While this may be one component of a larger toolkit, based on the supplied code chunk alone, the description does not accurately represent what the code actually does.
The declared description presents a broad multi-format document toolkit, but the supplied code chunk implements only one small subset: creating a basic Word document. Its primary purpose is much narrower than declared. There are no undeclared sensitive behaviors or permissions, but the description substantially overstates the implemented functionality in this code chunk.
Yes, there is a mismatch. The description presents a broad multi-format document toolkit with read/write support for Office files, PDF generation, and DOCX/PPTX to PDF conversion. The actual code chunk only implements PDF text extraction and basic metadata reading for a single file via CLI. It does not read or write Word, PowerPoint, or Excel files, does not create PDFs, does not convert documents, and does not perform batch processing. While the implemented PDF-reading behavior is consistent with one small part of the description, the declared purpose materially overstates the code's scope and capabilities.
The description presents a broad document-processing toolkit covering Word, Excel, PowerPoint, and PDF, including writing, conversion, and batch operations. The actual code only implements one specific capability: reading a single .pptx file and extracting text/table content. While this behavior is consistent with one small subset of the declared PPTX-reading functionality, the code chunk does not match the declared overall scope or capabilities. This is a material description-behavior mismatch because the declared primary purpose is much broader than what the code actually does.
The description claims a broad multi-format document toolkit with read/write and conversion features. The actual code chunk only implements a narrow XLSX-reading utility: it validates an Excel file path, loads the workbook with data_only=True, extracts rows from one or more sheets, and outputs results in text or JSON. This is materially narrower than the declared purpose. While XLSX reading is consistent with one listed feature, the overall declared functionality is not accurately represented by this code chunk.
Referenced artifact was not completely inspected
pip install -r requirements/all.txt
Referenced artifact was not completely inspected
pip install -r requirements/pptx.txt # PowerPoint only
This is a markdown file, so SQP-2 applies to missing user-facing warnings in the skill description. The README shows write and conversion commands that produce output documents, but it does not mention that these operations modify the filesystem or may overwrite existing files, which is relevant to user data and system integrity.
The dependency is specified with a lower-bound version only, so builds may resolve to different versions over time. This weakens supply-chain integrity and makes security posture non-reproducible, especially for a document-processing skill that handles potentially attacker-controlled files.
# All dependencies
# Word
python-docx>=1.1.2
lxml>=5.3.0
# PowerPoint
The manifest does not pin python-docx, so it is impossible to verify from this file whether the installed version is affected by known XXE-related advisories. In a document-processing skill, XML parser weaknesses can become relevant if untrusted DOCX files are handled.
Using an unpinned lxml version allows dependency resolution to drift across environments and time, which can silently introduce vulnerable or incompatible releases. Because lxml parses complex document/XML content, reproducible version control is particularly important in this skill context.
# All dependencies
# Word
python-docx>=1.1.2
lxml>=5.3.0
# PowerPoint
python-pptx>=1.0.0
Because lxml is unpinned, this manifest cannot establish whether deployed environments use versions affected by its published advisories. Given that lxml is a core XML/HTML parsing library and this skill processes Office document formats built on XML, the context slightly increases concern.
An unpinned python-pptx dependency creates a supply-chain risk because installations may pull different releases with different security properties. In a toolkit that processes untrusted Office files, uncontrolled dependency drift increases the chance of introducing parsing-related vulnerabilities.
lxml>=5.3.0
# PowerPoint
python-pptx>=1.0.0
Pillow>=10.0.0
# Excel
Pillow is unpinned, so future installs may resolve to versions with known security defects or behavioral changes. Since image parsing is commonly exposed to malformed-input attacks and this skill handles Office/PPT content with images, the context makes strict version control more important.
# PowerPoint
python-pptx>=1.0.0
Pillow>=10.0.0
# Excel
openpyxl>=3.1.0
Without an exact Pillow version, the project cannot verify whether installations include releases affected by known image-decoding vulnerabilities. Since this skill may parse embedded images from Office files, unverifiable image-library versions are a real though low-severity supply-chain risk.
The openpyxl requirement is not pinned, which means the deployed version may vary and could include unresolved security issues. Because spreadsheet parsers may process attacker-supplied files, non-reproducible dependency selection is a meaningful supply-chain weakness.
Pillow>=10.0.0
# Excel
openpyxl>=3.1.0
# PDF
pymupdf>=1.24.0
The openpyxl version is not pinned, so the manifest cannot prove whether affected versions with known XML entity issues are avoided. Spreadsheet files are often externally supplied, making unverifiable parser versions undesirable from a security standpoint.
PyMuPDF is specified only with a minimum version, allowing uncontrolled upgrades or environment-dependent resolution. In a PDF-processing toolkit, this increases exposure because PDF parsers are high-risk components and version drift can reintroduce vulnerable builds.
openpyxl>=3.1.0
# PDF
pymupdf>=1.24.0
PyMuPDF has known advisories, and because the dependency is not pinned, the manifest cannot demonstrate that deployments avoid affected versions. PDF parsing is a sensitive attack surface, so unverifiable version selection in this context is a genuine low-severity weakness.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
# Core dependencies
pathlib
argparse
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
# Core dependencies
pathlib
argparse
The dependency is specified with a minimum version only, which makes builds non-reproducible and allows future releases to be installed without review. That can introduce vulnerable or breaking versions through the supply chain even if the current tested version is safe.
# Microsoft Word (.docx)
python-docx>=1.1.2
lxml>=5.3.0
python-docx has known historical advisories, including XXE-related issues, and because the manifest is not pinned it is impossible to verify whether deployments will install an affected release. In a document-processing skill, that uncertainty matters more because the package may parse attacker-controlled Office files.
No suspicious patterns detected.