CVE-2024-32645

Executive Summary

CVE-2024-32645 is a vulnerability in the Vyper smart contract language (versions 0.3.10 and prior) that causes incorrect values to be logged when the raw_log builtin is called with memory or storage arguments used as topics. This flaw stems from improper unwrapping of variables in the build_IR function of the RawLog class, leading to incorrect topic emission. While no vulnerable contracts were found in production, the bug could allow attackers to manipulate or misinterpret logged events, potentially leading to information disclosure or logic errors in dependent systems. The CVSS score is 5.3 (Medium), and no patch is currently available.

Supply Chain & Package Security

This vulnerability affects the Vyper compiler, which is a critical component in the Ethereum smart contract development supply chain. Developers using Vyper to compile contracts that rely on raw_log for event logging are at risk. Since Vyper is distributed via PyPI (vyper package), any project depending on an affected version should be considered vulnerable. The lack of a patch means that supply chain security relies on manual code review and workarounds.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability can be triggered by deploying a contract that uses raw_log with memory/storage topics.
• Attack Complexity (AC): Low (L) – No special conditions are required beyond using the affected builtin.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): Low (L) – Incorrect logging may leak unintended data.
• Integrity (I): None (N) – No direct integrity impact.
• Availability (A): None (N) – No availability impact.

Threat Level: Medium. The bug is subtle and requires specific usage of raw_log, but it could lead to information disclosure or event spoofing in decentralized applications.

Deep Dive & Mechanics

The raw_log builtin in Vyper allows developers to emit low-level Ethereum logs with arbitrary topics. The vulnerability lies in the build_IR function of the RawLog class in the Vyper compiler. When memory or storage variables are passed as topics, the compiler fails to properly unwrap them, meaning it does not correctly resolve the variable’s value to its actual data. Instead, it may log the memory address or storage slot identifier rather than the intended value.

For example, if a developer writes:

raw_log([], [my_storage_var])

The compiler might emit the storage slot number of my_storage_var as the topic instead of its actual value. This can cause off-chain listeners (e.g., indexers, dApps) to misinterpret events, potentially leading to incorrect state updates or security decisions.

The root cause is in the build_IR method, which handles the translation of Vyper AST nodes to intermediate representation (IR). For topic arguments, it should recursively unwrap memory/storage references to their underlying values, but it fails to do so for certain cases.

Vulnerable vs. Patched Code

Vulnerable Code (Vyper <= 0.3.10):

# Example contract using raw_log with storage variable
my_var: uint256

@external
def log_event():
    raw_log([], [self.my_var])  # Incorrectly logs storage slot, not value

Patched Code (Hypothetical fix):

# The fix would require the compiler to properly unwrap the variable
# For now, developers must manually load the value into memory first
@external
def log_event():
    val: uint256 = self.my_var
    raw_log([], [val])  # Correctly logs the value

Compiler Fix (Conceptual): In the build_IR function of RawLog, the fix would involve adding a check to unwrap memory/storage references:

# Pseudocode for fix in compiler
def build_IR(self, expr, context):
    topics = []
    for topic in expr.args[1].elements:
        # Unwrap memory/storage references
        if isinstance(topic, (Variable, StorageVariable)):
            topic = topic.unwrap()  # Get actual value
        topics.append(topic)
    # Continue with IR generation

Exploitation & Lab Setup

Red Team (Attacker)

Objective: Exploit the incorrect logging to mislead off-chain systems.

Lab Setup:

1. Install Vyper 0.3.10: pip install vyper==0.3.10
2. Create a vulnerable contract:

# vulnerable.vy
stored_value: uint256

@external
def __init__():
    self.stored_value = 42

@external
def log_bad():
    raw_log([], [self.stored_value])  # Logs storage slot (0x0) instead of 42

3. Compile and deploy to a local Ethereum testnet (e.g., Ganache).
4. Call log_bad() and observe the emitted event. The topic will be 0x0000000000000000000000000000000000000000000000000000000000000000 (storage slot) instead of 0x000000000000000000000000000000000000000000000000000000000000002a (42).

Impact: An attacker could craft a contract that emits events with misleading topics, causing off-chain indexers to record incorrect data. This could be used to manipulate token balances, voting results, or other state-dependent logic.

Blue Team (Defender)

Detection:

• Monitor for contracts that use raw_log with storage or memory variables directly as topics.
• Use static analysis tools to scan Vyper source code for this pattern.
• In production, verify that all raw_log calls use only literal values or variables that have been explicitly loaded into memory.

Mitigation:

• Upgrade to a patched version when available.
• As a workaround, always load storage/memory variables into a local variable before passing to raw_log:

@external
def log_safe():
    val: uint256 = self.stored_value
    raw_log([], [val])

Indicators of Compromise (IOCs)

• Contract bytecode containing raw_log with storage variable references (detectable via static analysis).
• Ethereum logs where topics are storage slot numbers (e.g., 0x0000000000000000000000000000000000000000000000000000000000000000 for slot 0) instead of expected values.
• Compiler version in contract metadata: vyper:0.3.10 or earlier.

Detection Engineering

YARA Rule

rule Detect_Vyper_RawLog_Vulnerability {
    meta:
        description = "Detects Vyper contracts using raw_log with storage/memory variables as topics"
        author = "Valters IT"
        date = "2024-01-01"
        cve = "CVE-2024-32645"
    strings:
        $raw_log = "raw_log" nocase
        $storage_var = /self\.\w+/  // Matches storage variable references
    condition:
        $raw_log and $storage_var
}

Sigma Rule

title: Vyper RawLog Incorrect Topic Emission
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects Vyper contracts that may log incorrect topics due to CVE-2024-32645
logsource:
    category: ethereum
    product: vyper
detection:
    selection:
        event_type: "raw_log"
        topic_source: "storage" or "memory"
    condition: selection
falsepositives:
    - Contracts that intentionally log storage slot numbers
level: medium

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-32645 - Vyper RawLog Incorrect Topic Emission"; content:"raw_log"; depth:100; content:"self."; distance:0; within:50; classtype:attempted-information-leak; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Workaround: Manually load storage/memory variables into local variables before passing to raw_log:

@external
def safe_log():
    val: uint256 = self.my_storage_var
    raw_log([], [val])

2. Compiler Upgrade: Monitor the Vyper GitHub repository for a patched version (expected >0.3.10). When available, upgrade immediately.
3. Static Analysis: Use tools like Slither or Mythril to scan contracts for this pattern.
4. Audit: Review all contracts using raw_log to ensure topics are correctly emitted.
5. Monitoring: Set up alerts for unexpected topic values in logs.

Valters IT
DevSecOps & Cyber Threat Intelligence