Piano Score Fingering Arrangement

• Outcome: Review
• Latest audit: Sep 16, 2026 · 11:17 AM UTC
• Version: 0.1.0

Overview

This skill is a disclosed local piano-score fingering workflow, with some normal local file-processing risks but no evidence of hidden or malicious behavior.

Install only if you are comfortable giving the skill local access to the score files and output directory you choose. Avoid running it on untrusted MXL/PDF/image files outside a constrained environment, and avoid writing outputs into shared directories where another local user or process can pre-create symlinks with predictable temporary names.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/render_fingering_pdf.py:190

Finding

Predictable Temporary Files Permit Symlink-Based File Overwrite

Content

View full analysis

.overlay-tmp.pdf` - `.source-tmp.pdf` These files are not created through an exclusive temporary-file API. `Path.write_bytes()` follows symbolic links and does not protect against a file being replaced between validation and use. If the output directory is writable by another local user or process, that party can create one of the predictable temporary paths as a symbolic link to another file. The renderer then follows the link and overwrites the target with generated PDF data. The unconditional cleanup also removes the temporary path after use. When that path is a symbolic link, cleanup removes the link rather than restoring or validating it; the linked target remains corrupted. This is a local file-system vulnerability and does not independently grant access to files that the account running the Skill cannot already write. ### Attack Path 1. An attacker determines the renderer's intended output path, such as `/s ...[truncated 1311 chars]

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/create_plan_from_musicxml.py:38

Finding

Unbounded MXL Archive Decompression Can Exhaust Memory

Content

View full analysis

tuple[ET.ElementTree, str]: if path.suffix.lower() != ".mxl": return ET.parse(path), path.name with ZipFile(path) as archive: root_name = "" if "META-INF/container.xml" in archive.namelist(): container = ET.fromstring(archive.read("META-INF/container.xml")) for item in container.iter(): if local(item.tag) == "rootfile": root_name = item.attrib.get("full-path", "") if root_name: break if not root_name: root_name = next(name for name in archive.namelist() if name.lower().endswith(".xml")) return ET.ElementTree(ET.fromstring(archive.read(root_name))), f"{path.name}:{root_name}" ``` ### Technical Analysis MXL files are ZIP archives. The parser calls `ZipFile.read()` for both the container manifest and selected MusicXML member. `ZipFile.read()` decompresses the complete member and returns it as an in-memory byte string before XML parsing begins. The code does not enforce limits on: - Compressed archive size; - Number of archive members; - Declared or actual uncompressed member size; - Compression ratio; - Total uncompressed data processed; - XML element count or nesting depth. A highly compressible XML member can therefore have a small on-disk size but expand to a very large in-memory representation. Additional memory is then required by `ElementTree.fromstring()` to construct the XML tree. This can terminate the process through memory exhaustion or significantly degrade the host through CPU and memory pressure. The archive is not extracted to the file system, so this code does not create a Zip Slip path-traversal ...[truncated 1320 chars]

Remediation

View remediation

MAX_ARCHIVE_MEMBERS: raise ValueError("MXL contains too many members") info = archive.getinfo(root_name) if info.file_size > MAX_MEMBER_SIZE: raise ValueError("MusicXML member is too large") if info.compress_size == 0 and info.file_size: raise ValueError("invalid compression size") if info.compress_size and info.file_size / info.compress_size > MAX_COMPRESSION_RATIO: raise ValueError("suspicious MXL compression ratio") ``` 2. Read through `archive.open()` with a bounded reader instead of calling `archive.read()` without limits. Stop as soon as the maximum expanded size is exceeded. 3. Apply separate, smaller limits to `META-INF/container.xml`. 4. Limit total expanded bytes across all archive members inspected during processing. 5. Use incremental XML parsing where practical and enforce limits on element count and nesting depth. 6. Run score parsing inside a process with explicit memory, CPU-time, and wall-clock limits. 7. Add tests using high-compression-ratio MXL files and oversized XML members to verify early rejection without substantial allocation. ]]>

SkillSpector

Vulnerability Patterns

• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (133)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence

Finding

