Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Deployed instances of Datasette prior to `0.65.2` and `1.0a21` include an open redirect vulnerability. Hits to the path `//example.com/foo/bar/` (the trailing slash is required) will redirect the user to `https://example.com/foo/bar`. Patches This problem has been patched in both Datasette `0.65.2` and `1.0a21`. Workarounds If Datasette is running behind a proxy that proxy could be configured to replace `//` with `/` in incoming request URLs.
Recommended action: Upgrade to 1.0a21 (pre-release) or 0.65.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This bug affects Datasette instances running a Datasette 1.0 alpha - 1.0a0, 1.0a1, 1.0a2 or 1.0a3 - in an online accessible location but with authentication enabled using a plugin such as datasette-auth-passwords. The /-/api API explorer endpoint could reveal the names of both databases and tables - but not their contents - to an unauthenticated user. Patches Datasette 1.0a4 has a fix for this issue. Workarounds To work around this issue, block all traffic to the /-/api endpoint. This can be done with a proxy such as Apache or NGINX, or by installing the datasette-block plugin and adding the following configuration to your metadata.json or metadata.yml file: This will block access to the API explorer but will still allow access to the Datasette read or write JSON APIs, as those use different URL patterns within the Datasette /database hierarchy.
Recommended action: Upgrade to 1.0a4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The `?_trace=1` debugging feature in Datasette does not correctly escape generated HTML, resulting in a reflected cross-site scripting vulnerability. This vulnerability is particularly relevant if your Datasette installation includes authenticated features using plugins such as datasette-auth-passwords as an attacker could use the vulnerability to access protected data. Patches Datasette 0.57 and 0.56.1 both include patches for this issue. Workarounds If you run Datasette behind a proxy you can workaround this issue by rejecting any incoming requests with `?_trace=` or `&_trace=` in their query string parameters. References - OWASP guide to reflected cross-site scripting - Datasette issue #1360 For more…
Recommended action: Upgrade to 0.56.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The HTML form for a read-only canned query includes the hidden CSRF token field added in #798 for writable canned queries (#698). This means that submitting those read-only forms exposes the CSRF token in the URL - for example on https://latest.datasette.io/fixtures/neighborhoodsearch submitting the form took me to: https://latest.datasette.io/fixtures/neighborhoodsearch?text=down&csrftoken=CSRFTOKEN-HERE This token could potentially leak to an attacker if the resulting page has a link to an external site on it and the user clicks the link, since the token would be exposed in the referral logs. Patches A fix for this issue has been released in Datasette 0.46. Workarounds You can fix this issue in a Datasette instance without upgrading by copying the 0.46 query.html template into a custom templates/ directory and running Datasette with the --template-dir=templates/ option. References Issue 918 discusses this in details: https://github.com/simonw/datasette/issues/918 For more…
Recommended action: Upgrade to 0.46 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.