Vyper literal-shifting bugs via Unicode characters

Not applicable. The advisory reports a scan of 45,774 deployed-contract and repository source files found none of the line-separator triggers.

Root cause: Per the advisories: vyper/ast/parse.py builds source offsets inconsistently with the Python parser (str.splitlines line separators; character vs UTF-8 byte offsets), so visit_Num reads literal text from shifted positions. Affects 0.4.1 through 0.5.0b1.

Timeline, as sourced: 6 Oct 2026 (GHSA-wvx7-39qj-2g9v and GHSA-r3c7-7xwm-6vfw).

On 6 October 2026 the Vyper project published two related low-severity advisories. GHSA-wvx7-39qj-2g9v (opens in a new tab) describes eight line-separator characters that Python's str.splitlines treats as newlines but the parser does not, shifting source lookups so numeric literals compile with incorrect values or types. GHSA-r3c7-7xwm-6vfw (opens in a new tab) describes the same effect from multi-byte characters, such as non-ASCII identifiers that normalize to ASCII or an invisible byte-order mark. Both affect Vyper 0.4.1 through 0.5.0b1 (plus some legacy 0.1.0 betas). The advisories say an attacker able to contribute source could change an address, selector or constant without a compiler warning. Until a fix ships, they recommend rejecting the trigger characters before compilation.