Sinatra 3.2

Apply these rules only when maintaining Sinatra 3.2, the previous-major series that Sinatra's maintenance policy patches only for severe security issues; they were checked against 3.2.0. Prefer migrating to the current Sinatra 4 series, which receives every security fix and has the host-authorization control Sinatra added in 4.1.0 for CVE-2024-21510.

Apply the Ruby 3.3 baseline first and use that maintained runtime rather than the gem's obsolete Ruby 2.6 minimum. Ruby 3.2 or later avoids the known ETag regular-expression denial-of-service condition, but does not fix the forwarded-host vulnerability.

Version and middleware boundary

• Lock Sinatra, rack-protection, and Rack in Gemfile.lock. Sinatra 3.2.0 requires Rack 2.2, rack-protection = 3.2.0, Mustermann ~> 3.0, and Tilt ~> 2.0, so respect those dependencies and don't force Rack 3 or a newer Rack::Protection into this application. Rack's policy covers only its current and previous minor series, though it has kept shipping 2.2 security releases alongside them: take each one, and treat the end of 2.2 security releases as the deadline for moving to Sinatra 4. Watch Rack's own security advisories for those releases instead of waiting for bundle-audit to flag them, because the advisory databases scanners read can list an advisory's fix for Rack 3 and leave out the 2.2 release that fixes it. Audit Rack, the resolved server, and template engines separately from Sinatra.
• Expect bundle-audit to report Sinatra 3.2.0 for CVE-2024-21510 and CVE-2025-61921 on every run, because only Sinatra 4 carries those fixes.