T09 · Insecure Skill Coding Practices
Warning
- Location
tools.py:739- Finding
Calendar event creation does not technically enforce family approval
- Content
View full analysis
Vulnerability Details
File Location:
tools.py:739-779
Vulnerability Type: Missing authorization enforcement for externally derived calendar changes
Risk Level: MediumComplete Code Snippet
python def confirm_pending_school_events(email_id: str = "") -> str: """ Create calendar events for a pending entry and clear it. If email_id is empty, confirms ALL pending entries (for "add all" replies). Returns a summary string with per-event results. """ from features.calendar.calendar_manager import create_event data = _load_pending_school_events() data = _purge_stale_pending(data) if not data: return "🤔 No pending school events to confirm." targets = [email_id] if email_id else list(data.keys()) if email_id and email_id not in data: return f"🤔 No pending events for email {email_id}." created = [] failed = [] for eid in targets: entry = data.get(eid) if not entry: continue for ev in entry.get("events", []): title = ev["title"] date = ev["date"] time_str = ev.get("time") or None try: create_event( title=title, date_str=date, time_str=time_str, duration_minutes=60, is_all_day=(time_str is None), ) created.append(f"{title} ({date})") except Exception as e: failed.append(f"{title} ({date}): {str(e)[:80]}") del data[eid] _save_pending_school_events(data)Technical Analysis
The intended workflow is documented as:
- Fetch an externally supplied school email.
- Extract proposed events.
- Store those events in a pending queue.
- Obtain confirmation from the family.
- Create the corresponding Google ...[truncated 3058 chars]
- Remediation
View remediation
Remediation Suggestions
- Generate a cryptographically random, single-use approval nonce when pending events are proposed.
- Bind the nonce to:
- The specific pending queue entry.
- A digest of the exact event fields.
- The authorized family member or conversation.
- A short expiration time.
- Require the nonce when calling
confirm_pending_school_eventsand reject missing, expired, reused, or mismatched approvals. - Remove the implicit confirm-all behavior. Require explicit queue identifiers, or require a separate approval covering the exact set of entries.
- Validate the approving sender against an allowlist of authorized family identities supplied by the trusted messaging layer.
- Separate proposal data from approval state and record approval metadata before calendar creation.
- Delete a queue entry only after all corresponding writes succeed. Retain failed events with an explicit failure state so they can be reviewed or retried.
- Add tests proving that direct calls without valid approval evidence cannot reach
create_event.