DEV Community: Johnson

Debugging Filestash 'Invalid Account': How Response Time Led Me to a Swapped Config Field

Johnson — Sat, 04 Apr 2026 14:25:36 +0000

The Problem

Filestash's passthrough auth returns "Invalid account" on login. The backend is configured to forward credentials to the local SSH server (OpenSSH on the same machine). SSH works fine when tested directly. Password auth is enabled.

SYST INFO [auth] status=failed user=myuser backend=sftp err=Invalid+account
HTTP 307 POST  4.7ms /api/session/auth/?label=sftp

Environment:

Filestash running in Docker (bridge network 172.20.0.0/16)
SSH server on host: 192.168.1.x:22, listening on 0.0.0.0:22
UFW active on host
identity_provider.type = passthrough, attribute_mapping.related_backend = sftp

Diagnostic Step 1: Read the Response Time

Before touching config, the response time is the first clue.

Time	What it means
< 5ms	Pre-connection failure — params missing/invalid, DNS failure
~5–50ms	TCP connection refused (immediate RST)
100–500ms	SSH handshake + auth failure (wrong password)
3000ms+	TCP timeout (UFW DROP, no route)

4.7ms → we never attempted a TCP connection. The error is thrown before ssh.Dial().

In Filestash's Go SFTP backend (plg_backend_sftp.go), ErrNotValid ("Invalid account") is returned whenever:

hostname is empty after decryption
ssh.Dial() fails for any reason

At 4.7ms, it's case 1.

Diagnostic Step 2: Test Container Network Access

Even though the fast response time ruled out a network issue causing this failure, understanding the network matters for the full fix:

# From inside the Filestash container
docker exec filestash curl --connect-timeout 3 telnet://192.168.1.x:22
# → Timed out after 3002ms

docker exec filestash curl --connect-timeout 3 telnet://172.20.0.1:22
# → Timed out after 3002ms

UFW is blocking Docker's subnet from SSH. This won't cause "Invalid account" (too slow), but it means even after fixing the config, we'll need to address networking.

Diagnostic Step 3: Read the Actual Config

The SFTP params are AES-256-GCM encrypted in config.json. The admin API (GET /admin/api/config) returns decrypted values — but only if you're the browser.

Initial curl attempt:

curl -b admin_cookies.txt http://localhost:8334/admin/api/config
# → {"status": "error", "message": "Not Allowed"}

Check the Filestash JS source (lib/ajax.js):

opts.headers["X-Requested-With"] = "XmlHttpRequest";

All Filestash AJAX requests include this header. Without it, admin endpoints return 403.

curl -b admin_cookies.txt \
  -H 'X-Requested-With: XmlHttpRequest' \
  http://localhost:8334/admin/api/config

Now the decrypted config returns. The SFTP params:

{
  "sftp": {
    "type": "sftp",
    "hostname": "myserver",
    "username": "{{ .user }}",
    "password": "{{ .password }}",
    "path": "192.168.1.x",
    "port": "22"
  }
}

hostname = "myserver" (machine hostname, not resolvable inside Docker container)
path = "192.168.1.x" (IP address, entered in the wrong field)

The fields were swapped during browser configuration. DNS lookup for the machine hostname fails instantly inside the container → "Invalid account" at 4.7ms. ✅ Confirmed.

The Fix

Two issues to address:

Fix 1: Correct the SFTP params

POST the corrected config via admin API:

import json, subprocess

# Read current admin config
r = subprocess.run([
    'curl', '-s', '-b', 'admin_cookies.txt',
    '-H', 'X-Requested-With: XmlHttpRequest',
    'http://localhost:8334/admin/api/config'
], capture_output=True, text=True)
cfg = json.loads(r.stdout)['result']

# strip formObj metadata wrappers (Filestash admin API format)
def strip_metadata(obj):
    if isinstance(obj, dict):
        if 'value' in obj and 'label' in obj:
            return obj['value']
        return {k: strip_metadata(v) for k, v in obj.items()}
    return obj

clean = strip_metadata(cfg)

# Fix the swapped fields
sftp_params = json.loads(clean['middleware']['attribute_mapping']['params'])
sftp_params['sftp']['hostname'] = '127.0.0.1'  # SSH server on the host
sftp_params['sftp']['path'] = '/home/myuser'    # initial directory
clean['middleware']['attribute_mapping']['params'] = json.dumps(sftp_params)

# Restore connections (they're not in admin config, come from public config)
clean['connections'] = [{'type': 'sftp', 'label': 'sftp'}]

subprocess.run([
    'curl', '-s', '-b', 'admin_cookies.txt',
    '-H', 'X-Requested-With: XmlHttpRequest',
    '-H', 'Content-Type: application/json',
    '-X', 'POST', '-d', json.dumps(clean),
    'http://localhost:8334/admin/api/config'
])

Note: Always restore connections when POSTing admin config — the admin config endpoint does not include connections (they come from the public /api/config endpoint). If you don't add them back, the login form disappears.

Fix 2: Fix container networking

With hostname = 127.0.0.1, the container needs to reach the host's SSH. Two options:

Option A — UFW rule (requires sudo):

sudo ufw allow from 172.25.0.0/16 to any port 22

Option B — Host networking (no sudo, cleaner):

# docker-compose.yml
services:
  filestash:
    image: filestash/filestash
    container_name: filestash
    network_mode: host        # remove ports: mapping, not needed with host networking
    volumes:
      - filestash_data:/app/data/state
    restart: unless-stopped

volumes:
  filestash_data:

cd ~/filestash && docker compose down && docker compose up -d

With host networking, the Filestash process runs on the host's network stack. 127.0.0.1:22 is the host's SSH server. No UFW rules needed.

