T09 · Insecure Skill Coding Practices
- Location
SKILL.md:35- Finding
Security-Sensitive Door Unlocking Without Explicit Confirmation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:35, 80-93
Vulnerability Type: Unsafe authorization and confirmation policy for physical-security automation
Risk Level: MediumVulnerable Code
markdown **Never require confirmation for reversible actions.** Just do it. They can say "undo" if wrong.yaml automation: - alias: "Home Arrival - Accessible" trigger: - platform: zone entity_id: person.human zone: zone.home event: enter action: - service: scene.turn_on target: entity_id: scene.welcome_home - service: lock.unlock target: entity_id: lock.front_door - service: notify.agent data: message: "Human is home. Unlocked front door."Technical Analysis
The Skill establishes a broad rule that reversible actions should not require confirmation, then provides an automation that unlocks a front door based solely on an arrival event. Although unlocking can technically be reversed by relocking the door, it creates an immediate physical-security exposure that cannot be undone if an unauthorized person enters.
Zone and presence signals are not sufficient authorization boundaries by themselves. Depending on the deployment, they may be affected by stale device state, GPS inaccuracies, account compromise, sensor errors, or spoofed presence data. The template does not require device authentication, corroborating sensors, proximity verification, or explicit user approval before operating the lock.
The repository contains documentation and configuration examples rather than an active deployment. Exploitation therefore requires a user or agent to adopt this template in a Home Assistant environment.
Attack Path
- A user or agent implements the documented arrival automation.
- The
person.humanentity incorrectly or maliciously transitions intozone.home...[truncated 846 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the blanket no-confirmation rule with a risk-based policy.
- Restrict confirmation-free execution to a narrow allowlist of low-impact actions, such as changing lights or media playback.
- Require explicit user authorization for locks, alarms, garage doors, purchases, external communications, and other consequential operations.
- For accessibility-sensitive workflows where repeated confirmation is burdensome, use a preauthorized policy with narrowly defined devices, time windows, users, and conditions.
- Require multiple trusted presence signals, such as authenticated phone proximity plus an occupancy sensor, rather than relying on one zone transition.
- Add a short timeout, automatic relocking, event logging, and an immediate security notification.
- Fail closed when presence information is stale, ambiguous, unavailable, or inconsistent.
- Preserve an accessible emergency override that is authenticated and does not weaken routine access controls.
