Vyper Compiler Miscompilation and Parsing Bugs

Optimizer miscompilation in Vyper 0.3.8 through 0.5.0b1 can silently replace a ternary branch expression of the form (msg.value | K) or (len(msg.data) | K) with the constant 1 under default -O gas or -O codesize, corrupting contract logic and potentially locking funds. Only contracts containing that exact OR-in-ternary construct and compiled with an affected version are exposed; the flaw is a compiler-correctness issue rather than a runtime memory-safety bug. No public exploit code was identified at time of analysis, and risk is highly conditional on deployed bytecode containing the miscompiled pattern.

Factories compiled with Vyper 0.3.4 through 0.5.0b1 that forward an attacker-influenced code_offset into the create_from_blueprint builtin can be tricked into deploying contracts with zero runtime code. The compiler computes the remaining blueprint size with unchecked uint256 subtraction, so an offset larger than the blueprint's code size wraps to a small positive number and the copy silently yields empty bytecode; assets sent to the resulting codeless address, or initialization logic that assumes a working contract, can be permanently trapped. Impact is conditional rather than universal: only factories that both use this builtin and expose code_offset to callers are reachable (reflected in the assessed CVSS 3.1 vector AV:N/AC:H/PR:N/UI:N/C:N/I:L/A:L), no public exploit code has been identified at time of analysis, and no CISA KEV entry exists, so this is a moderate, conditional risk rather than a drop-everything priority.

Contracts written in Vyper 0.3.8 through 0.5.0b1 that use a ternary expression to select between nested arrays with differing inner bounds can silently store corrupted values or revert at runtime, because the compiler emits code that reads the narrower arm using the wider result type's memory layout. Only deployments that already contain this specific widening nested-array ternary pattern are exposed, and no public exploit code has been identified at time of analysis. The impact is confined to the integrity of the affected contract's own state (CVSS 4.0 6.3 Medium, VI:L with no confidentiality or availability impact), so contracts lacking the pattern are entirely unaffected.

Numeric literal manipulation in the Vyper smart-contract compiler (versions 0.1.0b1 through 0.1.0b16 and 0.4.1 through 0.5.0b1) lets attacker-supplied source silently alter address, integer, and decimal constants that survive into compiled bytecode. The compiler builds its source-line table with str.splitlines(), which recognizes line separators such as form feed (U+000C) and U+2028 that the Python parser ignores, so literals are classified and validated against a shifted view of the source. Exploitation requires a victim to compile and deploy malicious-looking-but-reviewed code (unauthenticated remote attacker, user interaction required per the assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N), and no public exploit code or confirmed active exploitation has been identified at time of analysis; this is a medium-severity integrity issue, not an urgent remote-code-execution priority.

Source-code integrity compromise in the Vyper compiler allows attacker-supplied Vyper source to silently substitute numeric literals, addresses, and other constants during compilation. Affected versions are Vyper 0.1.0b1 through 0.1.0b11, 0.1.0b14, and 0.4.1 through 0.5.0b1; exploitation requires the victim to compile source containing either a non-ASCII identifier that NFKC-normalizes to ASCII or an invisible byte-order mark, which triggers a character-versus-byte offset mismatch in literal reconstruction. No public exploit code identified at time of analysis, and the flaw does not affect already-compiled trusted contracts or expose a remote network service.