fatedier/frpcli-tool

Audited from a 0k-token evidence dossier; 3 files read, 13 probes answered.

frp is the reverse-proxy CLI a huge slice of the self-hosting world reaches for to punch a hole through NAT: download frps/frpc, edit a toml file, and a LAN service is reachable from the internet ^[27]. The tension here is that a decade of production trust sits on top of a dependency tree the maintainers don't visibly engage: the scan turns up 14 critical and 7 high vulnerabilities ^[18].

Governance is similarly lopsided — the top ten contributors account for 92% of history, external PRs merge at 8%, and only a quarter of merges carry a review ^[28]. None of this stops frp from doing the one thing it promises, tunneling TCP/UDP/HTTP traffic, which the code backs up ^[21].

The main knocks:

• The dependency scan is not a footnote, it's a headline the project ignores. 14 critical and 7 high-severity CVEs turn up across the resolved dependency graph, and nothing in the README or release notes acknowledges them ^[18]. For a networking tool that terminates untrusted traffic, an unaddressed critical count is not a nitpick.
• The contribution funnel is narrow for a project this popular. Only 8% of merged PRs in the sample come from external authors, and just a quarter get any review before merge, while ten people account for 92% of all contributions ^[28]. That concentration means the project's future rests on very few hands.
• Two of the busiest files in the codebase have no visible test coverage. server/http/controller_v2.go and client/config_manager.go rank among the highest-churn, highest-complexity files in the repo, yet neither shows a test reference ^[4]. Config parsing and the HTTP control surface are exactly where silent regressions hurt most.
• Issue triage lags and half the tracker is stale. 55% of open issues have sat untouched more than six months, and half of first responses come from a bot rather than a human ^[28]. Adopters filing bugs should expect a long wait for substantive engagement.

What holds up:

• Getting a working tunnel running is genuinely fast. The README walks from binary download to a working SSH-through-NAT setup in four copy-paste steps with sane defaults baked into the config structs [vitals-readme, src-pkg-config-legacy-server-go]. There's no framework to learn first.
• The core claim checks out against the code. Retrieval probes for the TCP/UDP/HTTP/HTTPS and P2P claims all land on real proxy and service implementation files rather than marketing-only surface [probe-claim-3, probe-claim-4]. The README isn't overselling what the binaries do.
• Release discipline is consistent even if governance is thin. All 100 tracked releases carry notes, and the cadence has held at roughly one release every six weeks over the last two years ^[28]. Users can track what changed without digging through commit history.

A widely trusted NAT-tunneling tool undercut by an unaddressed critical CVE count and a narrow contributor base.

Compare against ngrok, Tailscale Funnel, or rathole for narrower-scope, more actively-reviewed tunneling.