Security audit

workday-fpx

Security checks for vulnerabilities and agentic risk

Overview

This skill is not visibly malicious, but it gives an agent broad, persistent access to sensitive Workday HR data through an authenticated browser session with insufficient scoping and one misleading self-only claim.

Install only if you are authorized to use automated access for Workday data in your organization. Treat outputs as sensitive HR records, avoid broad enumeration or raw dumps, restrict browser site access to the exact tenant if possible, pin and verify the fpx package and extension source, and unpair or revoke extension access when finished.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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

Findings (2)

T08 · Insecure Dependencies

Warning

Location: SKILL.md:25
Finding: Unpinned Third-Party Components Receive Persistent Access to an Authenticated Workday Session<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 25–34 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ### Vulnerable Code ```sh npm install -g @fetchproxy/cli # provides `fpx` fpx profile add workday --domain myworkday.com # apex domain (per-tenant subdomain e.g. wd5) fpx pair -p workday # prints a pair code → approve in Transporter ``` ```text Requirements: the Transporter extension installed, an open tab at https://<host>/<tenant> (e.g. https://wd5.myworkday.com/acme) with SSO already completed, and the extension's Chrome Site access allowing myworkday.com. Pairing persists — after the first approval every later fpx call reuses it. ``` ### Technical Analysis The Skill instructs users to globally install `@fetchproxy/cli` without pinning a version or integrity hash. It then pairs that CLI persistently with a browser extension that has access to `myworkday.com` and an already authenticated Workday tab. The CLI and extension are not included in the audited project, so their implementation, update behavior, publisher authenticity, and handling of authenticated requests cannot be verified from the reviewed files. Because Workday responses may contain compensation, benefits, worker-profile, organization, and session-envelope information, the trust placed in these components is security-sensitive. The apex-domain site permission and persistent pairing are broader and longer-lived than the minimum permission needed for a single request to one tenant. Although the project contains no evidence that these components are currently malicious, an unsafe installation source, compromised publisher account, dependency compromise, or malicious extension update could abuse the established bridge. ### Attack Path 1. A user follows the Skill instructions and globally installs the latest available version of `@fetchproxy/cli`. 2. The user grants the Transporter extension access t ...[truncated 1132 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `@fetchproxy/cli` to a reviewed version instead of installing the latest release implicitly. 2. Verify package provenance and use npm integrity or lockfile controls where the installation mechanism permits. 3. Document the official CLI and extension publishers, expected package identifiers, and verified distribution URLs. 4. Scope browser site access to the exact Workday tenant host rather than the `myworkday.com` apex domain whenever the extension supports it. 5. Prefer session-scoped pairing or require reauthorization after a short expiration period. 6. Provide explicit unpairing and permission-revocation instructions. 7. Require confirmation before accessing particularly sensitive areas such as pay, compensation, benefits, or manager records. 8. Publish or independently audit the CLI, extension, and bridge protocol, including request routing, telemetry, update behavior, and response retention. 9. Ensure the bridge enforces an allowlist of expected HTTPS Workday origins and rejects redirects or requests to unrelated hosts. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: references/endpoints.md:105
Finding: Documented Worker and Manager Data Access Exceeds the Claimed Self-Only Scope<![CDATA[ ## Vulnerability Details **File Location**: `references/endpoints.md`, lines 105–156; contradictory scope statement at `SKILL.md`, line 114 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Code The Skill claims: ```text - Read-only, and touches only your own data — this is the same surface the `workday_*` MCP tools read, not the official admin-only REST/SOAP API. ``` However, the endpoint reference documents access to other workers and manager-visible data: ```markdown ## 5. Worker profile → the drill-in catalog (the manager surface) GET https://$HOST/$TENANT/inst/<workerCtx>/<workerIid>.htmld Returns "View Associate": a `compositeView` listing ~40 named, fetchable tasks across 9 sections. `<workerCtx>` differs per tenant — read it off an org-chart node's concrete profile uri (endpoint 6) rather than guessing. fpx get "https://$HOST/$TENANT/inst/1\$715/247\$42.htmld" -p workday | jq ' [.. | objects | select(.widget=="compositeViewSection") | {section: .label, tasks: [.taskNodes | .. | objects | select(.widget=="compositeViewTask") | {label, uri: (.uri + ".htmld")}]}]' Then fetch any of those uris: GET https://$HOST/$TENANT/inst/<ctx>/rel-task/<taskId>.htmld ``` The org-chart recipe also collects other workers' data: ```sh fpx get "https://$HOST/$TENANT/task/2998\$2673.htmld" -p workday | jq ' [.. | objects | select(.widget=="hierarchyNavigator") | {workerIid, chain: [.ancestors[]? | { name: (.navigatorInstance.instances[0].text // null), profileUri: (.navigatorInstance.selfUriTemplate + ".htmld"), title: (.navigatorItems[0].detailOne // null), location: (.navigatorItems[0].detailTwo // null), reports: (.navigatorItems[0].detailThree // null)}]}]' ``` ### Technical Analysis The implementation remains subject to Workday's server-side authorization, and the reviewed documentation does not demonstrat ...[truncated 2352 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove or correct the statement that the Skill touches only the user's own data. 2. Clearly distinguish self-service endpoints from worker, manager, and HR-visible endpoints. 3. Require explicit user confirmation before retrieving a profile or task associated with another worker. 4. Display the target worker identity, data category, and intended fields before each sensitive retrieval. 5. Default to self-only access and require an explicit opt-in mode for manager or organization-wide operations. 6. Apply field-level minimization and avoid returning profile URIs, task catalogs, or unrelated fields unless required by the user's request. 7. Introduce row limits and confirmation gates before traversing multiple workers or chunked grids. 8. Warn users that terminal output, shell logs, pipelines, and downstream scripts may retain regulated HR data. 9. Recommend using a dedicated Workday account or role with only the permissions necessary for the intended operation. 10. Preserve the existing guidance that excludes `sessionSecureToken`, and extend the output allowlist to other sensitive envelope and worker fields. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Missing User Warnings

High

Confidence: 96% confidence
Finding: The skill explicitly advertises access to sensitive HR, pay, benefits, and compensation data but does not present a clear privacy/security warning or require explicit user acknowledgement before use. In this context, the omission is dangerous because the skill leverages an already-authenticated corporate session, making access frictionless and increasing the risk of casual overcollection, misuse, or disclosure of regulated employee information.

Vague Triggers

Medium

Confidence: 86% confidence
Finding: The skill description is broadly framed around reading Workday HR data from any signed-in session and can be invoked in many generic Workday data-access scenarios without strong scoping constraints. Because it targets highly sensitive enterprise HR surfaces and encourages shell-based retrieval from an authenticated browser session, over-broad triggering increases the chance of unnecessary or excessive access to sensitive employee data.

Static analysis

No suspicious patterns detected.