Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI

GHSA-c647-pxm2-c52w

HIGH

Vyper vulnerable to memory corruption in certain builtins utilizing `msize`

Also known asCVE-2023-42443PYSEC-2023-306
Published
Sep 20, 2023
Updated
Nov 22, 2024
Affected
1 pkg
Patched
1 / 1
Exploits
1 known

EPSS Exploitation Probability

via FIRST.org ↗
0.7%probability of exploitation in next 30 days
Lower Risk48th percentile+0.47%
0.00%0.40%0.80%1.20%0.2%0.7%Dec 25Apr 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐍vyper

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Impact

In certain conditions, the memory used by the builtins raw_call, create_from_blueprint and create_copy_of can be corrupted.

  • For raw_call, the argument buffer of the call can be corrupted, leading to incorrect calldata in the sub-context.
  • For create_from_blueprint and create_copy_of, the buffer for the to-be-deployed bytecode can be corrupted, leading to deploying incorrect bytecode.

Below are the conditions that must be fulfilled for the corruption to happen for each builtin:

raw_call

  • memory is not fully initialized, ex. all parameters to an external function live in calldata and
  • The data argument of the builtin is msg.data. and
  • The to, value or gas passed to the builtin is some complex expression that results in writing to uninitialized memory (e.g. calling an internal function)

create_copy_of

  • memory is not fully initialized, ex. all parameters to an external function live in calldata and
  • The value or salt passed to the builtin is some complex expression that results in writing to uninitialized memory (e.g. calling an internal function)

create_from_blueprint

  • memory is not fully initialized, ex. all parameters to an external function live in calldata and
  • Either no constructor parameters are passed to the builtin or raw_args is set to True. and
  • The value or salt passed to the builtin is some complex expression that results in writing to uninitialized memory (e.g. calling an internal function)

Note: When the builtin is being called from an internal function f from a function g, the issue is not present provided that g has written to memory before calling f.

Examples

raw_call

In the following contract, calling bar(1,1) will return:

ae42e95100000000000000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000001

instead of:

ae42e95100000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001
identity: constant(address) = 0x0000000000000000000000000000000000000004

@external
def foo():
    pass

@internal
@view
def get_address()->address:
    a:uint256 = max_value(uint256) # 0xfff...fff
    return identity
@external
def bar(f:uint256, u:uint256) -> Bytes[100]:
    a: Bytes[100] = raw_call(self.get_address(), msg.data, max_outsize=100)
    return a
create_copy_of

In the following contract, after calling test(), the code deployed at self.created_address does not match the bytecode at target.

created_address: public(address)

@external
def test(target: address) -> address:
    # The expression in salt= is complex and will require to store to memory
    self.created_address = create_copy_of(target, salt = keccak256(_abi_encode(target)))
    return self.created_address
create_from_blueprint

In the following contract, after calling test(), the init bytecode used to create the contract deployed at the address self.created_address will not match the blueprint bytecode stored at target.

created_address: public(address)

salt: constant(bytes32) = keccak256("kebab")

@external
@payable
def test(target: address):
    # The expression in salt= is complex and will require to store to memory
    self.created_address = create_from_blueprint(target, code_offset=0, salt=keccak256(_abi_encode(target)))

Patches

issue tracking in https://github.com/vyperlang/vyper/issues/3609, patched in #3610

Workarounds

The complex expressions that are being passed as kwargs to the builtin should be cached in memory prior to the call to the builtin. For the last example above, it would be:

created_address: public(address)

salt: constant(bytes32) = keccak256("kebab")

@external
@payable
def test(target: address):
    salt: bytes32 = keccak256(_abi_encode(target))
    self.created_address = create_from_blueprint(target, code_offset=0, salt=salt)

References

Are there any links users can visit to find out more?

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIvyper0.3.4&&< 0.3.100.3.10
Exploits & PoCs
1

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vyper. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update vyper to 0.3.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c647-pxm2-c52w is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-c647-pxm2-c52w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-c647-pxm2-c52w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact In certain conditions, the memory used by the builtins `raw_call`, `create_from_blueprint` and `create_copy_of` can be corrupted. - For `raw_call`, the argument buffer of the call can be corrupted, leading to incorrect `calldata` in the sub-context. - For `create_from_blueprint` and `create_copy_of`, the buffer for the to-be-deployed bytecode can be corrupted, leading to deploying incorrect bytecode. Below are the conditions that must be fulfilled for the corruption to happen for each builtin: #### `raw_call` - memory is not fully initialized, ex. all parameters to an external f
O3 Security · Impact-Aware SCA

Is GHSA-c647-pxm2-c52w in your dependencies?

O3 detects GHSA-c647-pxm2-c52w across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.