Is Pydantic as safe as it is popular?

complexity of application security testing

If you want to keep complexity low and minimize security risks, you always need to decide whether using an external Python library is the right choice.

Practising 0Complexity design principles is never easy. But when it comes to security and minimising dependencies, you should weigh the advantages and disadvantages of using any external Python library.

Don’t get me wrong: many FOSS Python libraries are excellent, well-maintained software and you’d be foolish not to use them when appropriate.

So before using a new module in an MVP, running a quick and simple Static Application Security Test (SAST) on the external Python module will provide valuable information from a security point of view.

A Quick Look Through a Security Lens.

Pydantic is a widely used data validation library in the Python ecosystem. So if you’re tackling complex data validation in your Python application, why not reach for Pydantic? After all, it was designed with a clear focus: defining and validating data models.

And it’s clearly popular. Just look at the PyPI download stats (as of July 28, 2025):

• Downloads in the last day: 8,526,478

• Downloads in the last week: 88,457,411

• Downloads in the last month: 366,887,849

Those numbers are massive. Combine that with thousands of blog posts, widespread adoption, and serious funding behind the Pydantic company—and it’s easy to assume it must be the best choice.

But are we seeing real value, or are we falling for a well executed marketing wave?

A good question is: What are possible security risks when using this module in a project? Some random hackers in the world must have tested this module and declared it secure? Or not? Has it really been tested by independent security researchers or are we just assuming it’s safe because everyone is using it?

Trust is good. But verifying is better. Why not run your own simple Static Application Security Test (SAST) on Pydantic—and see what you find?

The number of good Python SAST scanners is limited. Some are complex, outdated, or take more than five minutes to install—and require significant time just to figure out how to run a simple test. So I prefer to use a solid simple Python Static Application Security Test (SAST) tool.

I’ll use Python Code Audit. This is a FOSS tool (GPL licensed) with code on Github that can be installed using pip.

So install this tool by:

Now you are ready to run a SAST test on the Pydantic code.

To run the test yourself:

1. Clone the Pydantic repository on a local file system. So do in e.g. a ../tmp directory: git clone https://github.com/pydantic/pydantic.git

2. Next run first an overview on all Pydantic code. So run codeaudit overview on the directory where the cloned repository is created. Assuming you used some /tmp to clone the repository, than you can do from within this /tmp directory:

This will give this a html-report that looks like:

3. Next step is of course to find out if what files have Python constructs that you should be aware of. So do a

This will show per file the potential issues found.

The result shown will look like:

For more confidence on imported modules check the overview report and do a scan on files that use many (external)modules or have a high complexity score.

Pydantic uses some constructs that I think you should be aware of. But since the context is key for security, you must understand the consequences when using Pydantic for your specific use-case!

Using Python Code Audit provides a fast, direct and clear overview of potential security issues.

Pydantic has had some security issues in the past. Well-known examples include: CVE-2021-29510, CVE-2023-30510, and CVE-2024-3772.

Some observations from a simple Static Application Security Test (SAST) performed on the Pydantic codebase:

• assert statements are used in many places. This is not always the best way for validation from a security perspective.

• pass and continue statements are used. This can be a potential security risks due to its overly broad exception handling and silent failure options.

• eval statement is used. This can be risky, as it allows execution of arbitrary code.

• pickle.loads statement is used. This should not be a potential issue. But history learns us why avoiding this prevents issues.

Overall, the Pydantic developers have created an excellent software module with minimal external dependencies. However, from a security standpoint, it’s worth noting the relatively high complexity and large codebase size. Complex codebases are generally harder to maintain and audit, which increases potential security risks over time.

Keep in mind:this was only a quick scan of security aspects of the Pydantic codebase. A thorough security audit requires more extensive checks. Not only on the code, like applying fuzzing testing, but also on the governance processes that are used to keep risks for users of the software minimised.