This release includes 2 breaking changes for platform teams planning a safe upgrade.
✓ No known CVEs patched in this version
Topics
Affected surfaces
ReleasePort's take
Light signalStarting with version 2.42.5, Portainer MCP will hard‑fail at startup if `PORTAINER_API_KEY` is not set when using HTTP transport; deployments must now pass a per‑user API key via the `X-Portainer-API-Key` header.
Why it matters: Version 2.42.5 enforces mandatory `PORTAINER_API_KEY`; any HTTP‑transport deployment missing this configuration will abort on startup, requiring immediate update to include per‑user key passthrough.
Summary
AI summaryPORTAINER_API_KEY hard‑fails at startup for HTTP transport; per‑user API key passthrough via X-Portainer-API-Key is now required.
Changes in this release
| Type | Severity | Summary | CVE |
|---|---|---|---|
| Security | High |
Enforces TLS on non-loopback HTTP binds; server refuses to start without cert, proxy attestation, or explicit plaintext opt‑out. Enforces TLS on non-loopback HTTP binds; server refuses to start without cert, proxy attestation, or explicit plaintext opt‑out. Source: llm_adapter@2026-06-09 Confidence: high |
— |
| Breaking | High |
Breaks HTTP-transport deployments: per-user Portainer API-key passthrough required; `PORTAINER_API_KEY` now hard-fails at startup under `PORTAINER_MCP_TRANSPORT=http`. Breaks HTTP-transport deployments: per-user Portainer API-key passthrough required; `PORTAINER_API_KEY` now hard-fails at startup under `PORTAINER_MCP_TRANSPORT=http`. Source: llm_adapter@2026-06-09 Confidence: high |
— |
| Dependency | Medium |
Bumped `fastmcp` to ≥3.4.2 and dropped direct `starlette` pin; CVE floor now carried transitively. Bumped `fastmcp` to ≥3.4.2 and dropped direct `starlette` pin; CVE floor now carried transitively. Source: llm_adapter@2026-06-09 Confidence: high |
— |
Full changelog
2.42.5 — Targets Portainer 2.42.x
[!WARNING]
Breaking change for HTTP-transport deployments.The HTTP credential model is now per-user passthrough. The bearer token is only an access gate; each caller must send their own Portainer API key in the
X-Portainer-API-Keyheader.
PORTAINER_API_KEYnow hard-fails at startup underPORTAINER_MCP_TRANSPORT=http— it is a stdio-only credential.Migration: remove
PORTAINER_API_KEYfrom your HTTP deployment and have each client sendX-Portainer-API-Keyalongside the existingAuthorization: Bearer <gate-token>. stdio transport is unaffected.
Added
- TLS posture enforcement on non-loopback HTTP binds (#67). The server
won't boot on a non-loopback bind unless you declare a cert
(PORTAINER_MCP_TLS_CERT/_TLS_KEY), proxy TLS attestation
(PORTAINER_MCP_TRUST_PROXY_TLS=1+..._FORWARDED_ALLOW_IPS), or the loud
plaintext opt-out (PORTAINER_MCP_DANGEROUSLY_ALLOW_PLAINTEXT_HTTP=1).
Loopback exempt; self-signed certs warn but don't block.
Changed
- Per-user Portainer API-key passthrough over HTTP (#66) — see the warning
above. Validation is cached positive-only (PORTAINER_MCP_AUTH_CACHE_TTL,
default 60s); the per-user key is never logged. - Bumped
fastmcpto>=3.4.2, dropped the directstarlettepin (CVE floor
now carried transitively).
Documentation
- Hygiene skill: an edge agent's health comes from its heartbeat, not its
Statusfield (#70).
Full changelog: https://github.com/portainer/portainer-mcp/blob/2.42.5/CHANGELOG.md
Breaking Changes
- `PORTAINER_API_KEY` environment variable now causes a hard failure at startup when `PORTAINER_MCP_TRANSPORT=http`; it is limited to stdio transport only.
- HTTP credential model changed to per‑user passthrough: each caller must send its own Portainer API key in the `X-Portainer-API-Key` header; bearer token becomes only an access gate.
Weekly OSS security release digest.
The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.
No spam, unsubscribe anytime.
Share this release
Related context
Related tools
Earlier breaking changes
- v2.42.1 Breaks `make dev` to now require PORTAINER_MCP_AUTH_TOKEN for local HTTP loop.
Beta — feedback welcome: [email protected]