1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
|
<!DOCTYPE html>
<html><head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<link href="sqlite.css" rel="stylesheet">
<title>Vulnerabilities</title>
<!-- path= -->
</head>
<body>
<div class=nosearch>
<a href="index.html">
<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
</a>
<div><!-- IE hack to prevent disappearing logo --></div>
<div class="tagline desktoponly">
Small. Fast. Reliable.<br>Choose any three.
</div>
<div class="menu mainmenu">
<ul>
<li><a href="index.html">Home</a>
<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
<li class='wideonly'><a href='about.html'>About</a>
<li class='desktoponly'><a href="docs.html">Documentation</a>
<li class='desktoponly'><a href="download.html">Download</a>
<li class='wideonly'><a href='copyright.html'>License</a>
<li class='desktoponly'><a href="support.html">Support</a>
<li class='desktoponly'><a href="prosupport.html">Purchase</a>
<li class='search' id='search_menubutton'>
<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
</ul>
</div>
<div class="menu submenu" id="submenu">
<ul>
<li><a href='about.html'>About</a>
<li><a href='docs.html'>Documentation</a>
<li><a href='download.html'>Download</a>
<li><a href='support.html'>Support</a>
<li><a href='prosupport.html'>Purchase</a>
</ul>
</div>
<div class="searchmenu" id="searchmenu">
<form method="GET" action="search">
<select name="s" id="searchtype">
<option value="d">Search Documentation</option>
<option value="c">Search Changelog</option>
</select>
<input type="text" name="q" id="searchbox" value="">
<input type="submit" value="Go">
</form>
</div>
</div>
<script>
function toggle_div(nm) {
var w = document.getElementById(nm);
if( w.style.display=="block" ){
w.style.display = "none";
}else{
w.style.display = "block";
}
}
function toggle_search() {
var w = document.getElementById("searchmenu");
if( w.style.display=="block" ){
w.style.display = "none";
} else {
w.style.display = "block";
setTimeout(function(){
document.getElementById("searchbox").focus()
}, 30);
}
}
function div_off(nm){document.getElementById(nm).style.display="none";}
window.onbeforeunload = function(e){div_off("submenu");}
/* Disable the Search feature if we are not operating from CGI, since */
/* Search is accomplished using CGI and will not work without it. */
if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
document.getElementById("search_menubutton").style.display = "none";
}
/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
function hideorshow(btn,obj){
var x = document.getElementById(obj);
var b = document.getElementById(btn);
if( x.style.display!='none' ){
x.style.display = 'none';
b.innerHTML='show';
}else{
x.style.display = '';
b.innerHTML='hide';
}
return false;
}
var antiRobot = 0;
function antiRobotGo(){
if( antiRobot!=3 ) return;
antiRobot = 7;
var j = document.getElementById("mtimelink");
if(j && j.hasAttribute("data-href")) j.href=j.getAttribute("data-href");
}
function antiRobotDefense(){
document.body.onmousedown=function(){
antiRobot |= 2;
antiRobotGo();
document.body.onmousedown=null;
}
document.body.onmousemove=function(){
antiRobot |= 2;
antiRobotGo();
document.body.onmousemove=null;
}
setTimeout(function(){
antiRobot |= 1;
antiRobotGo();
}, 100)
antiRobotGo();
}
antiRobotDefense();
</script>
<div class=fancy>
<div class=nosearch>
<div class="fancy_title">
Vulnerabilities
</div>
<div class="fancy_toc">
<a onclick="toggle_toc()">
<span class="fancy_toc_mark" id="toc_mk">►</span>
Table Of Contents
</a>
<div id="toc_sub"><div class="fancy-toc1"><a href="#executive_summary">1. Executive Summary</a></div>
<div class="fancy-toc1"><a href="#about_cves">2. About CVEs</a></div>
<div class="fancy-toc2"><a href="#a_separate_sql_injection_vulnerability_is_usually_required">2.1. A separate SQL injection vulnerability is usually required</a></div>
<div class="fancy-toc2"><a href="#defense_against_dark_arts">2.2. Defense Against Dark Arts</a></div>
<div class="fancy-toc2"><a href="#the_sqlite_developer_policy_toward_cves">2.3. The SQLite Developer Policy Toward CVEs</a></div>
<div class="fancy-toc1"><a href="#status_of_recent_sqlite_cves">3. Status Of Recent SQLite CVEs</a></div>
</div>
</div>
<script>
function toggle_toc(){
var sub = document.getElementById("toc_sub")
var mk = document.getElementById("toc_mk")
if( sub.style.display!="block" ){
sub.style.display = "block";
mk.innerHTML = "▼";
} else {
sub.style.display = "none";
mk.innerHTML = "►";
}
}
</script>
</div>
<h1 id="executive_summary"><span>1. </span>Executive Summary</h1>
<ul>
<li><p>
CVEs about SQLite probably do not apply to your use of SQLite.
</p></li><li><p>
All historical vulnerabilities reported against SQLite require at least
one of these preconditions:
</p><ol type="1">
<li><p>
The attacker can submit and run arbitrary SQL statements.
</p></li><li><p>
The attacker can submit a maliciously crafted database file to the
application that the application will then open and query.
</p></li></ol>
</li><li><p>
Few real-world applications meet either of these preconditions, and hence
few real-world applications are vulnerable, even if they use older
and unpatched versions of SQLite.
</p></li><li><p>
The SQLite development team fixes bugs promptly,
usually within hours of discovery. New releases of SQLite
are issued if the bug seems likely to impact real-world
applications.
</p></li><li><p>
Grey-hat hackers are rewarded based on the number and severity of
CVEs that they write. This results in a proliferation of CVEs that
have minor impact, or no impact at all, but which make
exaggerated impact claims.
</p></li><li><p><a name="notnew"></a>
Very few CVEs written about SQLite are real vulnerabilities in the
sense that they do not give any new capabilities to an attacker.
Consider:
</p><ol type="a">
<li><p>
Almost all CVEs written against SQLite require the ability to
inject and run arbitrary SQL.
</p></li><li><p>
The advertised consequence of most CVEs is "denial of service",
typically by causing a crash through a NULL pointer dereference or
a division by zero, or similar.
</p></li><li><p>
But if an attacker can already run
arbitrary SQL, they do not need a bug to cause a denial of service.
There are plenty of perfectly legal and valid SQL statements
that will consume unlimited CPU, memory, and disk I/O in order
to create a denial-of-service without requiring help from bugs.
</p></li><li><p>
Hence, the mere fact that an attacker has a way to inject and run
arbitrary SQL is in and of itself a denial-of-service attack. That
the arbitrary SQL might also tickle a bug in SQLite and cause a
crash is not a new vulnerability.
</p></li></ol>
</li><li><p>
The SQLite developers do not write CVEs. Any CVEs you find on
SQLite are generated by third-parties, often without any input from the
core developers. A common scenario is that someone will report a bug in
SQLite, which will promptly be fixed, then weeks later a CVE for that bug will
appear, unbeknownst to the developers.
</p></li><li><p>
You should not assume that a CVE about
SQLite contains authoritative information.
CVEs often contain inaccuracies.
The SQLite developers have attempted to add clarifications and
corrections to CVEs about SQLite.
</p></li></ul>
<h1 id="about_cves"><span>2. </span>About CVEs</h1>
<p>CVEs ("Common Vulnerabilities and Exposures") are reports of software
bugs that might allow a system to be hacked. The idea
behind CVEs is sound. They provide a common naming scheme whereby
software bugs that might compromise information security can be easily
tracked.
</p><p>While the original idea being CVEs is sound, the current processes for
creating and managing CVEs are inadequate. There are countless grey-hat
hackers running fuzzers against a wide-variety of open-source software
products (SQLite as well as many others) and writing up CVEs against
any problems they find. The grey-hats are rewarded, sometimes with
prestige and sometimes financially, by the number and severity of
the CVEs they write. This incentive results in a proliferation
of CVEs which are often not well-vetted and which can have exaggerated
impact claims. The quality-control procedures for CVEs are unable
to cope with this flood of inputs, making it difficult to correct
exaggerated, misleading, omitted, or inaccurate claims.
</p><p>This is not to say that CVEs are useless. CVEs do still (mostly)
report actual bugs. But in most cases the bugs are not true vulnerabilities,
in the sense that they do not contribute to data loss or compromise
in and of themselves.
It is good that bugs are reported and fixed. But not every bug is
accessible from every application. In the case of SQLite, most of the
bugs reported by CVEs are inaccessible in most applications. Upgrading
to the latest version of SQLite is always a good plan, but it need not
be an emergency just because an anonymous grey-hat on the internet
wrote up a CVE.
</p><h2 id="a_separate_sql_injection_vulnerability_is_usually_required"><span>2.1. </span>A separate SQL injection vulnerability is usually required</h2>
<p>
Other C-libraries that process complex structured inputs will
routinely be asked to deal with unvetted inputs from untrusted
sources. Libraries like libjpeg, or libzip, or OpenSSL are
handed input streams that come directly from potentially hostile
agents.
</p><p>
But database engines like SQLite are usually not this way.
The SQL scripts that are passed into SQLite come from the
(trusted) application itself, not from an attacker. Sometimes
applications contain bugs by which an external attacker can
trick the application into sending SQL of the attackers design
into the database engine. This is a separate bug in the
application called an
<a href="https://en.wikipedia.org/wiki/SQL_injection">SQL Injection
vulnerability</a>. Since SQL text is executable code, an
SQL Injection vulnerability is actually a special case of a
<a href="https://en.wikipedia.org/wiki/Arbitrary_code_execution">Remote
Code Execution (RCE) vulnerability</a>. An SQL Injection is perhaps not
quite as bad as other kinds of RCEs because,
while SQL is a powerful language, it is not as convenient
for crafting an exploit as Python or shell script or raw machine code.
Nevertheless, an SQL Injection is a serious problem.
</p><p>
Most CVEs written about SQLite assume that the attacker is
able to run arbitrary SQL scripts in SQLite. In most applications,
this means that there must first be an SQL Injection vulnerability
that allows the attacker to inject the malicious SQL.
</p><p>
A few applications do allow untrusted SQL scripts received from
potentially hostile agents to be run direct in SQLite. The main
example of this is the Chrome and Safari web browsers, which allow
an anonymous web page to run SQL using the WebSQL feature of Javascript.
This is done inside a sandbox with tightly controlled constraints on
resources, lest the SQL script try to soak up all available memory
or CPU cycles in a denial-of-service attack. Chrome and Safari
have the infrastructure in place to allow a hostile agent to run
code which does not harm or compromise the rest of the machine.
They have to, as they also run Javascript which could, if not
tightly controlled, do even more damage than unrestrained SQL.
Apart from Chrome and Safari, no applications known to the
SQLite developers deliberately allows an anonymous remote agent
to run arbitrary SQL text.
</p><p>However, most CVEs written against SQLite flippantly assume
that an attacker is free to run any arbitrary SQL in the database
engine. So to a good approximation, this means most CVEs
written against SQLite really only apply to SQLite as it is
used in Chrome and Safari. Or, in other words, most CVEs
for SQLite do not apply to you unless you are one of the
developers of Chrome or Safari.
</p><h2 id="defense_against_dark_arts"><span>2.2. </span>Defense Against Dark Arts</h2>
<p>
Most applications can use SQLite without having to worry about
bugs in obscure SQL inputs. If the application controls
the SQL, and the application is not deliberately trying to break
SQLite, then everything should just work.
It is not necessary to have the latest patched version of SQLite.
Any older version should work just fine.
</p><p>
However, there are some occasions where an application does need
to be able to safely run untrusted SQL. The SQLite developers work hard
to make SQLite safe for this purpose, though there are occasional
slip-ups. It is good to keep up-to-date with the latest patches
in this case. The separate <a href="security.html">defense against dark arts</a> document
contains additional suggestions that can help prevent zero-day
attacks in cases where SQLite is given inputs that come directly
from untrusted sources.
</p><h2 id="the_sqlite_developer_policy_toward_cves"><span>2.3. </span>The SQLite Developer Policy Toward CVEs</h2>
<p>SQLite developers fix all bugs in SQLite as soon as they are reported,
usually within a few hours. The fixes are immediately available on the
<a href="https://sqlite.org/src/timeline">public SQLite source tree</a>.
If a bug seems like it might cause problems for existing applications,
a new patch release for SQLite will be issued.
</p><p>However, the SQLite developers do not track CVEs. There are
various reasons for this:
</p><ol>
<li><p>
The developers often do not find out about CVEs until long after the
bug is fixed. You can see this by the fact that many CVEs reference the
bug fix in their initial report.
</p></li><li><p>
CVEs are a low-quality source of information about bugs in SQLite
that are likely to affect most applications.
</p></li><li><p>
Almost all bugs reported by CVEs are just bugs and not
true vulnerabilities. Claiming that they are vulnerabilities is
stretching the meaning of the word "vulnerability" and the SQLite
developers do not wish to participate in that deception.
</p></li><li><p>
The developers have no editorial influence on the content of CVEs,
and they do not like to be controlled by groups in which they have
no voice.
</p></li></ol>
<a name="cvetab"></a>
<h1 id="status_of_recent_sqlite_cves"><span>3. </span>Status Of Recent SQLite CVEs</h1>
<p>Though the SQLite developers do not consider CVEs to be a reliable
source of information about bugs in SQLite, they recognize that many
groups, and especially small teams working at the bottom of tall
bureaucracies, sometimes need to track CVEs, whether they are useful
or not. To aid in this chore, the following table of recent CVEs
affecting SQLite is provided.
</p><p>If you notice new CVEs associated with SQLite that are not in
the table below, please bring them to the attention of the developers
on the <a href="https://sqlite.org/forum/about">SQLite Forum</a> so they can
be added.
</p><table border="1" cellpadding="5" cellspacing="0" style="margin-left:5ex;">
<thead>
<tr>
<th valign="bottom">CVE Number</th>
<th valign="bottom">Fix</th>
<th valign="bottom">Comments</th>
</tr>
</thead>
<tbody>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2022-46908'>CVE-2022-46908</a>
</td>
<td valign='top'>Bug not in the SQLite library</td>
<td valign='top'>This is a bug in the --safe command-line option of the <a href="cli.html">command-line shell</a>
program that is available for accessing SQLite database files. The bug does
not exist in the SQLite library. Nor is it an issue for the <a href="cli.html">CLI</a> as long as
the user does not depend on the --safe option. It is not serious. It is
debatable whether or not this is a security issue.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2022-35737'>CVE-2022-35737</a>
</td>
<td valign='top'><a href="releaselog/3_39_2.html">3.39.2</a><br>(2022-07-21)</td>
<td valign='top'>This bug is an array-bounds overflow. The bug is only accessible when using some
of the C-language APIs provided by SQLite. The bug cannot be reached using SQL
nor can it be reached by providing SQLite with a corrupt database file.
The bug only comes up when very long string inputs (greater than 2 billion bytes
in length) are provided as arguments to a few specific C-language interfaces,
and even then only under special circumstances.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2022-24854'>CVE-2022-24854</a>
</td>
<td valign='top'>Not a bug</td>
<td valign='top'>This CVE describes a bug in an application that uses SQLite, not in SQLite itself.
SQLite is doing everything correctly. The application grants users the ability to
run SQL statements, using SQLite, that can leak or change information that those users
should not normally have access to. This is purely an application bug. It does not
describe a malfunction or vulnerability in SQLite.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2022-21227'>CVE-2022-21227</a>
</td>
<td valign='top'>Not a bug</td>
<td valign='top'>This CVE describes a bug in a third-party packages that provides a binding
for SQLite to Node.js. The bug reported is in the third-party Node.js binding,
not in SQLite itself. Do not be confused by the use of the word "SQLite" in the
ambiguously-worded CVE description.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-45346'>CVE-2021-45346</a>
</td>
<td valign='top'>Not a bug</td>
<td valign='top'>This CVE is misinformation. See the discussion around
<a href="https://sqlite.org/forum/forumpost/53de8864ba114bf6">SQLite forum post 53de8864ba114bf</a>.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-42169'>CVE-2021-42169</a>
</td>
<td valign='top'>Not a bug</td>
<td valign='top'>This CVE has nothing whatsoever to do with SQLite. It is about a bug in
application that happens to use SQLite. Since SQLite is mentioned in the
CVE description, the CVE is included here to emphasize that
this is not an SQLite bug.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-36690'>CVE-2021-36690</a>
</td>
<td valign='top'>Bug not in the SQLite library</td>
<td valign='top'>This bug is not in the SQLite core library, but rather in an
<a href="http://www.sqlite.org/src/dir?ci=trunk&name=ext/expert">
experimental extension</a> that is used to implement the
<a href="cli.html#expert">.expert command</a> in the <a href="cli.html">CLI</a>. The code that contains the bug
does not appear in <a href="amalgamation.html">standard SQLite builds</a>, though it
is included in the <a href="cli.html">sqlite3.exe command-line tool</a>.
Applications must link against the extra source code files that
implement the extension and take other deliberate actions to
activate the extension before the troublesome code can be run.
For the rare application that uses the troublesome extension,
the consequence of this bug is that malicious SQL can cause a
NULL pointer deference and denial of service.
<a href='https://sqlite.org/forum/info/78165fa25061742f'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-28305'>CVE-2021-28305</a>
</td>
<td valign='top'>Not a bug</td>
<td valign='top'>This is not a bug in SQLite. The bug is in a third-party application that
uses SQLite. SQLite is mentioned by name in the CVE description,
however, so we have included the CVE in the list.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-23404'>CVE-2021-23404</a>
</td>
<td valign='top'>Not a bug</td>
<td valign='top'>This is not a bug in SQLite. The bug is in a third-party application that
uses SQLite and includes "sqlite" in its name. This CVE is included on the
list because it mentions SQLite even though the bug has nothing to do
with SQLite.</td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-20227'>CVE-2021-20227</a>
</td>
<td valign='top'><a href="releaselog/3_34_1.html">3.34.1</a><br>(2021-01-20)</td>
<td valign='top'>Malicious SQL statement causes read-after-free. No harm can come of this
particular read-after-free instance, as far as anyone knows. The bug is
undetectable without a memory sanitizer. The CVE
claims that this bug is an RCE - a Remote Code Execution
vulnerability, but that claim is incorrect.
The RCE claim is misinformation.
<a href='https://sqlite.org/src/info/30a4c323650cc949'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2021-20223'>CVE-2021-20223</a>
</td>
<td valign='top'><a href="releaselog/3_34_0.html">3.34.0</a><br>(2020-12-01)</td>
<td valign='top'>The problem identified by this CVE is <u>not</u> a vulnerability.
It is a malfunction. A coding error causes <a href="fts5.html">FTS5</a>
to sometimes return inconsistent and incorrect results under obscure circumstances,
but no memory errors occur.
<a href='https://sqlite.org/src/info/b7b7bde9b7a03665'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-15358'>CVE-2020-15358</a>
</td>
<td valign='top'><a href="releaselog/3_32_3.html">3.32.3</a><br>(2020-06-18)</td>
<td valign='top'>Malicious SQL statement causes an read past the end of a heap buffer.
<a href='https://sqlite.org/src/info/8f157e8010b22af0'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13871'>CVE-2020-13871</a>
</td>
<td valign='top'><a href="releaselog/3_32_3.html">3.32.3</a><br>(2020-06-18)</td>
<td valign='top'>Malicious SQL statement causes a read-only use-after-free memory error.
<a href='https://sqlite.org/src/info/c8d3b9f0a750a529'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13632'>CVE-2020-13632</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read of a NULL pointer in the
<a href="fts3.html#matchinfo">matchinfo()</a> SQL function of the <a href="fts3.html">FTS3</a> extension, resulting in
denial of service.
<a href='https://sqlite.org/src/info/a4dd148928ea65bd'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13631'>CVE-2020-13631</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement (an ALTER TABLE that tries to rename a
<a href="vtab.html">virtual table</a> into one of its own <a href="vtab.html#xshadowname">shadow tables</a>)
causes an infinite loop and denial of service.
<a href='https://sqlite.org/src/info/eca0ba2cf4c0fdf7'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13630'>CVE-2020-13630</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read-only use-after-free,
possibly resulting in a incorrect output from the <a href="fts3.html#snippet">snippet()</a>
SQL function of the <a href="fts3.html">FTS3</a> extension. There is no known
way to exfiltrate data or crash the application using this bug.
<a href='https://sqlite.org/src/info/0d69f76f0865f962'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13435'>CVE-2020-13435</a>
</td>
<td valign='top'><a href="releaselog/3_32_1.html">3.32.1</a><br>(2020-05-25)</td>
<td valign='top'>Malicious SQL statement causes a read access to a NULL pointer and
denial of service.
<a href='https://www.sqlite.org/src/info/7a5279a25c57adf1'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-13434'>CVE-2020-13434</a>
</td>
<td valign='top'><a href="releaselog/3_32_1.html">3.32.1</a><br>(2020-05-25)</td>
<td valign='top'>Malicious SQL statement involving the printf() SQL function results
in an integer overflow which can overwrite the stack with over 2
billion bytes of 0x30 or 0x20 (ASCII '0' or ' ').
Even though this is a stack overwrite, there is no known way to
redirect control or otherwise escalate the level of harm.
This is a denial-of-service attack only.
<a href='https://www.sqlite.org/src/info/23439ea582241138'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-11656'>CVE-2020-11656</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes read-only use-after-free of memory allocation
if SQLite is compile with -DSQLITE_DEBUG. Does not affect release
builds.
<a href='https://www.sqlite.org/src/info/4722bdab08cb1'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-11655'>CVE-2020-11655</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read using an uninitialized pointer
and denial-of-service.
<a href='https://www.sqlite.org/src/info/af4556bb5c285c08'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-9327'>CVE-2020-9327</a>
</td>
<td valign='top'><a href="releaselog/3_32_0.html">3.32.0</a><br>(2020-05-22)</td>
<td valign='top'>Malicious SQL statement causes a read using an uninitialized pointer
and denial-of-service
<a href='https://www.sqlite.org/src/info/4374860b29383380'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2020-6405'>CVE-2020-6405</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference and
denial-of-service
<a href='https://www.sqlite.org/src/info/1bc783da63d58b05'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-20218'>CVE-2019-20218</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes an uninitialized pointer read and
denial-of-service.
<a href='https://www.sqlite.org/src/timeline?r=better-error-handling-1'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19959'>CVE-2019-19959</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference
in the <a href="zipfile.html">Zipfile virtual table</a> extension and
denial-of-service. This is only possible when the optional
<a href="zipfile.html">Zipfile virtual table</a> extension is deployed, which is not
the case in default builds.
<a href='https://www.sqlite.org/src/info/cc0fb00a128fd077'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19926'>CVE-2019-19926</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes an uninitialized pointer read and
denial-of-service.
<a href='https://www.sqlite.org/src/info/cba2a2a44cdf138a'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19925'>CVE-2019-19925</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference and
in the <a href="zipfile.html">Zipfile virtual table</a> extension and
denial-of-service. This is only possible when the optional
<a href="zipfile.html">Zipfile virtual table</a> extension is deployed, which is not
the case in default builds.
<a href='https://www.sqlite.org/src/info/a80f84b511231204'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19924'>CVE-2019-19924</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a uninitialized pointer reference and
denial-of-service.
<a href='https://www.sqlite.org/src/info/e2bddcd4c55ba3cb'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19923'>CVE-2019-19923</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>Malicious SQL statement causes a NULL pointer dereference and
denial-of-service.
<a href='https://www.sqlite.org/src/info/862974312edf00e9'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19646'>CVE-2019-19646</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>The <a href="pragma.html#pragma_integrity_check">PRAGMA integrity_check</a> command might cause the byte-code for a prepared
statement to loop indefinitely. This might enable a denial-of-service, if the
application has not taken appropriate and prudent steps
to limit the run-time of SQL statements. This is not a vulnerability, as there
are countless perfectly valid SQL queries, especially queries involving
<a href="lang_with.html#recursivecte">recursive common table expressions</a>, that also run essentially forever.
<a href='https://sqlite.org/src/info/bd8c280671ba44a7'>(details)</a></td>
</tr>
<tr><td valign='top'>
<a href='https://nvd.nist.gov/vuln/detail/CVE-2019-19317'>CVE-2019-19317</a>
</td>
<td valign='top'><a href="releaselog/3_31_0.html">3.31.0</a><br>(2020-01-22)</td>
<td valign='top'>This CVE identifies a bug in a development check-in of
SQLite. The bug never appeared in any official SQLite release.
<a href='https://www.sqlite.org/src/info/6601da58032d18ae'>(details)</a></td>
</tr>
</tbody>
</table>
<p align="center"><small><i>This page last modified on <a href="https://sqlite.org/docsrc/honeypot" id="mtimelink" data-href="https://sqlite.org/docsrc/finfo/pages/cves.in?m=62f06b3313c11e780">2022-12-14 16:29:06</a> UTC </small></i></p>
|
