OmniRoute due-diligence: maintainer, repo history, npm package trust #33

New Issue

2026-09-03T17:17:47Z

haylan commented

2026-09-03 17:17:47 +00:00

Part of #31

Question

OmniRoute's README (fetched directly, not summarized) contains "RTK + Caveman stacked compression saves 15–95% tokens (~89% avg)" — RTK and Caveman are the names of this environment's own Claude Code tooling (~/.claude/RTK.md, the Caveman persona). It also has a "For AI Agents" section stating "any capable agent (or your own code) gets the keys to the whole gateway," and ships AES-256-encrypted storage for API keys across 350+ providers plus MCP/A2A/webhook control surfaces built for agent operation.

Investigate before any real credentials touch an OmniRoute instance:

Who maintains diegosouzapw/OmniRoute — repo age, commit history, contributor count, any prior identity/reputation.
npm package (omniroute) — publish history, download counts, any flagged/reported issues, whether the package contents match the GitHub source.
Whether the RTK/Caveman name-drop is coincidental terminology, a copied/inspired-by credit, or evidence the project specifically targets AI coding agents' environments.
Any public reports (issues, forums, security advisories) of credential exfiltration, telemetry despite "disabled by default" claims, or other agent-targeted supply-chain concern.

Answer should be a clear recommendation: safe to proceed with real keys, safe to proceed sandboxed/credential-free only, or don't proceed.

Part of #31 ## Question OmniRoute's README (fetched directly, not summarized) contains "RTK + Caveman stacked compression saves 15–95% tokens (~89% avg)" — RTK and Caveman are the names of this environment's own Claude Code tooling (`~/.claude/RTK.md`, the Caveman persona). It also has a "For AI Agents" section stating "any capable agent (or your own code) gets the keys to the whole gateway," and ships AES-256-encrypted storage for API keys across 350+ providers plus MCP/A2A/webhook control surfaces built for agent operation. Investigate before any real credentials touch an OmniRoute instance: - Who maintains `diegosouzapw/OmniRoute` — repo age, commit history, contributor count, any prior identity/reputation. - npm package (`omniroute`) — publish history, download counts, any flagged/reported issues, whether the package contents match the GitHub source. - Whether the RTK/Caveman name-drop is coincidental terminology, a copied/inspired-by credit, or evidence the project specifically targets AI coding agents' environments. - Any public reports (issues, forums, security advisories) of credential exfiltration, telemetry despite "disabled by default" claims, or other agent-targeted supply-chain concern. Answer should be a clear recommendation: safe to proceed with real keys, safe to proceed sandboxed/credential-free only, or don't proceed.

haylan added the wayfinder:research label 2026-09-03 17:17:47 +00:00

haylan self-assigned this 2026-09-03 17:20:01 +00:00

haylan commented

2026-09-03 17:20:54 +00:00

Findings

Maintainer/repo (github.com/diegosouzapw/OmniRoute): Legitimate, large, active OSS project — 60.8k stars, 8.4k forks, 550+ contributors, 8,242+ commits, MIT license, first releases Dec 2024. Maintainer "diegosouzapw" (Diego Rodrigues de Sa e Souza, São Paulo) has a real multi-year GitHub history (71 public repos, 1,800+ followers, Pro dev program member, several other AI-tooling projects). Not a throwaway/sockpuppet account.

