CHANGELOG.md

@@ -29,8 +29,9 @@ is content-identical to v0.31.4, the `info.version` stamp being the whole diff.
 
 **Read `Breaking changes` regardless.** The auto-bitrate overhaul lands here in four phases, and
 Phase 4 redefines what the bitrate number *means* on the control plane — deliberately without a
-capability handshake. Alongside it: the 2026-08-25 security review (58 confirmed findings, one of
-them a console session cookie reaching code execution), a second GameStream security pass (media-port
+capability handshake. Alongside it: the 2026-08-25 security review (58 findings, most of them minor
+hardening; the most serious let an **authenticated** console session reach the pairing routes without
+the console password, and pairing is what grants launch), a second GameStream security pass (media-port
 endpoint proof, control-stream nonce separation), and the GameStream competitive program, which turns
 **both** video and control encryption on by default.
 
@@ -113,10 +114,14 @@ per-mode bpp pin and the ceiling, and `bitrate_auto` treats PyroWave sessions as
 switch re-resolves the pin whatever the `Hello` carried.
 
 **6. Console pairing routes move behind the console password** (security review). Arming, approving
-and PIN submission rode the generic catch-all with the operator's admin bearer attached — a console
-session cookie alone reached code execution. They now sit behind the console password like the other
-trust-root routes, and the armed PIN is returned **once** in that gated response instead of riding a
-1 s status poll. *A script driving the pairing routes with only a session cookie is now refused.*
+and PIN submission rode the generic catch-all with the operator's admin bearer attached, so — alone
+among the trust-root actions — they never re-asked for the console password. Scope it correctly: the
+caller had to be an **authenticated console session** already, so this was privilege escalation
+within the console, not something an unauthenticated network peer could reach. It matters because
+pairing is what grants launch, so a console sign-in became the ability to start a process on the
+host. They now sit behind the console password like the other trust-root routes, and the armed PIN is
+returned **once** in that gated response instead of riding a 1 s status poll. *A script driving the
+pairing routes with only a session cookie is now refused.*
 
 **7. Deep links auto-dial by stable record id only.** A display name or an address gets a
 confirmation on every client.
@@ -166,12 +171,14 @@ measured loss.
 
 ### Security review 2026-08-25
 
-58 confirmed findings across host, console, clients and supply chain. Nearly every serious one is a
-documented boundary whose code had stopped enforcing what its comment promised — so where the two
-disagreed the comment won and the code was made to match, and where it could not be, the comment was
-corrected instead.
+58 findings across host, console, clients and supply chain. **Read that number for what it is:** the
+long tail is minor hardening and build-infrastructure tightening, not 58 exploitable defects. What
+the serious ones share is a shape — a documented boundary whose code had stopped enforcing what its
+comment promised — so where the two disagreed the comment won and the code was made to match, and
+where it could not be, the comment was corrected instead.
 
-**Critical:** the console pairing routes, above. **High:** the plugin lane no longer reads the
+**Most serious:** the console pairing routes, above — escalation from an already-authenticated
+console session, not a pre-auth hole. **High:** the plugin lane no longer reads the
 unredacted log ring (which carried the webhook credentials the `/hooks` carve-out exists to
 withhold), and hook lines log an origin and a short id rather than a URL or a command line; a
 plugin-reported pid is held to `procscan`'s start-time floor before the SYSTEM host will signal it;

docs/releases/v0.32.0.md

@@ -4,13 +4,13 @@ The main change is that the bitrate number now tells the truth. When you set a r
 
 The part of your client that picks the rate for you has also been rebuilt. It used to mistake a still picture for a bad connection. A paused game convinced it the link was failing, so the next moment of motion arrived at the worst quality available. Climbing back could take a minute and a half. It now tells stillness apart from congestion, and recovers in seconds.
 
-This is also a security release. A review found 58 confirmed issues. One let anyone who could open your web console page run code on your host. Please update if anything other than you can reach your host.
+It is also a security release, though the count sounds worse than it is. A review of the whole system produced 58 findings, and most are small: hardening, build infrastructure, and places where a comment promised more than the code delivered. The one worth your attention needed somebody already signed in to your web console. From there they could reach the pairing controls without being asked for the console password, and pairing a device lets it launch programs. If anyone else can sign in to your console, take this update.
 
 ## TL;DR
 
 - **The bitrate you set is now the bitrate on the wire.** It used to cover the picture only. If you tuned your rate by trial and error, read "Before you update".
 - **Automatic bitrate no longer misreads a still picture as a bad connection.** Motion starts sharp, and recovery takes seconds instead of 100.
-- **Please update: 58 security issues are fixed.** One of them let a browser session on the web console reach code execution on your host.
+- **A security review fixed 58 findings, most of them small.** The one that mattered needed somebody already signed in to your web console. From there they could pair a device without the console password, and pairing is what lets a device launch programs.
 - **Android TV: fixed a permanent black screen with working sound.** Some devices could never start their decoder, so no picture ever arrived.
 - **Two people streaming at once now both get a controller.** The second person used to get no controller on Windows, or a merged one on Linux.
 - **Fixed garbage rectangles that never went away.** Black bars moved "like an equalizer" on every decoder, and nothing ever recovered.
@@ -30,7 +30,7 @@ This is also a security release. A review found 58 confirmed issues. One let any
 
 - **Your bitrate setting means something slightly different now.** Nothing breaks, and you need do nothing. But the same number now puts less on your network than it did. If you tuned by trying numbers until streams behaved, you can ask for more than before. If you tuned *down* because streams were unstable, leave it where it is — the overshoot you were compensating for is gone.
 - **Moonlight users: your video and control channel are now encrypted by default.** Clients that support it turn it on themselves. We watched one do exactly that on a local network, unprompted. That is why it became the default. A switch exists to go back; the developer changelog names it.
-- **If you script the web console's pairing steps, they now need the console password.** Arming a pairing, approving it and submitting the PIN no longer accept a logged-in browser session alone. This is the critical security fix, so the change is deliberate. Add the password to your script.
+- **If you script the web console's pairing steps, they now need the console password.** Arming a pairing, approving it and submitting the PIN no longer accept a signed-in browser session alone. That is the security fix described below, so the change is deliberate. Add the password to your script.
 
 ## New
 
@@ -76,9 +76,11 @@ This is also a security release. A review found 58 confirmed issues. One let any
 
 ## Security
 
-A review on 2026-08-25 produced 58 confirmed findings. Almost every serious one followed the same pattern. A boundary was described correctly in its own documentation, and the code had drifted away from that promise.
+A review on 2026-08-25 produced 58 findings across the host, the console, the apps and our build infrastructure. **Most are small** — tightening you would never notice, and places where a boundary was described correctly in its own documentation while the code had quietly drifted from that promise. A handful mattered. One mattered more than the rest, and it is worth being precise about what it was and was not.
 
-**The critical finding was the web console's pairing steps.** They ran through a generic route carrying the operator's admin credentials. A browser session on the console — nothing more — could reach code execution on the host. Those steps now sit behind the console password. The PIN is handed over once in that protected response, instead of being published to anyone polling.
+**That one was the web console's pairing controls.** Reaching them meant being signed in to the console already, so this was not something a stranger on your network could do. But once signed in, those controls ran through a general-purpose route carrying the operator's own credentials. So alone among the trust-root actions, they never asked for the console password. Since pairing a device is what lets that device launch programs, the gap turned "signed in to the console" into "can start something on the host".
+
+**What changed:** arming a pairing, approving it and submitting the PIN now all sit behind that password. The PIN itself is handed over once in the protected response, rather than being readable by anything polling for status.
 
 Other fixes in this release: