Sinatra 4.2

Apply the Ruby 4.0 baseline first. These rules cover Sinatra 4.2 with the matching rack-protection 4.2, Rack 3, and rack-session 2, and were checked against 4.2.1; the Ruby baseline supplies language, persistence, filesystem, and outbound-network rules.

Runtime and dependency boundaries

• Upgrade rack-protection together with Sinatra, which requires the exact matching release, and respect the Rack >= 3.0, < 4 and rack-session >= 2.0, < 3 dependency bounds. Verify the locked stack on the deployed Ruby 4.0 patch; Sinatra's Ruby 2.7.8 minimum is an installation constraint, not a promise of ongoing Ruby support or proof of Ruby 4.0 testing.
• Lock Rack and audit it separately from Sinatra, whose >= 3.0, < 4 requirement admits Rack releases with known host and scheme parsing, multipart exhaustion, header injection, and file-serving flaws. Rack's policy covers only its current and previous minor series and Rack 3.0 no longer gets security releases, so keep the lock on a supported Rack 3 series and take each of its security releases. On the older supported series, watch Rack's own security advisories instead of waiting for bundle-audit to flag a release, because the advisory databases scanners read can list a fix only for the newest series.
• Lock rack-session and audit it on its own, since Sinatra's >= 2.0, < 3 requirement also admits flawed releases. rack-session 2.0.0 through 2.1.1, which predate the 2.1.2 fix, accept a forged cookie as session data when decryption under secrets: fails, and the forged data can also reach Marshal deserialization; after running