It has always been the position of the CPython developers that using python for sandboxing is unsupported. With that in mind it doesn't really matter if you can "exploit" python with weird bytecode because you are supposed to be on the other side of the airtight hatchway[0] anyways.

I don't know what the stance of other python runtimes are, but you should probably just use a sandbox at OS level which is likely to be tested far more thoroughly.

[0]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

It's worth mentioning the interesting failure of pysandbox:

> I now think that putting a sandbox directly in Python cannot be secure. To build a secure sandbox, the whole Python process must be put in an external sandbox.

https://mail.python.org/pipermail/python-dev/2013-November/1...

Comments for that link:

https://web.archive.org/web/20190113115213/https://blogs.msd...

I did this a while back: https://tomforb.es/segfaulting-python-with-afl-fuzz/

CPython bytecode will segfault Python if it’s slightly incorrect. And that’s fine, it’s not a security risk and it’s not worth the performance overhead of validating wonky bytecode.

You don't need a fuzzer. Python doesn't do bounds checking of stack manipulation. This is not considered a bug

I think people have, but it's not clear that searching for bugs by perverse input is a great use of time. Maybe better to focus on solving currently known issues.