T09 · Insecure Skill Coding Practices
- Location
src/excel_exporter.py:62- Finding
Spreadsheet Formula Injection Through OCR-Controlled Invoice Fields
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill appears to perform invoice OCR as advertised, but it needs review because it mishandles API credentials and can create unsafe Excel files from untrusted invoice text.
Install only after reviewing the credential handling and Excel-output risks. Do not use the sample keys in setup.md, prefer environment variables or a secret manager over config.txt or command-line secrets, confirm you are allowed to send the invoices to Baidu OCR, and treat generated XLSX reports as sensitive files that may need formula sanitization before opening or sharing.
src/excel_exporter.py:62Spreadsheet Formula Injection Through OCR-Controlled Invoice Fields
setup.md:168Credential-Shaped Secrets in Documentation and Unsafe Credential Handling
src/invoice_extractor.py:117Predictable Temporary Files Allow Symlink Overwrite and Cross-Process Collisions
requirements.txt:1Installer Uses Unbounded Dependency Versions Without Integrity Verification
Claiming Baidu OCR while using a different OCR engine, and claiming Excel export and multi-file support without clearly implementing them, can cause users to expose sensitive invoice data under false assumptions about where data goes and what processing occurs. Such mismatches are especially risky for financial documents because they affect privacy expectations, compliance obligations, and trust in downstream outputs.
Claiming Baidu OCR while using a different OCR engine, and claiming Excel export and multi-file support without clearly implementing them, can cause users to expose sensitive invoice data under false assumptions about where data goes and what processing occurs. Such mismatches are especially risky for financial documents because they affect privacy expectations, compliance obligations, and trust in downstream outputs.
The skill processes invoices and receipts, which commonly contain sensitive financial and personal data, yet it does not clearly warn users that document contents will be transmitted to Baidu OCR. Without explicit disclosure, users cannot make an informed decision about sharing regulated or confidential data with a third party, creating privacy, compliance, and data-handling risk.
The setup guide embeds real-looking Baidu API and Secret Key values directly in a manual configuration example, and they are not labeled as fake placeholders. Readers may copy and reuse them, which can expose a real third-party account to unauthorized API consumption, billing abuse, service suspension, or compromise if the credentials are valid.
This is a true secret-exposure issue in documentation: the example shows realistic credential strings without any warning that they are nonfunctional placeholders. In the context of a skill specifically designed to interact with Baidu OCR, such keys are especially dangerous because users are expected to use them for authentication, making accidental misuse or exploitation more likely.
The skill advertises capabilities that inherently require file access, environment access, and network transmission to a third-party OCR provider, but it does not declare an explicit tool scope or permissions boundary. This creates a transparency and governance gap: users and the agent framework cannot clearly constrain or audit what resources the skill may access, increasing the risk of overbroad file reads, credential use, and external data transfer.
An overly broad trigger can cause the skill to activate for general invoice or receipt requests where users did not intend OCR processing or third-party transmission. In this context, mistaken activation is more dangerous because invoice and receipt files often contain financial identifiers, addresses, tax numbers, and other sensitive business data.
The examples encourage uploading invoice PDFs/images to Baidu OCR but provide no user-facing notice that invoice contents will be transmitted to a third-party service. Invoices routinely contain sensitive financial and personal data, so omission of a privacy/data-sharing warning can lead to unintended disclosure and compliance issues.
Passing API keys and secret keys directly on the command line can expose credentials through shell history, process listings, audit logs, and CI job logs. This creates a realistic path for credential theft and misuse of the OCR account.
The automated email example sends generated Excel invoice reports as attachments without warning that these files may contain sensitive financial and personal information. Users may adopt the pattern directly and exfiltrate data to the wrong recipient, insecure mailbox, or unmanaged email environment.
The module docstring presents the skill entirely in Chinese, and the command-line interface strings throughout the file are also Chinese-only. This imposes a specific language/locale on users without offering an opt-in choice or documenting a justified region-specific constraint.
The module docstring and all user-facing CLI messages are written exclusively in Chinese, indicating a fixed language experience. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale restriction is explicitly documented and justified, which it is not here.
The skill sends invoice images/PDF-derived image data to Baidu's external OCR API, which means potentially sensitive financial and personal data leaves the local environment. In an invoice-processing skill, this is expected functionality, but the lack of an explicit user-facing disclosure/consent mechanism creates a real privacy and compliance risk because users may not realize documents are being uploaded to a third party.
Comments, docstrings, prompts, and status messages are consistently written in Chinese, including the interactive setup flow. This creates a language policy concern because the skill does not offer any language choice or indicate that it is intentionally limited to Chinese users.
The code persists BAIDU_API_KEY and BAIDU_SECRET_KEY directly into config.txt in plaintext. If the working directory is shared, backed up, committed to source control, or readable by other local users/processes, these credentials can be exposed and then abused to access the Baidu OCR account or consume its quota.
The module description and all user-facing strings are in Chinese, including status messages and default worksheet/file names. This imposes a specific language/locale on users without offering a language choice or documenting that the skill is intended only for a Chinese-speaking or region-specific context.
The code explicitly initializes PaddleOCR with lang='ch', and the surrounding natural-language descriptions are also Chinese-only. Under the policy, forcing a specific language or locale without user opt-in is a natural-language policy concern unless the constraint is clearly documented and justified as region-specific.
When OCR fallback is used for PDF pages, rendered page images containing invoice data are written to .temp/cache on local disk. Invoice documents commonly contain sensitive financial and personal/business information, so persisting them without clear user notice or secure handling increases the risk of unintended disclosure through leftover files, backups, shared workspaces, or permissive filesystem access.
The image fallback path converts the source image into a temporary PDF and stores it under .temp/cache, again persisting invoice contents locally. Because this skill is specifically designed for invoice extraction, the temporary file is very likely to contain regulated or confidential billing data, making accidental retention or exposure materially risky.
The module docstring and CLI-facing description are written entirely in Chinese, which imposes a specific language on users without any opt-in or explanation. Under the policy rule, forcing a language/locale without user choice or documented justification is a natural-language policy violation.
This tool processes invoices, which commonly contain sensitive financial, tax, and identity information, and sends them to a third-party OCR provider while also storing extracted results locally in Excel. The file does not present a clear privacy notice, consent step, or data-handling warning, so users may unknowingly expose regulated or confidential data to external services and local storage.
The dependency is specified with a lower bound only, so installs are not reproducible and may pull in unexpected future versions. In a skill that processes untrusted invoice images/PDFs and makes network requests, dependency drift can silently introduce vulnerable or breaking releases into the runtime.
requests>=2.28.0
pandas>=2.0.0
openpyxl>=3.1.0
PyMuPDF>=1.23.0
Because requests is not pinned, it is impossible to verify from this manifest whether the deployed version includes fixes for known advisories. The risk is somewhat contextual: this skill likely calls an external OCR API, so an unsafe HTTP client version could affect credential handling, redirects, or TLS-related behavior depending on the actual installed release.
Using an unpinned pandas version means the installed package can vary across environments and over time, reducing reproducibility and making it hard to verify exposure to known issues. Although this file alone does not prove exploitation, it increases supply-chain and maintenance risk.
requests>=2.28.0
pandas>=2.0.0
openpyxl>=3.1.0
PyMuPDF>=1.23.0
Pillow>=10.0.0
The manifest does not allow verification that the installed pandas release is free of known issues. Even though the cited pandas advisory may be situational, leaving the version unpinned prevents reliable assessment and can expose the skill to vulnerable dependency resolution.
Detected: suspicious.exposed_secret_literal