The declared description presents a broad end-to-end piano score recognition and automatic fingering system, including multi-format ingestion, coordinate preservation, fingering generation, and PDF/MusicXML export. This code chunk does not implement those capabilities. It specifically takes a MusicXML input plus a precomputed plan, maps plan records to XML notes, inserts annotations, and saves the result. That is a materially narrower and different function than the declared purpose, so this chunk does not accurately represent the description.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence

Finding

The description promises an end-to-end piano score recognition and fingering system with multiple input formats and export formats. This code chunk does not implement those capabilities. Instead, it assumes a unified plan already exists, groups notes by page, crops around saved coordinates from page images, overlays crosshairs, labels each crop with measure/note/hand/finger info, and saves PNG sheets. While it relates to coordinate-accurate review of note locations, that is only a narrow audit helper and not an accurate representation of the declared primary functionality.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The declared description presents a full music-score ingestion, recognition, fingering, and export capability. This code chunk does not implement those functions. Instead, it supports an internal review workflow over an already-existing plan structure: it validates measure regions, builds a manifest with observed note/rest counts, enforces independently entered expected counts and duration verification, and applies completed checks back into the plan JSON. That is materially different from the declared primary purpose. While such review tooling could be part of a larger OMR pipeline, this chunk itself is focused on audit/QA of measure symbols, not on piano-score reading, coordinate extraction, fingering generation, or output rendering.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence

Finding

The description claims a full score-recognition and automatic-fingering capability with format ingestion and annotated musical outputs. This code chunk does not implement those core behaviors. Instead, it validates an already-produced plan, counts assigned fingers, checks recognition quality, notes unresolved/low-confidence items, and writes a delivery report to a text file. While this reporting function is plausibly adjacent to the broader product, the actual code's primary purpose is diagnostic/report generation, not score reading, coordinate preservation, fingering generation, or output rendering. Therefore the supplied chunk does not accurately represent the declared description.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence

Finding

The code chunk’s primary function is converting MusicXML/MXL into a structured internal fingering/recognition plan. That partially aligns with the declared domain of piano score processing, but several major declared capabilities are absent from the implementation shown. There is no optical music recognition, no PDF/image handling, no MuseScore parsing, no page-coordinate preservation, no actual fingering search/generation, and no annotated PDF or MusicXML output in this file. The code does extract semantic score data relevant to later fingering workflows, so it is related, but the declared description materially overstates what this chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence

Finding

The supplied code chunk is a narrow init.py file that exposes symbols from a fingering-related core package. While this is consistent with a small part of the declared fingering functionality, it does not substantiate the broader advertised capabilities such as ingesting score files, OMR/score recognition, coordinate extraction, or output generation. Because the declared description presents a much larger end-to-end system than the actual code shown, the description is not accurately represented by this chunk.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence

Finding

The code’s primary behavior is narrow and specific: generate and refine piano fingering assignments from a pre-existing recognized note plan. It loads plan data, validates recognition, invokes a hand-position/fingering solver, applies deterministic musical repair rules, and writes the modified plan back out. That aligns with only one portion of the description: automatic piano fingering using a bundled solver. However, the declared description presents a broader end-to-end capability set including ingest of images/PDF/MusicXML/MXL/MuseScore, coordinate-preserving score recognition, and export as annotated PDF or fingered MusicXML. None of those broader I/O and annotation capabilities are present in this code chunk. This is a material description/behavior mismatch for the supplied chunk, even though the fingering-generation portion is accurately represented.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The declared description presents an end-user skill for score ingestion, recognition, coordinate preservation, automatic piano fingering, and output rendering. The supplied code chunk does none of those primary tasks. Instead, it manages a post-recognition curation pipeline over an existing plan structure: building review queues based on note confidence/validation, applying scoped add/replace/delete edits to notes, invalidating verification gates when semantic fields change, confirming gates, freezing/locking facts, and reporting lock status. While some field names relate to recognized score notes and coordinates, this is only consistent with an internal editing/QA component, not the advertised end-to-end recognition/fingering/output functionality. Therefore the code behavior is materially different from the declared purpose.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence

Finding

