CVE-2025-68480: Unpatched marshmallow DoS vulnerability in safety 3.7.0

[1minds3t]

Checklist

• I agree to the terms within the Safety Code of Conduct.
• I have searched existing issues to ensure this bug hasn't been reported before.

Safety version

Summary

safety==3.7.0 (released Nov 6, 2024) includes a transitive dependency on marshmallow that is vulnerable to CVE-2025-68480. This creates an ironic situation where the security scanning tool itself ships with a known vulnerability.

Vulnerability Details

• CVE: [CVE-2025-68480](https://nvd.nist.gov/vuln/detail/CVE-2025-68480)
• Severity: Moderate (CVSS 5.3)
• Issue: DoS vulnerability in Schema.load(data, many=True) where moderately sized requests can consume disproportionate CPU time
• Affected versions: marshmallow >= 3.0.0rc1, < 3.26.2 and marshmallow >= 4.0.0, < 4.1.2
• Patched versions: marshmallow >= 3.26.2 or marshmallow >= 4.1.2

Validation Timeline

This vulnerability has been thoroughly validated through multiple independent reviews:

1. December 21, 2025: Marshmallow maintainers confirmed the vulnerability and released patches (3.26.2, 4.1.2)
2. December 22, 2025: GitHub Security Advisory Database reviewed and officially published GHSA-428g-f7cq-pgp5
3. December 22, 2025: Submitted to the National Vulnerability Database (NVD) as CVE-2025-68480

GitHub's security team doesn't submit vulnerabilities to the NVD without thorough review—this multi-stage validation confirms this is a genuine security issue, not a false positive. I've waited until after this official review process to file this issue out of respect for responsible disclosure timing.

Current Dependency Constraint

From [pyproject.toml](https://github.com/pyupio/safety/blob/main/pyproject.toml#L32):

"marshmallow>=3.15.0", # TODO: To be removed

This constraint allows installation of all vulnerable marshmallow versions from 3.15.0 up through 4.1.1 (including the entire vulnerable 4.0.x series).

Recommended Fix

Since the comment indicates marshmallow is planned for removal, you have two options:

Option 1 (if removal is imminent): Remove the marshmallow dependency entirely
Option 2 (if still needed): Update to require the patched version:

"marshmallow>=4.1.2",  # ✅ CVE-2025-68480 patched

Or if you need to maintain compatibility with the 3.x series:

"marshmallow>=3.26.2,!=4.0.*,!=4.1.0,!=4.1.1",  # ✅ Excludes vulnerable 4.0-4.1.1

Temporary Workaround

Users can override this by explicitly pinning marshmallow in their own dependencies:

"marshmallow>=4.1.2"  # Override safety's vulnerable transitive dependency
"safety>=3.7.0"

Pip's dependency resolver will install marshmallow>=4.1.2, satisfying both constraints.

Request

Could you please release a patch version (e.g., safety==3.7.1) with the updated marshmallow constraint—or better yet, remove it entirely if that TODO is ready to be addressed? This would help protect the broader Python ecosystem from this DoS vulnerability.

Additional Context

I previously reported a similar issue with authlib via email on November 23, 2025, and appreciate that safety 3.6.2 was released promptly afterward addressing that concern. Given your team's track record of responsive security maintenance, I'm confident you'll want to address this quickly as well.

Thank you for maintaining such an important security tool for the Python community!

References

• GitHub Advisory (Reviewed): GHSA-428g-f7cq-pgp5
• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2025-68480
• Marshmallow patch commit: marshmallow-code/marshmallow@d24a0c9

Python version

All versions (3.9-3.14 supported by safety 3.7.0)

Operating System

All operating systems (detected via automated dependency scanning tools like Dependabot)

Bug description

The security scanning tool safety itself contains a known security vulnerability in its transitive dependency marshmallow.

What I was trying to do:
Run routine security scans on my Python project using safety 3.7.0

What I expected to happen:
Safety would scan dependencies without itself containing known vulnerabilities

What actually happened:
Dependabot and security scanners flagged CVE-2025-68480 in marshmallow (a transitive dependency of safety 3.7.0), creating an ironic situation where the security tool itself has a vulnerability

Steps to reproduce

1. Install safety 3.7.0: pip install safety==3.7.0
2. Check transitive dependencies: pip show marshmallow
3. Observe that marshmallow version can be anywhere from 3.15.0 to 4.1.1 (including vulnerable versions)
4. Run any vulnerability scanner (Dependabot, Snyk, or even safety itself on a environment with marshmallow <4.1.2)
5. Observe CVE-2025-68480 flagged for marshmallow

Alternatively:

1. Check safety's dependency constraint in pyproject.toml
2. Note: "marshmallow>=3.15.0", # TODO: To be removed
3. This allows all vulnerable versions through 4.1.1

Command and output

$ pip install safety==3.7.0
# (installation output)

$ pip show marshmallow
Name: marshmallow
Version: 4.1.1  # or any version <4.1.2
# ... shows it was installed as dependency of safety

# When running security scanners:
# Dependabot Alert Example:
Transitive dependency marshmallow 4.1.1 is introduced via safety 3.7.0
CVE-2025-68480: Moderate severity DoS vulnerability in Schema.load(many=True)


---

**Additional context**

This vulnerability was officially validated through multiple independent reviews:

1. **December 21, 2025**: Marshmallow maintainers confirmed and patched (versions 3.26.2, 4.1.2)
2. **December 22, 2025**: GitHub Security Advisory Database officially published GHSA-428g-f7cq-pgp5
3. **December 22, 2025**: Submitted to National Vulnerability Database as CVE-2025-68480

**Recommended fix:**
Since your pyproject.toml already has `# TODO: To be removed` next to the marshmallow dependency, this might be a good opportunity to either:
- Remove the marshmallow dependency entirely (if that TODO is ready), OR
- Update to `"marshmallow>=4.1.2"` to exclude vulnerable versions

Additional context

I previously reported a similar authlib vulnerability via email (11/23/25), and safety 3.6.2 was released promptly afterward. Thank you for your responsive security maintenance!

References:

• GitHub Advisory (Reviewed): GHSA-428g-f7cq-pgp5
• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2025-68480
• Marshmallow patch: marshmallow-code/marshmallow@d24a0c9

[github-actions]

Hi @1minds3t, thank you for opening this issue!

We appreciate your effort in reporting this. Our team will review it and get back to you soon.
If you have any additional details or updates, feel free to add them to this issue.

Note: If this is a serious security issue that could impact the security of Safety CLI users, please email security@safetycli.com immediately.

Thank you for contributing to Safety CLI!

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• Safety check and marshmallow 4.0 > post_dump() got an unexpected keyword argument #740
• safety's own authlib dependency causes safety check failure #822
• Marshmallow 4.0.0 breaks safety check #716

🔗 Related PRs

#608 - fix/clarify-vulnerabilities-found/ [merged]
#612 - fix/safety error when scan is run without being authenticated [merged]
pyupio/platform#1054 - feat(pydantic): bump pydantic version to update safety schemas [merged]
pyupio/platform#1356 - fix: use explicit version specifier with pre-release spec for safety installation [merged]
pyupio/platform#1411 - feat: add parser and scanner for dependency vulnerability detection [merged]

👤 Suggested Assignees

• SafetyQuincyF
• mkb79
• fmigneault
• brabster
• davidlacho

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[yeisonvargasf]

Hi @1minds3t,

Thank you for this thorough and well-researched report! We really appreciate you taking the time to document the CVE details, timeline, and provide recommended fixes.

I wanted to share some context that should ease concerns about the practical impact on Safety users:

Safety CLI is not affected by this vulnerability

CVE-2025-68480 specifically targets Schema.load(data, many=True) — the deserialization path. Safety CLI only uses marshmallow for serialization (i.e., Schema.dump()) when exporting vulnerability reports to JSON. We never use .load() to process external input, so the DoS attack vector described in the CVE does not apply to Safety's usage of marshmallow.

Fresh installations already get the patched version

Since marshmallow 4.1.2 (the patched version) is now the latest release on PyPI, users running pip install safety today will have pip's dependency resolver pull in the patched version by default, as our constraint >=3.15.0 is satisfied by 4.1.2.

Why we're not restricting the version range

While pinning to >=4.1.2 might seem like the straightforward fix, it can cause unintended friction for a CLI tool like Safety:

• Installation conflicts: Users often run Safety within existing environments, where other packages depend on specific marshmallow versions. A strict lower bound could prevent Safety from being installed altogether, which would mean users miss out on vulnerability warnings for their actual at-risk dependencies. Note: We recommend scanning outside of the target environment using one of our binaries.

• Unnecessary upgrade pressure: Other packages in a user's environment may also depend on marshmallow without being affected by this CVE (e.g., if they only use .dump() or don't pass untrusted input to .load(many=True)). Forcing a marshmallow upgrade could require teams to conduct compatibility testing or security assessments before they can even install Safety.

Since Safety itself is not vulnerable, we don't want to inadvertently block users from scanning their projects.

We're removing the marshmallow dependency entirely

As you noticed from the # TODO: To be removed comment, we've been planning to eliminate this dependency. We believe this is the cleanest path forward, and you can expect it in an upcoming release.

---

Thanks again for the report and for your previous authlib disclosure as well. 🙏

I'll close this issue once we remove the marshmallow dependency.

[fmigneault]

@yeisonvargasf
Is there a timeline of the "removing the marshmallow dependency" path?

While it is indeed better this way, I must explicitly have marshmallow>=4.1.2 in my dependencies in the meantime to patch safety, and it will likely stay there unnecessarily even once marshmallow dependency is removed, since I don't regularly check all projects' sub-dependencies...

Currently, the same problem happens for filelock>=3.20.1 (#665) and authlib>=1.6.5 (#822), and they are still not addressed...
It is very frustrating to get many security vulnerabilities "false-positives" by the tool itself.

Why we're not restricting the version range [...]

It would seem that if users have this restriction, they could simply pin safety itself to avoid the update applying fixed vulnerabilities. If they cannot update to latest marshmallow, filelock, authlib, they would get the vulnerability warnings anyway, so it's not like upgrading safety is that critical to them anyway...

It rather seems like safety does not apply its own recommendations and best practices of "proper remediation for vulnerabilities detected", and only accumulates technological debt unnecessarily.