Back to skill

Security audit

Photos

Security checks for vulnerabilities and agentic risk

Overview

This photo skill is useful but needs review because it can permanently store sensitive location and face-related records, and some metadata examples may alter original photos.

Review this skill before installing it on private or shared photo libraries. It should be used only if you are comfortable with a persistent local index of photo paths, dates, camera data, GPS-derived locations, descriptions, and person tags; ask for explicit confirmation before reverse geocoding GPS, face-based tagging, or metadata writes, and keep edits on copies only.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:16
Finding

Persistent Plaintext Storage of Sensitive Photo and Biometric Metadata

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 16-18, 25, and 39-41
Vulnerability Type: Sensitive data stored persistently without defined access controls or retention safeguards
Risk Level: Medium

Vulnerable Code Snippet:

markdown
- Create `.photo-index/` in library root with one JSON sidecar per photo
- Sidecar filename: `{original-hash}.json` — survives renames and moves
- Index fields: `hash`, `path`, `date_taken`, `camera`, `gps`, `description`, `tags`, `indexed_at`
markdown
- Cache vision results permanently in sidecar JSON — never re-analyze same photo
markdown
- **By location**: Reverse geocode GPS once, store city/country in sidecar for text search
- **By person**: If user identifies someone once ("that's Maria"), tag all similar faces in index

Technical Analysis

The Skill instructs the Agent to create persistent JSON sidecars containing photo paths, GPS information, reverse-geocoded locations, vision-generated descriptions, tags, and inferred associations between identities and similar faces. These records are stored permanently inside the photo library.

No instructions require restrictive filesystem permissions, encryption, explicit consent for face association, reduced-precision location storage, retention limits, or a secure index-deletion workflow. Consequently, a searchable collection of sensitive personal information can remain available after the immediate task has completed.

Face associations and location histories are particularly sensitive because they can reveal identities, residences, travel patterns, relationships, and activities. The content hash-based filename does not protect the sidecar contents and should not be treated as encryption or access control.

Attack Path

  1. A user asks the Agent to index or search a local photo library.
  2. The Agent creates .photo-index/ and writes one plaintext JSON sidecar per photo.
  3. EXIF ...[truncated 1108 chars]
Remediation
View remediation

Remediation Suggestions

  • Make GPS extraction, reverse geocoding, and face association explicit opt-in operations.
  • Do not persist exact GPS coordinates by default; retain only user-approved, reduced-precision location data when needed.
  • Require explicit consent before associating a person's name with similar faces.
  • Define retention limits and provide commands to inspect, export, and securely delete the complete index.
  • Create .photo-index/ and its files with permissions restricted to the library owner.
  • Encrypt sensitive index fields or the entire index when the environment provides a suitable user-controlled key store.
  • Warn users that sidecars may be included in cloud synchronization, NAS replication, and backups.
  • Exclude sensitive fields from logs, progress messages, manifests, and diagnostic output.
  • Allow users to disable permanent vision caching or retain only non-sensitive derived metadata.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:46
Finding

Metadata Commands Can Modify Original Photos Despite the Non-Destructive Policy

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 10 and 46-47
Vulnerability Type: Unsafe file modification and failure to enforce stated copy-before-edit behavior
Risk Level: Medium

Vulnerable Code Snippet:

markdown
- **Never overwrite originals** — edits go to `edited/` subfolder, originals stay untouched
markdown
- Write date: `exiftool -DateTimeOriginal="2024:03:15 14:30:00" photo.jpg`
- Strip GPS before sharing: `exiftool -gps:all= photo.jpg` (operates on copy, not original)

Technical Analysis

The safety policy requires all edits to be made in an edited/ subdirectory, but the documented exiftool examples operate directly on the supplied photo.jpg path. Neither command creates a copy, verifies that the target is under edited/, nor checks that the source and destination resolve to different files.

The statement that GPS stripping “operates on copy” is descriptive only and is not enforced by the command. If photo.jpg refers to an original library file, exiftool modifies that file's metadata. Although ExifTool commonly creates an _original backup under default behavior, the Skill does not verify that behavior, preserve the backup safely, or restore from it following an error. Tool configuration or command variations may also alter backup behavior.

This inconsistency can lead an Agent to follow the command example rather than the higher-level safety requirement.

Attack Path

  1. A user asks the Agent to correct a capture date or remove GPS metadata before sharing a photo.
  2. The Agent substitutes the original library path for photo.jpg in the documented command.
  3. The command executes without first copying the file into edited/.
  4. ExifTool writes metadata to the original file.
  5. The original's metadata is changed, and downstream indexing, synchronization, or backup processes propagate the modified version.
  6. If the wrong path was selected or a b ...[truncated 644 chars]
Remediation
View remediation

Remediation Suggestions

  • Require a copy-before-edit workflow and show it directly in every metadata-writing example.

  • Resolve and compare canonical source and destination paths before running ExifTool; abort if they refer to the same file.

  • Require the destination to be inside the designated edited/ directory.

  • Preserve file permissions and timestamps as appropriate when creating the working copy.

  • Use an explicit destination-oriented workflow, for example:

    sh
    mkdir -p -- "edited"
    cp -- "photo.jpg" "edited/photo.jpg"
    exiftool -DateTimeOriginal="2024:03:15 14:30:00" -- "edited/photo.jpg"
    
  • Apply GPS removal only to the verified copy:

    sh
    exiftool -gps:all= -- "edited/photo.jpg"
    
  • Validate the edited output and its metadata before sharing or replacing any derived artifact.

  • For bulk changes, create the required manifest, obtain user approval, and record source and destination paths.

  • Never rely solely on ExifTool's incidental backup behavior as the preservation mechanism.

Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (2)

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

The skill is presented as organizing and searching local photo libraries with safe file handling, but reverse geocoding GPS data implies sending precise location metadata to an external service unless an offline database is explicitly used. That creates a privacy and data-minimization gap because users may reasonably expect fully local processing while sensitive location history could be disclosed to third parties.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The instruction to identify a person once and then tag all similar faces introduces biometric processing and identity propagation across a photo library. This is more sensitive than ordinary organization metadata because it can infer and persist identity relationships at scale, creating privacy, consent, and misidentification risks for everyone appearing in the collection.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.