This bug was reported against the Debian package but is an upstream issue:

It assumes lengths of data sets read from saved game files. It copies data from a file into a fixed-size heap-allocated buffer without size verification, leading to a heap-based buffer overflow.

This should be fixed, indeed.
Related issues : issue951, issue952 (how come we never commented those one ???)

But, however, if one tries to crash FDRPG with a malicious, I bet he will find thousands of way. Do we really have to protect against intentional corruptions ?

Well, if user A corrupts data and gets user B to load it and can through this access anything unrelated to FDRPG, then yes, it's a security issue.

Yes, but we do not have any support to 
transaction save files. I personally have 
a hard time when I need someone reporting 
a bug to upload their savegames (and that 
happens only when the file is already a 
"bad file", anyway).

People could try to get 100% completion 
savegames or have someone hack it; Both 
can be done more smartly by using the 
cheat menu or cheat level editor (it ought 
yo be more documented than savefiles, 
even), and are not something we encourage.

But then we have Murphy Law. If someone 
can do something the right way, OR by the 
wrong way, someone WILL do it the wrong 
way.

I would not call this critical (and my 
initial proposal for a quick patch would 
be a banner  informing to never load a 
savegame from internet).

We also have that updating to fix this 
would change savefiles compatibility, so I 
think unlikely to a proper, real fix being 
deployed for 1.0 or anytime soon. But I'm 
not a coder.

Also, there was something about safe and 
unsafe lua modes, I think that limiting 
lua to what we currently use would be the 
way to go but I know nothing about it. I 
might be talking nonsense here, this is 
why I split the post.

Fixed in commit e106cec2c
Lua sandboxing added