Verification

After the fix:

SYST INFO [auth] status=failed user=myuser backend=sftp err=Invalid+account
HTTP 307 POST  53ms /api/session/auth/?label=sftp

53ms — actual SSH connection attempted (test was with wrong password, so auth failed, but the connection was made). With correct credentials:

SYST INFO [auth] status=ok user=myuser backend=sftp
HTTP 302 POST  91ms /api/session/auth/?label=sftp

Summary

Issue	Symptom	Cause	Fix
Hostname/path swapped	"Invalid account" in 4.7ms	Browser form filled incorrectly — `hostname="myserver"`, `path="192.168.1.x"`	Swap: `hostname="127.0.0.1"`, `path="/home/myuser"`
UFW blocks Docker subnet	TCP timeout (3s) to host SSH	UFW blocks `172.25.0.0/16 → port 22`	Switch to `network_mode: host`

Key debugging insight: Response time tells you where the failure is. Sub-5ms = before any network I/O. This rules out 90% of the usual suspects and points directly at config/param issues.

Checklist for Filestash SFTP Passthrough Auth

[ ] middleware.identity_provider.type = "passthrough"
[ ] middleware.attribute_mapping.related_backend = "sftp"
[ ] attribute_mapping.params contains correct hostname (not the machine's hostname, not the path)
[ ] connections array is present in config (check /api/config public endpoint)
[ ] Container can reach hostname:port via TCP (test with curl telnet://host:port from inside container)
[ ] SSH server has PasswordAuthentication yes (or not explicitly disabled)
[ ] When calling admin API from scripts: include X-Requested-With: XmlHttpRequest header

Filestash: https://www.filestash.app — self-hosted file browser with SFTP, S3, FTP, and more.

I Downloaded the Claude Code Source Before Anthropic DMCA'd It

Johnson — Wed, 01 Apr 2026 06:50:56 +0000

Someone reverse-engineered Anthropic's proprietary Claude Code CLI from its compiled npm bundle. They used Claude itself to do it. Published April 1st. 3.6k stars. 4.7k forks. In 15 hours.

The author left a note in the README: "I don't know how long this project will exist. Fork doesn't work well — git clone is more stable." Translation: DMCA imminent.

I cloned it immediately. Spent several hours auditing 3,817 files across 62 source directories. Here's what's actually inside — and why this is different from any source leak you've seen before.

This Isn't a Sourcemap Leak — It's Stranger

When developers hear "source leak," they assume accidentally shipped .map files alongside minified JS. The standard accidental disclosure. I checked the official @anthropic-ai/claude-code npm package for exactly that — nothing. Anthropic shipped clean.

What actually happened here is more interesting:

Decompile the 25MB official npm bundle using standard reverse tools
Feed the decompiled output into 4 rounds × 7 parallel Claude agents to reconstruct TypeScript types, interfaces, and file structure
The result had 1,341 type errors — not unusual for AI-reconstructed code
Run another round of Claude agents specifically to fix type errors → zero remaining
Auto-generate 1,206 stubs for Anthropic's private internal packages (the ones not in the npm bundle)
Run bun run dev — it boots, connects to the real Anthropic API, and prints version 2.1.87

They used Claude to rebuild Claude from Claude's own compiled output. The recursion is real.

The repository includes a RECORD.md file documenting the entire process, including the developer's machine path: /Users/konghayao/code/ai/claude-code. The original author is konghayao, and they documented every step of the methodology with enough detail that the reconstruction is reproducible.

30 Hidden Feature Flags Nobody Knew About

This is the finding that stops you cold. Inside the entry point, a single polyfill replaces the entire feature-flagging system:

const feature = (_name: string) => false;

Every feature check in the codebase calls feature("FLAG_NAME"). That one function controls all of them. And there are 30 named flags gating production-ready code that ships with every install — just silently disabled.

These aren't placeholder stubs. They're connected to real UI flows, real API calls, real session management. The code is finished. The flag just says no.

Here's what's waiting:

KAIROS — The always-running autonomous agent. Designed to operate indefinitely in the background. Sends push notifications when it needs a human decision, drops completed files when done, and resumes automatically. This is the "AI that works while you sleep."

DAEMON + BRIDGE_MODE — Claude Code restructured as a persistent background service with a remote command interface. Clients connect to the daemon and issue commands. Multiple Claude instances on the same machine, all orchestrated through a single process.

BG_SESSIONS — Background session management with a full lifecycle API: ps (list active sessions), logs (stream output), attach (drop in), kill (terminate). tmux for AI agents.

SSH_REMOTE — claude ssh <host>. Issue Claude commands directly to a remote machine. Not a terminal emulator. Claude Code itself, running headless on the remote server, controlled from your local terminal.

FORK_SUBAGENT — Mid-task state cloning. While Claude is doing something complex, you fork the current agent. The fork starts in the exact same state. Both continue independently. You can compare results or parallelize subtasks.

COORDINATOR_MODE — One Claude orchestrating a fleet of Claude workers. The coordinator breaks down work, assigns it, aggregates results. Multi-agent inside a single project, without you managing anything.

VOICE_MODE — Push-to-talk integration. Already wired up. Just needs the flag flipped and a microphone to be useful. The UI code is there.

KAIROS_GITHUB_WEBHOOKS — Claude subscribes to your repository's PR events. Commit pushed? Review requested? Claude wakes up, processes the event, and takes configured actions in real time — without you opening a terminal.

ULTRAPLAN — An extended planning mode distinct from the current plan mode. The source suggests it enables significantly longer-horizon task decomposition, likely for multi-session project work.

WEB_BROWSER_TOOL — A browsing capability directly inside Claude Code. Not scraping. A real browser tool, integrated into the agent's tool loop.

PROACTIVE — Claude monitors context and responds to things without being asked. Detects patterns, flags issues, suggests actions before you request them.

BUDDY — Multi-instance collaborative mode. Two Claude instances working on the same codebase simultaneously, with session awareness of each other.

DIRECT_CONNECT — Peer-to-peer tunnel between Claude Code instances. Skip the daemon; connect two agents directly.

TORCH and LODESTONE — Undocumented. Based on the code context, these appear to be infrastructure flags for internal Anthropic deployment tooling. The names suggest something directional — LODESTONE typically means a navigational reference point.

None of this was on any roadmap. None of it was announced. All of it shipped with @anthropic-ai/claude-code@2.1.87.

The Architecture Explains Why the Gap Is Unbridgeable

The permission system alone is 6,300 lines of TypeScript.

It includes a YOLO classifier — a component that evaluates whether a given shell command is safe to auto-execute without asking. It factors in command type, path context, recent session history, and risk heuristics. Then decides: ask the user, execute automatically, or block.

The three operating modes (plan, auto, manual) aren't UI toggles. They're deeply wired into the execution loop with different code paths for each. Switching modes mid-session is a state transition, not a preference change.

The streaming query loop is 1,700 lines. It simultaneously manages:

Token budget tracking and soft/hard limit behavior
Session auto-compaction when context fills (preserves working set, discards old context)
Multi-tool call attribution (knows which tool call produced which output)
Partial response streaming with backpressure
Interrupt handling at the right mid-execution points

Every session is serialized to disk as a JSONL artifact. This single design decision enables everything else:

/resume brings back any session from any device
Sessions survive machine reboots and crashes
FORK_SUBAGENT works because the state is just a file — you copy it
The QR code teleport feature (found in the source) works by sharing the session artifact path

There are no open-source coding agents with this infrastructure. The closest alternatives have single-session architectures. Claude Code treats sessions as first-class long-lived objects.

What the Decompiled Comments Exposed

Minification strips variable names and whitespace. It doesn't touch code comments. The 25MB bundle shipped with every comment that was present at compile time.

6 internal Anthropic Slack channel links — full https://anthropic.slack.com/archives/CHANNEL_ID/p... permalinks preserved in comments. These are engineering discussion threads that the comment author left as references. The channel IDs are: C07VBSHV7EV, C06FE2FP0Q2, C0AHK9P0129, C093BJBD1CP, C08428WSLKV, C093UA0KLD7.

Production OAuth CLIENT_ID: 9d1c250a-e61b-44d9-88ed-5944d1962f5e

Staging CLIENT_ID: 22422756-60c9-4084-8eb7-27705fd5cf9a

Staging infrastructure domains:

platform.staging.ant.dev (Anthropic's internal shorthand domain for staging)
api-staging.anthropic.com
claude-ai.staging.ant.dev

US Federal Government instance: claude.fedstart.com — a separate Claude deployment for FedRAMP-compliant government customers. There's also claude-staging.fedstart.com for the staging layer of that deployment.

Private GitHub issues up to #30,912 — comments referencing internal GitHub issues confirm the private anthropics/claude-code repository is enormous, with tens of thousands of internal issues the public never sees.

Everything came from comment strings the minifier preserved verbatim.

The Strategic Moat Is a Boolean

if (process.env.USER_TYPE === 'ant') {
  // full feature access
}

Anthropic engineers run the exact same binary as every Pro or Max subscriber. Same npm package. Same version number. But with USER_TYPE=ant set in the environment, every feature flag in that polyfill becomes true.

They've been using KAIROS, DAEMON, and COORDINATOR_MODE internally for months — possibly longer. The code is mature. It has edge case handling, error recovery, retry logic. This isn't prototype code. It's been running in production for Anthropic's own engineers.

When these features ship publicly, there's zero migration cost. The install artifact is identical. The flag just flips.

GrowthBook — not Statsig, not LaunchDarkly — manages the rollout. Found GrowthBook integration in the source confirms the rollout mechanism: percentage-based progressive rollout, starting with 1% of Pro users, expanding to 10%, then everyone. Silent A/B testing against power users before broad launch.

When KAIROS ships broadly:

Your Claude instance runs in the background indefinitely
It sends you a push notification when it needs a human decision
You approve or redirect
It continues
You come back an hour later and the feature branch is done, the tests pass, the PR is open

That's not science fiction. That's the code that ships today, gated behind a single function returning false.

What Comes Next

The DMCA will arrive. The repo link in this article may already be dead when you read it.

But the knowledge doesn't go away. The 30 feature flags now have names. The architecture is documented. The staging infrastructure is mapped. The rollout mechanism is understood.

When Anthropic announces KAIROS or DAEMON publicly, you'll know exactly what you're getting — because you've already read the code.

git clone https://github.com/claude-code-best/claude-code
# 32MB. 3,817 files. 62 directories.
# The DMCA will come. Fork before it does.

The repo may not survive the week. The insights from the source will outlast it.

FileBrowser Alternatives for Mobile: A Self-Hoster's Comparison Guide

Johnson — Sat, 28 Mar 2026 07:03:40 +0000

The Problem

If you self-host FileBrowser, you know the desktop experience is solid. But open it on your phone and you'll hit:

Tiny touch targets — buttons designed for mouse precision
Hover-dependent menus — nonexistent on touchscreens
Preview-second design — it's a file manager, not a file viewer

For mobile, you want the opposite: preview-first, big tap areas, minimal navigation depth.

I tested the major alternatives. Here's the comparison.

Quick Comparison

Tool	Primary Use	Mobile UX	Self-Host Effort	Customizable	License
Filestash	File browsing + preview	⭐⭐⭐⭐	Docker 1-liner	Yes (Vue/JS)	AGPL-3
AList	Multi-storage aggregator	⭐⭐⭐⭐	Docker 1-liner	Limited (Go)	AGPL-3
Dufs	Minimal HTTP file server	⭐⭐⭐	Single binary	No	MIT
FileBrowser	File management	⭐⭐	Docker 1-liner	Limited (Vue)	Apache-2
Nextcloud	Full cloud platform	⭐⭐	Complex stack	Yes (PHP)	AGPL-3
Cockpit	Server admin panel	⭐	apt install	No	LGPL
code-server	Remote VS Code	⭐	Docker	Yes	MIT

Tier 1: Filestash

Best for: Read-only browsing, markdown/code preview, mobile PWA

Filestash connects to your server via SFTP, WebDAV, S3, or Git, and renders a clean mobile-friendly UI. Files open in preview mode by default — markdown renders, code gets syntax highlighting, videos play inline.

Deploy

# docker-compose.yml
version: '3'
services:
  filestash:
    image: machines/filestash
    restart: always
    ports:
      - "8334:8334"
    volumes:
      - ./data:/app/data/state

docker compose up -d
# Open http://your-server:8334
# Configure SFTP backend pointing to your server

Mobile PWA Setup

Open Filestash URL in Safari/Chrome on your phone
Tap Share → "Add to Home Screen"
Now it opens fullscreen — no browser chrome, feels like a native app

Why It Works

Preview-first: Click file → see content immediately
Touch-friendly: Large tap targets, no hover dependencies
Frontend is Vue/JS: If you want to customize mobile UX (card layout, feed view, larger buttons), fork and modify

Limitations

Not perfect on mobile — community notes the webapp can feel sluggish with large directories
No native iOS/Android app
AGPL license (important if you distribute modifications)

Tier 2: AList

Best for: Multi-storage browsing, video playback, aggregating cloud + local storage

AList isn't a file browser — it's a storage aggregator with a web frontend. Mount local dirs, Google Drive, S3, OneDrive, WebDAV all in one place.

Deploy

docker run -d --restart=unless-stopped \
  -v /etc/alist:/opt/alist/data \
  -p 5244:5244 \
  -e PUID=0 -e PGID=0 \
  --name="alist" \
  xhofe/alist:latest

# Get admin password
docker exec -it alist ./alist admin random
# Open http://your-server:5244

Strengths

Video playback is excellent — streams directly in browser
Big mobile-friendly buttons
Multi-backend: Local + cloud drives in one UI
Active community, regular updates

Limitations

Built on Go — UI customization requires modifying the embedded frontend
More suited as a "content aggregator" than a "file browser"
Overkill if you only need to browse one local directory

Tier 3: Dufs

Best for: Zero-config directory serving, temporary file sharing

Dufs is a single Rust binary. No config, no database, no Docker required (though Docker works too).

Deploy

# Direct binary
curl -fsSL https://github.com/sigoden/dufs/releases/latest/download/dufs-x86_64-unknown-linux-musl -o dufs
chmod +x dufs
./dufs /path/to/your/files -p 5000 --allow-search

# Docker
docker run -v /path/to/files:/data -p 5000:5000 sigoden/dufs /data

Strengths

Zero overhead — ~5MB binary, no dependencies
HTTP directory listing with basic file preview
Built-in upload, search, auth
Works surprisingly well on mobile (responsive design)

Limitations

Bare-bones UI — no rich markdown rendering, no fancy preview
No multi-backend support
Not designed for heavy daily use

What to Avoid (for Mobile)

❌ Nextcloud / Seafile

Heavy stack (DB + Redis + cron + WebDAV). Slow on mobile. Designed for team collaboration — massive overkill for personal file browsing. If you deploy it for "just viewing files", you'll spend more time maintaining it than using it.

❌ Cockpit

Server admin panel. Has a file section but it's an afterthought. Don't install a 200MB admin suite to browse markdown files.

❌ code-server

VS Code in the browser. Fantastic on iPad with a keyboard. Unusable on a phone screen — too many tiny UI elements, too much complexity.

❌ SFTP Apps (Free Tiers)

Termius and FE File Explorer both work, but free tiers lock key features (device sync, multiple connections). The freemium model is designed to frustrate you into paying.

The Optimal Setup

After testing everything, the best mobile experience comes from layering tools:

Phone (mobile browser)
  └── Filestash (browse + preview) ← primary
  └── AList (video playback) ← when needed

Desktop (regular browser)  
  └── FileBrowser (file management)
  └── SSH terminal (admin tasks)

Architecture Decision: If You Want to Customize

Both Filestash and AList are open source. Here's where to fork:

Goal	Fork This	Why
Mobile UX improvements	Filestash	Vue/JS frontend, easy to modify
Add storage backends	AList	Clean Go backend, modular drivers
Custom preview engine	Filestash	Plugin-based viewer system
API-only file access	AList	Well-documented REST API

The "ultimate" architecture for power users:

AList as the storage aggregation layer (handles all backend connections)
Custom frontend (Next.js/Vue) consuming AList's API
Feed-based UI (recent files, search-first, no path navigation)

Key Insight

The fundamental problem with phone file browsers isn't the tools — it's the mental model. Desktop file managers assume path-based navigation: /home/user/docs/project/file.md. On a 6-inch screen, this is hostile UX.

The best mobile tools minimize directory traversal:

Preview-first: Click = see content, not open folder
Search-first: Find by name, not by path
Recency-first: Show recent files, not root directory

Pick tools that match this model. Your phone will thank you.

Running a homelab? Filestash + Docker takes 2 minutes to deploy. Try it before building anything custom.

The LiteLLM Supply Chain Attack: How a Poisoned Security Scanner Stole Credentials From Thousands of AI Environments

Johnson — Wed, 25 Mar 2026 13:03:50 +0000

The LiteLLM Supply Chain Attack: How a Poisoned Security Scanner Stole Credentials from Thousands of AI Environments

A deep dive into one of the most sophisticated software supply chain attacks of 2026 — and what every developer can learn from it.

On March 24, 2026, a developer named Callum McMahon at FutureSearch was testing a Cursor MCP plugin. Minutes after Python installed a fresh dependency, his machine ground to a halt — RAM usage spiking to 100%, processes forking uncontrollably. What he'd stumbled into wasn't a bug. It was a backdoor.

Two versions of litellm, a popular Python package downloaded 3.4 million times per day, had been poisoned. The malicious code was quietly harvesting SSH keys, cloud credentials, Kubernetes secrets, and cryptocurrency wallets — then encrypting everything and shipping it to an attacker-controlled server.

The kicker? The attackers got in by compromising a security scanner.

What Is LiteLLM?

LiteLLM is an open-source Python library that acts as a unified gateway to 100+ LLM providers — OpenAI, Anthropic, Cohere, Hugging Face, and more. With roughly 97 million monthly downloads and 2,000+ dependent packages (including DSPy, MLflow, and Open Interpreter), it sits at a critical junction in the AI developer ecosystem.

When deployed as a proxy server, LiteLLM holds API keys for multiple model providers in one place. That makes it an incredibly high-value target.

The Attack Chain: Five Days, Three Tools, One Threat Actor

The attack on LiteLLM didn't start on March 24. It started five days earlier.

Phase 1: Trivy (March 19)

Trivy is a widely-used open-source security scanner from Aqua Security. On March 19, attackers exploited a pull_request_target workflow vulnerability in Trivy's CI to exfiltrate the aqua-bot credentials. They then rewrote the Git tags for trivy-action v0.69.4 to point to a malicious release carrying a credential-harvesting payload.

Yes — a security scanner was the first domino.

Phase 2: Checkmarx KICS (March 23)

Using infrastructure from the Trivy compromise, the same attackers hit Checkmarx KICS (Keep Infrastructure as Code Secure). The C2 domain checkmarx.zone — designed to impersonate the Checkmarx security company — was registered and activated.

Phase 3: LiteLLM (March 24)

LiteLLM's CI/CD pipeline ran Trivy as part of its build process, pulling it from apt without a pinned version. The compromised Trivy action exfiltrated the PYPI_PUBLISH token from the GitHub Actions runner environment.

With that token, the attackers published:

litellm 1.82.7 at 10:39 UTC
litellm 1.82.8 at 10:52 UTC (just 13 minutes later)

Both contained malicious payloads. Different delivery mechanisms, same devastating effect.

Two Delivery Mechanisms

Version 1.82.7: Source Code Injection

The payload was base64-encoded and embedded directly inside litellm/proxy/proxy_server.py. It executes whenever anything imports litellm.proxy — the standard import path for LiteLLM's proxy server mode.

Version 1.82.8: The .pth Nuclear Option

This version added a file called litellm_init.pth to site-packages/. Python's .pth mechanism fires on every interpreter startup — no import needed. This means the payload runs when you execute pip, python -c, or even when your IDE's language server starts Python.

The .pth file was correctly declared in the wheel's RECORD file, so it passed pip's hash verification. The package passed all standard integrity checks because it was published using legitimate credentials.

CPython maintainers have acknowledged the security risk of .pth startup hooks in issue #113659, but no patch has been applied as of this writing. — Snyk

The Three-Stage Payload

Stage 1: Credential Harvesting

The script systematically collects:

System data: hostname, environment variables, running processes, network routing, auth logs
SSH keys: all private keys from ~/.ssh/
Cloud credentials: AWS credentials/config, GCP and Azure service account files, cloud metadata via IMDS queries (with full IMDSv2 signing implemented), AWS Secrets Manager, and SSM Parameter Store
Container/orchestration secrets: Docker config.json, Kubernetes kubeconfig, service account tokens, secrets, and certificates
CI/CD configs: Jenkins, Travis CI, Terraform state files
Communication tokens: Slack and Discord webhook tokens
Cryptocurrency: Bitcoin, Ethereum, Solana, Cardano, Monero wallet files, seed phrases, and Ledger hardware wallet configurations
Everything else: .env files, Git credentials, API keys from shell history, password hashes from /etc/shadow

Stage 2: Encrypted Exfiltration

The collected data is encrypted before transmission:

Generate a 32-byte AES-256 session key via openssl rand
Encrypt data with AES-256-CBC (PBKDF2 key derivation)
Encrypt the session key with a hardcoded 4096-bit RSA public key (OAEP padding)
Bundle everything into tpcp.tar.gz
POST the bundle to https://models.litellm.cloud/

The domain models.litellm.cloud was registered on March 23 — one day before the attack. The RSA public key in this payload is identical to the one found in the Trivy and KICS payloads, providing ironclad attribution.

Stage 3: Persistence and Lateral Movement

Local persistence:

Writes a backdoor to ~/.config/sysmon/sysmon.py
Creates a systemd user service named "System Telemetry Service"
The service polls https://checkmarx.zone/raw every 5 minutes for commands

Kubernetes lateral movement:
If the script finds a K8s service account token, it:

Reads all secrets across every namespace
Deploys a privileged pod to every node in kube-system using alpine:latest
These pods mount the host filesystem and install the backdoor on the underlying node

Pods are named node-setup-{node_name}, making them look like legitimate cluster operations at first glance.

The Discovery: A Bug Saved Us

The malicious payload had a critical flaw. The .pth mechanism fires when Python starts, and the payload spawns a new Python subprocess. That subprocess also triggers .pth execution, creating an unintended fork bomb that caused exponential RAM growth.

McMahon traced the OOM crash to the newly installed litellm package, found litellm_init.pth (a 34,628-byte double base64-encoded file), and published his findings on futuresearch.ai. The disclosure spread to r/LocalLLaMA, r/Python, and Hacker News within the hour.

If the attacker hadn't accidentally created a fork bomb, this could have run silently for weeks.

The Cover-Up Attempt

When the community began reporting the compromise in GitHub issue #24512, the attackers responded with brute force:

88 bot comments from 73 unique accounts posted in a 102-second window (12:44-12:46 UTC)
The accounts were previously compromised developer accounts, not purpose-created profiles
Using the compromised maintainer account (krrishdholakia), the attackers closed the issue as "not planned"
They committed messages to unrelated repositories reading "teampcp update"

76% of the bot accounts overlapped with the botnet used during the Trivy disclosure. The community routed around the censorship by opening a parallel tracking issue (#24518) and continuing discussion on Hacker News, where the thread reached 324 points.

The Blast Radius

The poisoned versions were on PyPI for approximately 3 hours. In that window, projects that filed security PRs included:

Project	Response
DSPy	PR #9498 merged; CI failure report
MLflow	PR #21971 merged
OpenHands	PR #13569
CrewAI	PR #5040 (decoupled from litellm)
langwatch	PR #2577
Arize Phoenix	PR #12342
Aider	Confirmed safe (pins litellm==1.82.3)

Remember: the .pth mechanism fires when any Python process starts, including pip itself. In CI/CD environments, this means the payload executes during build steps, not just at application runtime.

Per Wiz, LiteLLM is present in 36% of all cloud environments.

Who Is TeamPCP?

TeamPCP (also known as PCPcat, Persy_PCP, ShellForce, and DeadCatx3) has been active since at least December 2025. They maintain Telegram channels and embed the string "TeamPCP Cloud stealer" in their payloads.

The LiteLLM compromise is Phase 09 of an ongoing campaign spanning five ecosystems: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI. All three domains in this operation share the same registrar (Spaceship, Inc.) and hosting provider (DEMENIN B.V.).

Most alarmingly, per The Hacker News, TeamPCP is now collaborating with LAPSUS$, the notorious extortion group. In a Telegram post, TeamPCP stated:

"These companies were built to protect your supply chains yet they can't even protect their own. The state of modern security research is a joke. As a result, we're gonna be around for a long time stealing terabytes of trade secrets with our new partners."

They've also deployed CanisterWorm, which uses the Internet Computer Protocol (ICP) as a C2 channel — the first observed use of ICP as C2 in a supply chain campaign, making takedowns nearly impossible.

A component called hackerbot-claw uses an AI agent for automated attack targeting — one of the first documented cases of AI being used operationally in a supply chain attack.

Karpathy's Response

Andrej Karpathy, whose tweet about the incident garnered 36.7 million views, used this as a rallying point for his stance on dependency minimalism:

"I don't like adding dependencies to my projects. Instead I prefer to use an LLM to 'yoink' the code I need... I get just the code I need with no transitive dependency surprises."

Whether you agree with Karpathy's radical dependency avoidance or not, the sentiment resonated: this attack was possible because a build pipeline trusted an unpinned dependency, which trusted another unpinned dependency, creating a cascading compromise chain.

Are You Affected? Check Now

Step 1: Check your installed version

pip show litellm | grep Version

If you see 1.82.7 or 1.82.8, treat the system as compromised. Don't just upgrade — the payload may have already run.

Step 2: Check for persistence artifacts

# Check for the sysmon backdoor
ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
ls -la /root/.config/sysmon/sysmon.py 2>/dev/null && echo "ROOT BACKDOOR FOUND"

# Check for the systemd persistence service
systemctl --user status sysmon.service 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null && echo "PERSISTENCE SERVICE FOUND"

# Check for exfiltration archive remnants
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc /tmp/session.key.enc 2>/dev/null && echo "EXFIL ARTIFACTS FOUND"

Step 3: Check for malicious .pth files

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

Step 4: Verify file hashes

# Check proxy_server.py (1.82.7)
find / -path "*/litellm/proxy/proxy_server.py" 2>/dev/null -exec shasum -a 256 {} \;
# Malicious hash: a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b

# Check litellm_init.pth (1.82.8)
find / -name "litellm_init.pth" 2>/dev/null -exec shasum -a 256 {} \;
# Malicious hash: 71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238

Step 5: Check network indicators

grep "litellm.cloud\|checkmarx.zone" /etc/hosts
grep "models.litellm.cloud\|checkmarx.zone" /var/log/syslog 2>/dev/null

Step 6: Check Kubernetes

kubectl get pods -A | grep "node-setup-"

If You're Compromised: Full Remediation

Remove persistence: Delete ~/.config/sysmon/, disable sysmon.service, remove /tmp/tpcp.tar.gz and related files
Rotate ALL credentials: SSH keys, AWS/GCP/Azure keys, API keys, Docker registry creds, K8s configs, database passwords, Git credentials, cryptocurrency wallet seed phrases
Audit cloud services: AWS Secrets Manager, SSM Parameter Store, all namespaced K8s secrets
Check for rogue pods: Look for node-setup-* pods in kube-system
Reinstall clean: Use a fresh environment, pin to litellm<=1.82.6

Lessons Learned

1. Pin Your CI/CD Dependencies

LiteLLM pulled Trivy from apt without a pinned version. This is how the compromised Trivy action entered the pipeline. Every dependency in CI/CD should be pinned by hash or version.

2. Security Tools Are High-Value Targets

The attackers deliberately targeted tools with elevated access: a container scanner (Trivy), an infrastructure scanner (KICS), and an LLM gateway (LiteLLM). Each tool has broad read access to credentials by design.

3. `.pth` Files Are a Known Python Threat Vector

Python's .pth startup hooks execute arbitrary code on every interpreter startup. Despite being flagged in CPython issue #113659, no mitigation exists. Watch for packages that install .pth files.

4. Hash Verification Is Not Enough

pip install --require-hashes would have passed for both malicious versions because the malicious content was published using legitimate credentials. The hashes match what PyPI advertised — but what PyPI advertised was malicious.

5. The Snowball Effect Is Real

As Wiz researcher Gal Nagli summarized:

"Trivy gets compromised → LiteLLM gets compromised → credentials from tens of thousands of environments end up in attacker hands → and those credentials lead to the next compromise. We are stuck in a loop."

6. Accidental Bugs Save Lives

If the attacker had tested their fork bomb behavior, this could have persisted silently. They didn't, and an unintended OOM crash led to the fastest possible discovery.

The Bigger Picture

This isn't an isolated incident. It's Phase 09 of a sustained campaign that has hit five ecosystems. TeamPCP's playbook is simple and devastating: compromise a tool that has access to credentials, use those credentials to compromise the next tool, repeat.

The AI ecosystem is particularly vulnerable because:

LLM gateway tools store credentials for dozens of providers
Many AI projects move fast and pin dependencies loosely
CI/CD pipelines in ML projects often run security scanners with broad access
The AI developer community (r/LocalLLaMA, r/Python) was where the disclosure spread — not traditional security channels

The open-source supply chain's strength — that anyone can contribute — is also its weakness. When the tools we use to scan for security vulnerabilities are themselves compromised, we need to fundamentally rethink our trust model.

Indicators of Compromise (IOCs)

Type	Value
Malicious .pth hash (1.82.8)	`71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238`
Malicious proxy_server.py hash (1.82.7)	`a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b`
Exfiltration domain	`models.litellm.cloud`
C2 polling domain	`checkmarx.zone/raw`
Persistence path	`~/.config/sysmon/sysmon.py`
Systemd service	`sysmon.service` ("System Telemetry Service")
Exfil artifacts	`/tmp/tpcp.tar.gz`, `/tmp/session.key`, `/tmp/payload.enc`
K8s rogue pods	`node-setup-{node_name}` in `kube-system`

Sources: Snyk, The Hacker News, Endor Labs, FutureSearch, Wiz, Socket

Tags: #security #supplychain #python #ai #litellm #cybersecurity #opensource #devops

PicoClaw vs OpenClaw — What's the Difference?

Johnson — Mon, 23 Mar 2026 13:20:58 +0000

I've been running OpenClaw as my personal AI assistant for a few months — it handles my Discord, Slack, WhatsApp, runs scheduled tasks, controls my browser. It's basically my second brain.

Then PicoClaw dropped in February 2026, and I had a spare NanoKVM sitting on my desk. So I set it up on a $10 RISC-V board with 128MB of RAM, just to see if it could actually work.

Here's what I learned.

The quick version

OpenClaw is the full-featured TypeScript assistant that runs your digital life. It needs >1GB RAM and a real machine to run on.

PicoClaw is the Go rewrite that fits in a RISC-V chip. It uses 20MB of RAM, boots in under a second, and does everything PicoClaw needs to do — minus the stuff that requires a full desktop.

One sentence each:

PicoClaw: run AI agents on hardware you forgot you owned
OpenClaw: run AI agents that do everything you wish your computer could do automatically

Where they came from

OpenClaw started as "Clawdbot" — Peter Steinberger (the PSPDFKit founder) built it as a weekend project to relay WhatsApp messages to Claude. Then on January 9th 2026, Anthropic blocked third-party OAuth tokens, and suddenly everyone needed an alternative. Stars exploded from 2K to 219K in 3 months.

It got renamed twice — Anthropic's lawyers objected to "Clawdbot" sounding too close to "Claude," so it went Clawdbot → Moltbot → OpenClaw. In February, Steinberger joined OpenAI and handed the project to an independent foundation.

PicoClaw came from Sipeed, a Chinese hardware company that makes those tiny RISC-V boards. Their observation was simple: OpenClaw needs more than 1GB of RAM. It's not running on a $10 board. So they built a Go reimplementation that would.

By February 2026:

OpenClaw: 219K stars, 774 contributors, 50 releases
PicoClaw: 18.3K stars, 74 contributors, 3 releases — with most of the code written by the AI agent itself (95% agent-generated, they claim)

The actual difference in practice

Memory footprint:

My OpenClaw setup idles at around 1.2GB on my Mac. PicoClaw on the NanoKVM? About 20MB — they originally targeted <10MB but recent features pushed it up a bit.

Startup time is where it really shows. OpenClaw takes ~5 seconds on my M2 Mac. On a 0.8GHz board, that's 500+ seconds. PicoClaw starts in under a second on that same board.

What you can actually do with each:

PicoClaw covers the essentials: Slack, Telegram, Discord, plus the Chinese messengers (DingTalk, WeCom, QQ, LINE). It can search the web, read/write files, run shell commands, and schedule tasks. For edge deployment, that's enough.

OpenClaw covers all of that plus WhatsApp, iMessage, Signal, Teams, Google Chat, Matrix — basically the entire Western messaging stack. Then it adds browser automation (full Chromium CDP), a canvas for visual workspaces, voice wake, camera access, iOS/Android/macOS companion apps, and multi-agent coordination. It's a different beast.

The LLM provider situation:

Both work with the usual suspects: OpenAI, Anthropic, Gemini, Groq, DeepSeek, Ollama, OpenRouter, Cerebras. PicoClaw adds GitHub Copilot support (via gRPC, though without tools). OpenClaw adds NVIDIA and Volcengine.

I use Groq free tier on PicoClaw (it's free, fast, good enough for simple tasks) and Anthropic Claude on OpenClaw for the heavy lifting.

The skills/customization angle

Both use SKILL.md files for extending capabilities. The formats are almost identical — which makes sense since PicoClaw was explicitly inspired by the same patterns.

OpenClaw has ClawHub (clawhub.com), an actual marketplace where people share skills. PicoClaw doesn't have a marketplace yet — you're writing your own or adapting from OpenClaw's ecosystem.

OpenClaw also has Lobster, a typed workflow pipeline engine for complex automation. PicoClaw doesn't have this yet.

When I actually use which

PicoClaw — I use it for:

Always-on monitoring tasks that don't need heavy compute (checking price drops, RSS feeds, simple notifications)
Running on old Android phones and the NanoKVM
Situations where I need something booting in 1 second on cheap hardware

OpenClaw — Everything else. Specifically:

WhatsApp and iMessage integration (PicoClaw can't do these)
Browser automation (clicking things in Chrome, scraping, login flows)
Canvas for visual output
Multi-agent workflows where one agent spawns subagents
Anything requiring the iOS app for camera or voice

The DNA they share

What's interesting is how similar the architecture is under the hood:

Both have:
  Workspace/     agent working directory
    AGENT.md     behavior/personality
    SOUL.md      tone and style
    skills/      modular capabilities
    cron/        scheduled tasks
    sessions/    conversation history
  Gateway mode   always-on daemon
  Agent mode     one-shot CLI
  Heartbeat      periodic background tasks
  Sandbox        security boundary

This isn't accidental. PicoClaw's README literally says "inspired by the same principles." They're the same idea at different resource points on the spectrum:

$10 RISC-V ─────── Raspberry Pi ─────── Desktop/Server
    │                    │                     │
 PicoClaw            both work             OpenClaw
(only option)       (pick by features)   (full power)

Bottom line

If you want to run AI agents on cheap hardware, edge devices, or anywhere Node.js is too heavy — PicoClaw is genuinely impressive. The 20MB footprint is real. The fast boot is real.

If you want an AI assistant that handles WhatsApp, controls your browser, talks to your phone, and coordinates multiple agents in parallel — OpenClaw is what you actually want.

Most people running homelab setups end up using both: OpenClaw as the main brain on a real machine, PicoClaw on Raspberry Pis and old phones for lightweight monitoring tasks.

They're not competing — they solve different parts of the same problem.

DEV Community: Johnson

Debugging Filestash 'Invalid Account': How Response Time Led Me to a Swapped Config Field

The Problem

Diagnostic Step 1: Read the Response Time

Diagnostic Step 2: Test Container Network Access

Diagnostic Step 3: Read the Actual Config

The Fix

Fix 1: Correct the SFTP params

Fix 2: Fix container networking

Verification

Summary

Checklist for Filestash SFTP Passthrough Auth

I Downloaded the Claude Code Source Before Anthropic DMCA'd It

This Isn't a Sourcemap Leak — It's Stranger

30 Hidden Feature Flags Nobody Knew About

The Architecture Explains Why the Gap Is Unbridgeable

What the Decompiled Comments Exposed

The Strategic Moat Is a Boolean

What Comes Next

FileBrowser Alternatives for Mobile: A Self-Hoster's Comparison Guide

The Problem

Quick Comparison

Tier 1: Filestash

Deploy

Mobile PWA Setup

Why It Works

Limitations

Tier 2: AList

Deploy

Strengths

Limitations

Tier 3: Dufs

Deploy

Strengths

Limitations

What to Avoid (for Mobile)

❌ Nextcloud / Seafile

❌ Cockpit

❌ code-server

❌ SFTP Apps (Free Tiers)

The Optimal Setup

Architecture Decision: If You Want to Customize

Key Insight

The LiteLLM Supply Chain Attack: How a Poisoned Security Scanner Stole Credentials From Thousands of AI Environments

The LiteLLM Supply Chain Attack: How a Poisoned Security Scanner Stole Credentials from Thousands of AI Environments

What Is LiteLLM?

The Attack Chain: Five Days, Three Tools, One Threat Actor

Phase 1: Trivy (March 19)

Phase 2: Checkmarx KICS (March 23)

Phase 3: LiteLLM (March 24)

Two Delivery Mechanisms

Version 1.82.7: Source Code Injection

Version 1.82.8: The .pth Nuclear Option

The Three-Stage Payload

Stage 1: Credential Harvesting

Stage 2: Encrypted Exfiltration

Stage 3: Persistence and Lateral Movement

The Discovery: A Bug Saved Us

The Cover-Up Attempt

The Blast Radius

Who Is TeamPCP?

Karpathy's Response

Are You Affected? Check Now

Step 1: Check your installed version

Step 2: Check for persistence artifacts

Step 3: Check for malicious .pth files

Step 4: Verify file hashes

Step 5: Check network indicators

Step 6: Check Kubernetes

If You're Compromised: Full Remediation

Lessons Learned

1. Pin Your CI/CD Dependencies

2. Security Tools Are High-Value Targets

3. .pth Files Are a Known Python Threat Vector

4. Hash Verification Is Not Enough

5. The Snowball Effect Is Real

6. Accidental Bugs Save Lives

The Bigger Picture

PicoClaw vs OpenClaw — What's the Difference?

The quick version

3. `.pth` Files Are a Known Python Threat Vector