T09 · Insecure Skill Coding Practices
- Location
scripts/generate_record.js:86- Finding
Shared Nested Template Leaks Patient Data Across Generated Records
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This medical-record skill is coherent in purpose but needs review because it can invent missing clinical facts and save sensitive records to local files without adequate safeguards.
Review carefully before installing or using with real patient information. Do not treat generated records as clinical facts without authorized clinician review, avoid entering unnecessary identifiers, and do not use the save/logging paths for sensitive records unless storage location, access controls, retention, and filename handling are corrected.
scripts/generate_record.js:86Shared Nested Template Leaks Patient Data Across Generated Records
scripts/generate_record.js:150Caller-Controlled Filename Allows Path Traversal and Plaintext Medical-Record Storage
test.js:18Complete Medical Records Are Disclosed Through Standard Output
SKILL.md:30Missing Clinical Facts Are Replaced With Unverified Normal Findings
The skill handles highly sensitive medical data but does not warn users about privacy risks, data minimization, or appropriate use. This can lead users to disclose unnecessary protected health information without informed awareness, increasing confidentiality and compliance risk.
Instructing the system to fill unspecified medical fields as 'normal' or with clinical defaults can fabricate health facts that were never provided or verified. In a medical-record workflow, this is especially dangerous because false documentation can mislead clinicians, create legal/compliance exposure, and corrupt sensitive patient records.
The trigger keyword "入院记录" is broad enough to match many ordinary requests about admission notes, which can cause the skill to activate outside a narrowly intended workflow. In a medical context, over-broad invocation is more sensitive because it may steer users into generating or handling clinical documentation when they only intended a general discussion, increasing privacy and safety risk.
The English trigger "medical record" is highly generic and overlaps with common conversation, making accidental activation likely. Because this skill concerns medical documentation, unintended activation can expose sensitive workflows, collect health information unnecessarily, or generate formal-looking records in situations where the user did not request that specific function.
The trigger phrases are broad enough that normal conversation about medical records could activate the skill unintentionally, causing collection or generation of sensitive health content without clear user intent. In a medical context, accidental activation is more dangerous because it may prompt for or expose protected health information.
The skill description and workflow are written to operate in Chinese and present Chinese trigger phrases and output expectations, while not offering a language choice or stating that the skill is intentionally limited to a Chinese-speaking or region-specific context. This creates a natural-language locale policy concern under the rule for forced language without user opt-in.
The description and most trigger phrases are specified only in Chinese, presenting the skill as a Chinese-language workflow without documenting any user choice of language or locale. This can violate language/locale policy when the skill effectively assumes a specific language by default instead of offering opt-in or alternatives.
The trigger list contains generic phrases such as “入院记录” and “medical record” that can plausibly appear in ordinary conversation, increasing the chance the skill activates when the user did not explicitly request it. In a medical context, unintended invocation is more sensitive because it can steer the conversation into handling personal health information or generating clinical documentation without clear user intent.
The example explicitly saves a generated medical record containing highly sensitive patient data to a file, but provides no guidance on secure storage, access controls, encryption, retention, or de-identification. In a medical-record generation skill, this omission is more dangerous than in ordinary content because users may copy the pattern directly and persist protected health information in insecure locations, creating confidentiality and compliance risks.
The script persists generated medical records to a local file, which expands the skill from drafting text into storing sensitive health information on disk. In a medical-record context, local persistence increases confidentiality and compliance risk because patient data may be written to insecure locations, retained longer than intended, or accessed by other local users/processes.
The code writes potentially sensitive patient records to disk without any explicit warning, confirmation, or privacy notice. In the context of medical documentation, silent persistence of PHI materially increases the chance of accidental disclosure, mishandling, and noncompliant data storage.
The saveToFile function accepts an arbitrary filename and joins it with process.cwd(), allowing callers to choose essentially any writable path relative to the current working directory, including parent-directory traversal such as ../../file. This is more than a privacy issue: it creates a generic local file-write primitive that could overwrite other files the process can access.
This markdown file is entirely written as a Chinese admission-record template and does not offer any language or locale choice. Under the stated policy, forcing a specific language without user opt-in can be a natural-language policy violation unless the locale constraint is clearly documented and justified.
This JavaScript file uses Chinese exclusively in comments, test data values, and console output strings, with no indication that the user can choose another language or locale. That creates a natural-language policy concern when a skill implicitly enforces a specific language without documented opt-in or justification.
The natural-language instructions and primary invocation phrases are Chinese-only, which can amount to a language-policy constraint if users are not given an explicit language or locale choice. The file does include one English trigger phrase, but it does not clearly state that users may interact in multiple languages or that the Chinese focus is intentionally region-specific.
All headings, instructions, sample data, and output are written in Chinese, which can amount to a language-policy issue if the skill effectively forces a specific language without user opt-in. The file does not indicate that the skill is China-specific or that users may choose another language.
The code uses toLocaleTimeString('zh-CN') and all user-facing text is fixed in Chinese, which imposes a specific language/locale choice. The file does not provide an opt-in, configuration option, or explanation that this skill is intentionally limited to a Chinese-language or region-specific context.
No suspicious patterns detected.