Vyper interfaces returning integer types less than 256 bits can be manipulated if uint256 is used

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

not scored

EPSS

• CVE-2020-37289: 0.26% estimated exploitation activity in the next 30 days; percentile 18.00 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

VVE-2020-0001 Earlier today, we received a responsible disclosure of a potential issue from @montyly (security researcher at @trailofbits) for Vyper users who make assumptions about what values certain interface types can return. Impact We determined the issue to be mild and unlikely to be exploited, with an easy workaround while the correct resolution is in process. The issue stems from a number of things, which we will detail here. (1) The ABI Specification is under-defined such that function return type is not always reflected in how you use it This means that a function which returns uint8 under the hood actually returns a 32 byte integer, making it identical to a function that returns uint256. This allows users to read an interface that returns a uint8 value to be stored into a uint256 variable without any explicit casting or input validation. (2) Vyper doesn't have uint8 types When Vyper was originally created, it only had one numeric type, but we added just enough types to…

Published by the source

25 Mar 2020, 18:20 UTC

Last modified by the source

24 Oct 2026, 02:56 UTC

Source last checked

26 Oct 2026, 13:08 UTC

1. Revision 2 · amended · 26 Oct 2026

   Amended from ghsa record GHSA-mr6r-mvw4-736g

2. Revision 1 · created · 24 Oct 2026

   Published from osv record GHSA-mr6r-mvw4-736g

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2020-37289

Advisory: Vyper interfaces returning integer types less than 256 bits can be manipulated if uint256 is used
IDs: CVE-2020-37289, GHSA-mr6r-mvw4-736g
Record: https://patchnext.com/advisories/cve-2020-37289 (revision 2, source checked 26 Oct 2026, 13:08 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Unrated
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor response not established. A vendor fix does not mean a deployment is fixed.

## Affected components
- PyPI vyper: affected <= 0.1.0b16

## Suggested inspection (read-only)
- `python -m pip show vyper`: prints the installed version. Run with the environment that serves production active.

## Supported action
No complete vendor fix is recorded. Follow the primary source's mitigation guidance and check this record again before closing anything.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on vyper.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/GHSA-mr6r-mvw4-736g (OSV record GHSA-mr6r-mvw4-736g lists affected ranges: PyPI vyper >=0 <=0.1.0b16)
- Verified: https://github.com/advisories/GHSA-mr6r-mvw4-736g (GitHub-reviewed advisory GHSA-mr6r-mvw4-736g lists affected ranges: PyPI vyper >=0 <=0.1.0b16)

Commands are suggestions: review each one before running it.