npm package omniroute: Publishes from the same repo (git+https://github.com/diegosouzapw/OmniRoute.git), maintainer email matches (diegosouza.pw@outlook.com), version history tracks the GitHub releases (currently 3.8.50/3.8.51), ~316k downloads in the last 30 days. Package contents plausibly match source — it's a bundled Next.js "standalone" build of the same repo, not a divergent/trojanized artifact.

RTK/Caveman name-drop: OmniRoute's own docs describe RTK as its internal "smart tool-result filtering, dedup & truncation" engine and Caveman as its "rule-based prose compression" engine — i.e. these are OmniRoute's own named subsystems, not a reference to this environment's ~/.claude/RTK.md/Caveman persona specifically. Found no evidence the project targets this environment by name — the terms read as generic/convergent naming for a token-compression feature, not a crafted lure. Coincidental, not a smoking gun — but also not something to fully dismiss given the second finding below.

Security history: In May 2026, Socket.dev flagged npm omniroute@3.8.5 (score 48/100, "6 AI-detected malware instances") for: root-CA installation for MITM/TLS interception (Windows/macOS/Linux), keychain credential import, execFile/PowerShell execution helpers, a local service supervisor, and unverified cloud credential sync/write-back. The maintainer published a self-attestation (docs/security/SOCKET_DEV_FINDINGS.md) and shipped v3.8.6 days later: 4 of 6 findings were ruled false positives on legitimate opt-in features (de-obfuscated the PowerShell invocation to remove the "base64-elevation" fingerprint, documented allowlisted callers), but 2 were real vulnerabilities and were patched: unauthenticated Zed credential auto-import (now requires 2-step confirmation + SHA256 fingerprint check) and unsigned Cloud Sync credential write-back (now HMAC-SHA256 signature-verified, opt-in only). A OMNIROUTE_BUILD_PROFILE=minimal build exists that stubs out all of these sensitive modules entirely. No confirmed malware, no reports found of actual credential exfiltration in the wild, no other advisories/forum reports beyond this incident. Response was handled responsibly and transparently.

Bottom line: Safe to proceed sandboxed / credential-free only, for now. This is a real, popular, actively-maintained project (not a scam or agent-targeting supply-chain attack) — the RTK/Caveman overlap looks coincidental. But it ships a genuinely large and dangerous privileged-agent attack surface by design (root CA/MITM install, keychain import, cloud credential sync, 110 MCP tools with full gateway control — matching the README's own "any capable agent... gets the keys to the whole gateway" admission), and it had two real credential-handling vulnerabilities patched only one release ago (3.8.5 → 3.8.6). Given this stack (per #31) never configures cloud provider keys anyway, initial integration should stay credential-free/local-only, ideally built with OMNIROUTE_BUILD_PROFILE=minimal to strip the MITM/keychain/cloud-sync modules that aren't needed here, before any decision to widen scope to real secrets.

## Findings **Maintainer/repo (github.com/diegosouzapw/OmniRoute)**: Legitimate, large, active OSS project — 60.8k stars, 8.4k forks, 550+ contributors, 8,242+ commits, MIT license, first releases Dec 2024. Maintainer "diegosouzapw" (Diego Rodrigues de Sa e Souza, São Paulo) has a real multi-year GitHub history (71 public repos, 1,800+ followers, Pro dev program member, several other AI-tooling projects). Not a throwaway/sockpuppet account. **npm package `omniroute`**: Publishes from the same repo (`git+https://github.com/diegosouzapw/OmniRoute.git`), maintainer email matches (diegosouza.pw@outlook.com), version history tracks the GitHub releases (currently 3.8.50/3.8.51), ~316k downloads in the last 30 days. Package contents plausibly match source — it's a bundled Next.js "standalone" build of the same repo, not a divergent/trojanized artifact. **RTK/Caveman name-drop**: OmniRoute's own docs describe RTK as its internal "smart tool-result filtering, dedup & truncation" engine and Caveman as its "rule-based prose compression" engine — i.e. these are OmniRoute's own named subsystems, not a reference to this environment's `~/.claude/RTK.md`/Caveman persona specifically. Found no evidence the project targets *this* environment by name — the terms read as generic/convergent naming for a token-compression feature, not a crafted lure. Coincidental, not a smoking gun — but also not something to fully dismiss given the second finding below. **Security history**: In May 2026, Socket.dev flagged npm `omniroute@3.8.5` (score 48/100, "6 AI-detected malware instances") for: root-CA installation for MITM/TLS interception (Windows/macOS/Linux), keychain credential import, execFile/PowerShell execution helpers, a local service supervisor, and unverified cloud credential sync/write-back. The maintainer published a self-attestation (`docs/security/SOCKET_DEV_FINDINGS.md`) and shipped v3.8.6 days later: 4 of 6 findings were ruled false positives on legitimate opt-in features (de-obfuscated the PowerShell invocation to remove the "base64-elevation" fingerprint, documented allowlisted callers), but **2 were real vulnerabilities and were patched**: unauthenticated Zed credential auto-import (now requires 2-step confirmation + SHA256 fingerprint check) and unsigned Cloud Sync credential write-back (now HMAC-SHA256 signature-verified, opt-in only). A `OMNIROUTE_BUILD_PROFILE=minimal` build exists that stubs out all of these sensitive modules entirely. No confirmed malware, no reports found of actual credential exfiltration in the wild, no other advisories/forum reports beyond this incident. Response was handled responsibly and transparently. **Bottom line**: **Safe to proceed sandboxed / credential-free only, for now.** This is a real, popular, actively-maintained project (not a scam or agent-targeting supply-chain attack) — the RTK/Caveman overlap looks coincidental. But it ships a genuinely large and dangerous privileged-agent attack surface by design (root CA/MITM install, keychain import, cloud credential sync, 110 MCP tools with full gateway control — matching the README's own "any capable agent... gets the keys to the whole gateway" admission), and it had two real credential-handling vulnerabilities patched only one release ago (3.8.5 → 3.8.6). Given this stack (per #31) never configures cloud provider keys anyway, initial integration should stay credential-free/local-only, ideally built with `OMNIROUTE_BUILD_PROFILE=minimal` to strip the MITM/keychain/cloud-sync modules that aren't needed here, before any decision to widen scope to real secrets.

haylan closed this issue

2026-09-03 17:20:59 +00:00

~~haylan referenced this issue 2026-09-03 17:21:12 +00:00~~

Migrate the AI gateway from LiteLLM to OmniRoute #31

haylan referenced this issue

2026-09-03 17:28:21 +00:00

OmniRoute: per-workload virtual keys, admin UI, and deployment shape (Docker/compose) #36

haylan referenced this issue

2026-09-03 17:28:57 +00:00

Migrate the AI gateway from LiteLLM to OmniRoute #31

Sign in to join this conversation.