Back to skill

Security audit

opentable-fpx

Security checks for vulnerabilities and agentic risk

Overview

The skill is transparent about what it does, but it gives agents raw signed-in OpenTable write access without an enforced final confirmation step.

Install only if you are comfortable letting an agent act through your signed-in OpenTable browser session. Before any booking, modification, cancellation, favorite change, or payment-backed reservation, require the agent to show the exact final action, restaurant, time, party size, cancellation policy, and any card or fee terms, then approve it explicitly outside the raw fpx command flow.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:103
Finding

Consequential reservation changes lack an enforced confirmation gate

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:103-109; supporting request procedures in references/opentable-fpx-requests.md:16-19, references/opentable-fpx-requests.md:244-285, and references/opentable-fpx-requests.md:322-349
Vulnerability Type: Unconfirmed authenticated account mutation
Risk Level: Medium

Vulnerable instruction:

markdown
- **Booking, modifying, and cancelling are real actions with no
  confirm-gate here.** The MCP's `opentable_book`/`opentable_modify`/
  `opentable_cancel` tools ask the user to confirm first (a prompt, or a
  preview + single-use `confirmToken`) plus a mandatory preview step; raw
  `fpx` calls have none of that — a `make-reservation` POST
  commits immediately. Fetch `/booking/details` and read the cancellation
  policy first (§5 of the reference) before calling it.

Supporting commit procedure:

markdown
## 6. Book — step 2: commit (`/dapi/booking/make-reservation`)

Plain JSON POST (not a persisted query). Consumes the `slotLockId` from
§5, plus your own profile fields (from §4's `.header.userProfile` —
`mobilePhoneNumber.number` with the country code stripped) and a fresh
`correlationId` (any UUID). **This makes a real reservation — no
dry-run.**

Technical Analysis

The Skill intentionally replaces OpenTable MCP operations that use a prompt or a preview-bound, single-use confirmToken with direct fpx requests. These requests execute using the session of a paired, signed-in OpenTable browser tab.

The documented preview retrieves booking details and advises the Agent to inspect cancellation and payment conditions, but it does not technically enforce fresh user approval. The commit endpoint accepts the prepared reservation data directly, while the cancellation procedure similarly submits an authenticated mutation without a confirmation token or interactive gate.

This creates a reachable separation-of-intent flaw: once the ...[truncated 1984 chars]

Remediation
View remediation

Remediation Suggestions

Introduce a local write-operation wrapper and prohibit direct mutation calls from the Skill workflow.

  1. Generate a preview containing the exact action, restaurant, date and time, party size, seating area, cancellation policy, payment requirements, and any expected fee.
  2. Require fresh, explicit user approval after presenting that preview.
  3. Issue a short-lived, single-use confirmation token bound cryptographically to the action type, account context, target reservation, and complete parameter set.
  4. Reject booking, modification, cancellation, and favorite mutations unless the request includes a valid token.
  5. Invalidate the token after one use and whenever any bound parameter changes.
  6. Keep read-only operations as the default and expose mutation operations only through the confirmation-enforcing wrapper.
  7. Add a dry-run mode that emits the intended request without transmitting it.
  8. For payment-backed or fee-bearing reservations, require a separate confirmation that explicitly states the applicable financial terms.
  9. Update references/opentable-fpx-requests.md so raw mutation examples cannot be treated as directly runnable Agent procedures without the wrapper.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.