Skip to content

Security: Unsafe IPC handler accepts unknown type without validation#1978

Open
ed-thuando wants to merge 1 commit intostacklok:mainfrom
ed-thuando:contribai/fix/security/unsafe-ipc-handler-accepts-unknown-type-
Open

Security: Unsafe IPC handler accepts unknown type without validation#1978
ed-thuando wants to merge 1 commit intostacklok:mainfrom
ed-thuando:contribai/fix/security/unsafe-ipc-handler-accepts-unknown-type-

Conversation

@ed-thuando
Copy link
Copy Markdown

Summary

Security: Unsafe IPC handler accepts unknown type without validation

Problem

Severity: High | File: main/src/ipc-handlers/utils.ts:L19

In main/src/ipc-handlers/utils.ts, the 'utils:get-workload-available-tools' handler accepts an unknown type for the workload parameter without validating the input. This allows any data to be passed to getWorkloadAvailableTools() without type checking or sanitization.

Solution

Add proper type validation for the workload parameter. Define an expected interface and validate the input before passing to getWorkloadAvailableTools(). Example: Create a type for Workload and use type guards to ensure the input matches expected structure.

Changes

  • main/src/ipc-handlers/utils.ts (modified)

Testing

  • Existing tests pass
  • Manual review completed
  • No new warnings/errors introduced

Generated by ContribAI v6.0.0

In main/src/ipc-handlers/utils.ts, the 'utils:get-workload-available-tools' handler accepts an `unknown` type for the workload parameter without validating the input. This allows any data to be passed to getWorkloadAvailableTools() without type checking or sanitization.

Affected files: utils.ts

Signed-off-by: ed-thuando <231172918+ed-thuando@users.noreply.github.com>
@samuv
Copy link
Copy Markdown
Collaborator

samuv commented Apr 13, 2026

thank you @ed-thuando can we also add the correct type in preload/src/api/utils.ts it should be

 workload: CoreWorkload

samuv added a commit that referenced this pull request Apr 17, 2026
…ools handler

The handler previously forwarded the raw `workload` argument straight to
getWorkloadAvailableTools, which expects the generated CoreWorkload type.
An earlier attempt (#1978) introduced a local `Workload` interface with
`name: string` and an `isWorkload` guard that only checked `typeof value' ===
`object`, so it neither matched the real type nor actually enforced a name.

- Add `isCoreWorkload` that rejects non-objects, `null`, and arrays, and
  validates `name`, `url`, `transport_type`, `proxy_mode`, `port`, and
  `remote` match their declared types when present
- Throw a `TypeError` at the IPC boundary for malformed payloads instead of
  forwarding them into the AI SDK / MCP client
- Reuse `GithubComStacklokToolhivePkgCoreWorkload` from
  `@common/api/generated/types.gen` rather than defining a parallel type
samuv added a commit that referenced this pull request Apr 17, 2026
…ools handler

The handler previously forwarded the raw `workload` argument straight to
getWorkloadAvailableTools, which expects the generated CoreWorkload type.
An earlier attempt (#1978) introduced a local `Workload` interface with
`name: string` and an `isWorkload` guard that only checked `typeof value' ===
`object`, so it neither matched the real type nor actually enforced a name.

- Add `isCoreWorkload` that rejects non-objects, `null`, and arrays, and
  validates `name`, `url`, `transport_type`, `proxy_mode`, `port`, and
  `remote` match their declared types when present
- Throw a `TypeError` at the IPC boundary for malformed payloads instead of
  forwarding them into the AI SDK / MCP client
- Reuse `GithubComStacklokToolhivePkgCoreWorkload` from
  `@common/api/generated/types.gen` rather than defining a parallel type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants