>The specific attack, foreclosed in many cases [a] by the "Features Recently Added to SQLite To Help Avoid This Attack" outlined in post 2 above by said expert My main question was are those features enabled (well disabled) by default in SQLite out of the box 3.32.1 installations, and if not can I do so at runtime in any version of Python. The answer seems to be no for both. I/we have no idea how to implement section 1.2 #8 and #9 (especially 9) of this page https://www.sqlite.org/security.html so the service will be disabled until such time that he/we figures it out. The entire service is just running open source Python scripts on user provided databases so the user doesn't have to install tools to do so. I apologize that this may seem repetitive but the comments on Hacker News from yesterday seem to agree that in some cases like this one, simply running a known SELECT statement on untrusted data can be exploited without those mitigations in the linked page and without any special custom functions created/used by the open source application. In the video, the guy seems to create his own VIEWs and store them within the database. But then you go on to say: >If you look at that video, you can see that there is more to the attack than merely running a SELECT known ahead of time to the attacker. The "more" is to have arranged for that query to actually resolve to evaluation of a malicious (and so necessarily custom) function (or, by logical extension, arbitrary code loaded via the extension mechanism.) That is why Richard added qualification regarding custom functions or virtual tables. Without those possibilities, which are under the application's control, recent versions of SQLite foreclose the form of attack described in that video (and well summarized in Richard's post 2 in this thread.) Which makes me think a default out of the box version of SQLite would not be vulnerable in my described case.