Yopass

Security

• [GHSA-rpg6-935f-pp7v] Remote memory exhaustion via unbounded JSON body on POST /create/secret (High, CVSS 7.5)
  The handler decoded the request body without a size cap, so an unauthenticated client could
  force the server to allocate an arbitrarily large payload in memory before the --max-length
  check ran. A single large request could OOM-kill the process. The body is now bounded with
  http.MaxBytesReader and oversized requests get a 413 without being buffered. (#3772)
  Reported by @EQSTLab.

• Session cookies stayed valid after logout, and for far longer than intended. (#3775)
  securecookie.New defaults to a 30-day maxAge, so the 24h MaxAge on the cookie was a
  client-side hint only — a captured cookie authenticated for 30 days. The codec maxAge now
  matches. Sessions also carry a random ID; logout records it as revoked with a 24h TTL and
  getSession rejects any cookie whose ID is listed, so a replayed cookie no longer
  authenticates. Revocation lookups fail open, so a storage outage does not sign everyone out.
  Affects deployments running OIDC with --require-auth.

• Unbounded Prometheus label cardinality from client-supplied HTTP methods. (#3773)
  Arbitrary methods reaching the file-server catch-all route each created a new metric label,
  letting an unauthenticated client grow server memory indefinitely. Unknown methods now collapse
  to the existing <other> sentinel.

• HTTP servers had no connection timeouts. (#3776)
  A client could open a connection and hold it open indefinitely without completing a request.
  ReadHeaderTimeout and IdleTimeout are now set on the yopass server, and the full set
  including ReadTimeout/WriteTimeout on the metrics server. Whole-request deadlines are
  intentionally left off the yopass server because file upload and download stream bodies of
  arbitrary size.

Bug fixes

• A transient storage error no longer destroys a multi-view file secret. (#3774)
  FileStore.Load returned an undifferentiated error for both "object is gone" and "store is
  unreachable", and the download handler deleted the database metadata in either case — so a
  single S3 network blip or disk hiccup permanently destroyed the secret. Load now wraps the
  ErrKeyNotFound sentinel on definite not-found only (os.IsNotExist, S3 NoSuchKey/NotFound,
  database cache miss). The handler cleans up stale metadata for that case alone; anything else
  returns 503 and keeps the record so the secret survives the outage.

Hardening

• Stricter PGP armor validation on submission. (#3772) isPGPEncrypted only parsed the armor
  BEGIN line, so any string shaped like an armor header was accepted — wrong block types,
  truncated messages, plaintext wrapped in headers. The block type, body, and END marker are now
  all verified. Thanks to @xhydraxOffSec for reporting this.

  This is input hygiene, not a security boundary: a client can always encrypt with a key it
  controls, so the server can never prove a payload is encrypted. The value is rejecting
  malformed ciphertext before a sender shares a link to a secret nobody can decrypt. SECURITY.md
  is reworded accordingly — "No Plain Text Storage" is guaranteed by the client, not enforced by
  the server.

Behavior changes

• Malformed or truncated armored payloads that earlier versions accepted are now rejected with
  400. Requests exceeding the body cap return 413 instead of 400. Clients producing well-formed
  OpenPGP messages are unaffected.
• Logging out now invalidates the session server-side. Existing sessions are unaffected by the
  upgrade, but cookies issued before it are subject to the corrected 24h codec lifetime.