This is already better but I would think about using an already well-tested and known package for the role of detecting the actual mime type instead of reinventing the weel...

After a quick search I found the following to be the most appetizing options (always imo):

• Pillow: probably overkill, since we would only use the verify method (the transpose too if we want to be fancy)
• filetype: also uses magic bytes to detect the actual file type but is more structured and allows passing a stream (such as an online resource) since it only needs the first bytes anyway.

These were just 2 cents, since I hate having to maintain something that someone already worked hard to do and it is for sure more tested and used than my version... 😄

@sinaatalay what do you think?

It is for sure lighter to just add the code rather than using an external package, but maybe for the future it is better to use a package and just focus on using the result instead of the implementation.

Hi @sinaatalay,

How would you like to proceed here?

@alpernae in the meantime can you pls fix the failing test?

This way @sinaatalay would have everything ready

@LukeSavefrogs All issues should be fixed now.

Thank you. Could you provide an example of how a bad actor might exploit this vulnerability, and what the consequences would be?

Hi @sinaatalay,

A security policy with a supported versions table helps users clearly understand which releases address known vulnerabilities (such as the local file exposure issue) and when they should upgrade. This is especially important for a CLI tool, where users may not update automatically.

From a project perspective, documenting your security process demonstrates a good-faith effort to handle vulnerabilities responsibly. It can also reduce legal risk and minimize noise from duplicate or scattered reports. A clear policy directs researchers to the appropriate reporting channel instead of having security concerns posted publicly.

Most importantly, when users evaluate RenderCV, seeing an active security policy signals competence and care—particularly when there is a known file exposure issue on record. The policy itself doesn’t fix the vulnerability, but it gives you control over how issues are reported, handled, and communicated.

considering that RenderCV is a CLI application without network access?

Being a CLI application doesn’t eliminate risk. Since the project is open source, anyone can download and use it publicly or integrate it into internal services (for example, allowing users to generate CVs). In such scenarios, if user input is not properly validated, a malicious actor could supply a crafted file path. If they also have access to directories containing generated CVs or related files, this could potentially lead to unintended file exposure.