SQLpage Files

An AI-assisted security audit found three vulnerabilities: one authentication bypass that is high severity for affected OIDC deployments, and two lower-severity issues. It also led to three hardening changes. Upgrade now if you use custom OIDC protected paths.

Security fixes:

• High severity for affected OIDC deployments: protected path bypass.
• Affected: sites using OIDC with custom oidc_protected_paths, such as ["/admin"], to protect only part of the site.
• Not affected: sites not using OIDC, or using the default oidc_protected_paths = ["/"] to protect the whole site.
• Impact: an unauthenticated attacker could use percent-encoded URLs to access pages that should require login. The fix checks decoded request paths against decoded oidc_protected_paths and oidc_public_paths.
• Medium severity: private SQL files could be served after privileged run_sql includes.
• Affected: apps that call sqlpage.run_sql(...) on private paths such as sqlpage/, dotfiles, absolute paths, or ../ paths.
• Impact: an attacker who knew the path could request the cached file directly and run it as a public page for a few milliseconds.
• Low severity: debug error messages displayed in production
• Affected: environment = "production" and pages that can error while serving JSON, NDJSON, SSE, or CSV contents.
• Impact: an attacker could gather private information about your database schema through error messages.

Additional hardening:

• Safely quote csv and download filename values in Content-Disposition, preventing download filename corruption.
• Reject unsafe OIDC redirect targets containing backslashes or control characters, affecting user-controlled login return targets and sqlpage.oidc_logout_url.
• Bind sqlpage.oidc_logout_url links to the current session, preventing forced logout of another browser.