The declared description promises end-user capabilities for score ingestion, OMR, coordinate-preserving note extraction, automatic piano fingering, and output generation. The supplied code does none of those directly. Instead, it provides internal lifecycle/integrity utilities for extracted score facts: canonicalizing selected fields, hashing them, setting a lock, and verifying that recognition data has not changed after locking. While this could be a supporting component within a larger score-recognition/fingering system, this specific code chunk’s actual purpose is materially narrower and different from the declared description, and it introduces an undeclared integrity-locking capability as its primary function.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The declared description describes a broad piano score ingestion, recognition, coordinate preservation, and automatic fingering system with PDF/MusicXML outputs. This code chunk does none of that. It parses a JSON structure from disk and generates SVG markup for a fingered jianpu score. Its logic is purely presentational: escaping text, drawing note degrees, octave dots, duration lines, rhythm dots, hand labels, and measure boundaries. There is no parsing of score image/PDF/MusicXML/MuseScore formats, no coordinate extraction, no dynamic hand-position search or fingering computation, and no PDF or MusicXML export. The code’s primary purpose is materially different from the declared skill purpose, so this is a clear mismatch.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence

Finding

The declared description presents an end-to-end piano score recognition and fingering skill. The supplied code chunk does not implement those user-facing capabilities. Instead, it validates an existing internal 'plan' structure and enforces recognition quality gates before fingering can proceed. It checks score facts such as page/measure/hand coverage, notehead/rest bounding boxes, independent symbol checks, staff-line geometry, pitch spelling versus MIDI, keyboard positions, tie consistency, event-count checks, and unresolved review items. While this is related to the declared domain and supports the larger workflow, the actual code chunk’s purpose is narrower and materially different: validation of recognition evidence, not score ingestion, coordinate extraction, fingering generation, or annotated output creation. Therefore the description does not accurately represent what this code chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence

Finding

The declared description is about music-score OCR/recognition, coordinate-preserving notehead extraction, and automatic piano fingering generation. The supplied code does not implement any of those domain-specific behaviors. Instead, it initializes and exports interfaces from the pypdf library, whose purpose is generic PDF processing. While PDF support could be a supporting dependency for a score-processing tool, this specific code chunk is solely a generic PDF library entrypoint and exposes capabilities not mentioned in the description, such as text extraction, metadata handling, encryption/password support, and page transformations. Therefore, the code chunk's actual behavior is materially different from the declared skill purpose.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The declared description is about end-user music-processing features: optical music recognition, notehead coordinate preservation, piano fingering search, and annotated score export. The actual code chunk does none of that. It is vendor library code for decoding PDF character mappings and font encodings, a generic text-extraction support function within PDF parsing. While such code could be a supporting dependency in a PDF-processing pipeline, this chunk itself only handles Unicode/CMap parsing and provides no score-reading, music-notation semantics, coordinate tracking, fingering logic, or music file export behavior. Therefore the description does not accurately represent what this code chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The supplied code is a low-level character encoding helper from a PDF library, not music-notation analysis or fingering logic. It does not parse scores, detect noteheads, preserve coordinates, compute hand positions, or generate annotated musical outputs. While PDF-related utilities could be a supporting component in a larger system, this specific chunk is unrelated to the declared core functionality and instead serves generic text/encoding support for PDF handling.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This code chunk is a vendor utility from pypdf for LZW encoding/decoding of byte streams. Its purpose is narrowly focused on compression codecs used in PDF processing infrastructure. That is only a supporting technical component at best and does not itself implement any of the declared end-user musical capabilities. There are no signs of optical music recognition, MusicXML/MuseScore handling, notehead coordinate extraction, fingering algorithms, or score annotation. Therefore the declared description does not accurately represent what this code chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The supplied code is vendor data for pypdf: a large dictionary named 'adobe_glyphs' mapping Adobe glyph names to Unicode characters. Its purpose is text/glyph decoding support in PDF handling. This is only a low-level generic PDF/text support asset and, in this chunk, contains no logic related to optical music recognition, piano score parsing, note coordinate extraction, fingering algorithms, annotation generation, or music output. Because the declared description presents a specialized piano-score recognition and fingering skill while the actual code shown is an unrelated glyph mapping table, this is a clear description-behavior mismatch.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The supplied code is unrelated to the declared piano-score recognition and fingering functionality. It is a large lookup dictionary used by a PDF library codec for glyph-name-to-Unicode translation, likely a low-level support file for PDF text extraction/rendering. While such a table could indirectly support PDF handling elsewhere in a broader project, this chunk itself does not implement or evidence the declared primary capabilities. Therefore the description does not accurately represent what this code chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This code chunk is unrelated to the declared end-user functionality. It is a low-level glyph-name-to-Unicode lookup table used by a PDF library for character decoding. While such a table could be a minor supporting dependency for PDF text extraction, this snippet by itself does not perform any music OCR, note localization, fingering search, or output generation described in the skill. Therefore the supplied code does not accurately represent the declared purpose.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This code is unrelated to the declared music-processing functionality. It is a static glyph-to-Unicode lookup table used by a vendored PDF library component, plus a helper that fills additional glyph aliases. There is no evidence here of optical music recognition, parsing of music formats, extraction of note positions, dynamic hand-position search, or output generation for annotated scores. While such a table could be a low-level support component inside a larger PDF-processing system, this chunk by itself does not implement or directly reflect the declared primary purpose, so the description does not accurately represent what this supplied code chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The supplied code does not implement music-score recognition, fingering, coordinate tracking, annotation, or any piano-related workflow. It only contains predefined font metric tables used by a PDF library for standard font handling, plus aliases for common font names. That is unrelated support code for PDF text/font rendering rather than the declared skill behavior, so the description does not accurately represent this code chunk.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This code chunk is unrelated to the declared end-user functionality. It is a low-level encoding mapping table used for text/PDF character decoding, not logic for optical music recognition, music parsing, fingering algorithms, or score annotation. While such a table could be a supporting dependency inside a larger PDF-processing system, this specific chunk does not substantiate the declared skill purpose. Therefore the description does not accurately represent what this supplied code chunk actually does.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This code is a vendor support file for symbol-font decoding, likely used internally by a PDF library. It does not implement any of the declared end-user capabilities around music OCR, score analysis, fingering generation, or annotated output. While such a table could be a minor dependency of PDF handling elsewhere, this chunk’s actual behavior is narrowly limited to character mapping and is not accurately represented by the broad declared purpose.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

