This appears to have been introduced with 3.48.0. From the amalgamation's shell.c:

char *sqlite3_fgets(char *buf, int sz, FILE *in){
  if( UseWtextForInput(in) ){
    /* When reading from the command-prompt in Windows, it is necessary
    ** to use _O_WTEXT input mode to read UTF-16 characters, then translate
    ** that into UTF-8.  Otherwise, non-ASCII characters all get translated
    ** into '?'.
    */
    wchar_t *b1 = sqlite3_malloc( sz*sizeof(wchar_t) );
    if( b1==0 ) return 0;
#ifndef SQLITE_USE_STDIO_FOR_CONSOLE
    DWORD nRead = 0;
    if( IsConsole(in)
     && ReadConsoleW(GetStdHandle(STD_INPUT_HANDLE), b1, sz, &nRead, 0)
    ){
      b1[nRead] = 0;

If SQLITE_USE_STDIO_FOR_CONSOLE is not set, and ReadConsoleW has at least sz bytes available to read into b1, then nRead == sz, which means the call to add a null character will go beyond the end of b1.

This crashes a debug version of shell for me when sqlite3_free is eventually called since malloc's guard cookie is no longer valid. Perhaps not the preferred fix, but at least locally, I've fixed it to unblock myself by subtracting one byte from the ReadConsoleW call here so the buffer overflow doesn't happen and the later call to WideCharToMultiByte also null terminates the string.