v1.4.2

MirrorProxy 1.4.2

MirrorProxy 1.4.2 fixes a high-severity server-side request forgery (SSRF)
vulnerability in upstream HTTP redirects and includes additional security and
release-maintenance updates. Thank you to @kta1kri
for the detailed private vulnerability report and responsible disclosure.

Security: validate every upstream redirect

In 1.4.1 and earlier, the shared outbound HTTP client followed a configured
upstream's redirect without checking the new destination. A malicious or
compromised upstream could redirect an otherwise legitimate public proxy
request to an internal service or cloud metadata address and return its
response to the requester. When disk caching was enabled and the response met
the normal cache rules, that response could also be stored under the original
upstream URL's cache key.

The data-plane client now handles redirects explicitly. Every new destination
must use HTTP(S), stay within a 10-hop limit, avoid HTTPS-to-HTTP downgrades,
resolve only to public addresses, and connect to the addresses that were
validated. Redirects from an explicitly configured IP upstream may stay on
that same origin, including a private IP intentionally chosen by the operator.
Cross-origin hops remove Authorization, Cookie, and Proxy-Authorization.
Because an outbound HTTP/SOCKS proxy may resolve a hostname independently of
MirrorProxy, redirects through it fail closed except for the configured IP
origin. A rejected redirect returns 502 instead of fetching the target.

This applies to the shared proxy adapters, OCI manifest and blob requests,
Composer JSON metadata, source-health probes, and administrator-initiated
GeoIP downloads. The OCI bearer-token fetch retains its existing stricter
issuer and destination rules. Local regression tests exercised real Debian OS
and OCI manifest routes against a redirecting upstream and confirmed that a
separate internal listener received no request. Same-origin redirects for an
explicitly configured private IP continue to work.

Other updates

• Added Content-Security-Policy, X-Frame-Options, X-Content-Type-Options,
  Referrer-Policy, and Permissions-Policy to server responses. HSTS is emitted
  only when the delivery path is verified as HTTPS, including trusted reverse
  proxy metadata.
• Replaced fixed cryptographic values in tests and used the authenticated
  encryption library's random nonce generator in production. The enc:v1:
  format, nonce size, authenticated data, and existing ciphertext decryption
  remain compatible.
• Updated rustls from 0.23.41 to 0.23.45 to address RUSTSEC-2026-0285,
  with only the required lockfile dependency changes.
• Updated the frontend test toolchain from Vitest 4 to Vitest 5.
• Standardized stable Release names to vX.Y.Z and the rolling prerelease
  name to Nightly.

Compatibility, upgrade, and rollback

• No configuration or SQLite migration is required. Existing routes, account
  data, secret ciphertext, and ordinary public upstream URLs remain compatible.
• Upstreams that redirect to an internal address or through a separately
  resolving outbound proxy may now return 502. Configure the trusted final
  upstream URL directly when this occurs; do not disable destination checks.
• The upgrade does not remove existing disk-cache entries. If a malicious
  upstream response may have been cached before upgrading, inspect and remove
  affected entries or restore a known-clean cache before serving them again.
• Keep a binary backup for operational rollback, but note that running 1.4.1
  restores the redirect vulnerability. Prefer correcting an incompatible
  upstream URL while retaining 1.4.2.

Verification

• The SSRF fix commit passed GitHub CI and CodeQL. The release candidate is
  checked with locked Rust formatting, strict Clippy, workspace tests, real
  administrator API smoke, dependency audit, frontend build and tests, and
  protocol smoke in CI.
• The release workflow packages server and client archives, native client
  packages, checksums, and package-manager metadata. Verify downloaded files
  against the published SHA256SUMS before installation.
• No production deployment is part of this Release.

Full comparison: v1.4.1...v1.4.2