This code is a low-level vendor codec mapping from byte values to Unicode characters for the Zapf Dingbats encoding, likely a bundled dependency used in PDF processing. On its own, it is unrelated to the declared music-OMR and piano-fingering functionality. Because the actual code chunk’s purpose is materially different from the declared purpose and implements none of the described end-user capabilities, this chunk is a clear description-behavior mismatch.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The declared description is about optical/music score recognition and piano fingering workflows. The actual code chunk does something entirely different: it imports and exposes cryptographic provider implementations for PDF encryption/decryption, with fallback logic across libraries. This is a materially different primary purpose and indicates a clear description-behavior mismatch. While the broader skill might include many files, this specific supplied code chunk is unrelated to the declared music-processing functionality except for a very loose connection to PDFs.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence

Finding

The declared description is about end-to-end piano score recognition and fingering. The actual code chunk is an unrelated low-level crypt provider stub from a PDF library, exposing no music-processing behavior at all. Its primary purpose is materially different from the declared skill purpose, so this is a clear mismatch.

Content

No source excerpt is available for this finding.

Static analysis

Detected: suspicious.dynamic_code_execution, suspicious.exposed_secret_literal, suspicious.obfuscated_code

Dynamic code execution detected.

Critical

• Code: suspicious.dynamic_code_execution
• Location: scripts/vendor/typing_extensions.py:1485

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: scripts/vendor/pypdf/_encryption.py:629

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: scripts/vendor/pypdf/_reader.py:174

Potential obfuscated payload detected.

Warn

• Code: suspicious.obfuscated_code
• Location: scripts/vendor/pypdf/_doc_common.py:93

Potential obfuscated payload detected.

Warn

• Code: suspicious.obfuscated_code
• Location: scripts/vendor/pypdf/_encryption.py:112

Potential obfuscated payload detected.

Warn

• Code: suspicious.obfuscated_code
• Location: scripts/vendor/pypdf/generic/_image_inline.py:194