On August 15, 2010, an attacker exploited a single arithmetic flaw in Bitcoin's transaction-verification code to create 184,467,440,737.09551616 new bitcoins in one transaction — a number so large it was more than 100,000 times the entire supply in existence at the time. The bug wasn't a broken cryptographic algorithm or a stolen key. It was an integer overflow: two large values were added together, the sum exceeded the maximum a 64-bit variable could hold, and the result silently wrapped around into a number that passed every validation check the code performed. Developers patched it within about five hours using an emergency hard fork, but the incident became the textbook case for a bug class that has since triggered aircraft airworthiness directives, erased hundreds of millions of dollars in cryptocurrency value, and handed attackers root access to Linux servers. Integer overflow and wraparound vulnerabilities are cheap to write, easy to miss in review, and capable of turning one addition or multiplication into a full security failure. Here's how they work and why they keep coming back.
What is an integer overflow and wraparound vulnerability?
An integer overflow — cataloged as CWE-190 in MITRE's Common Weakness Enumeration — occurs when an arithmetic operation produces a result larger than the maximum value a data type can represent, causing it to silently wrap around to a small, zero, or negative value instead of raising an error. The wrap depends on the type's range: an unsigned 8-bit integer holds values from 0 to 255, so 200 + 100 doesn't produce 300 — it produces 44, because 300 minus the 256-value range wraps back to the start. A signed 32-bit integer maxes out at 2,147,483,647; add 1 to it and, in languages that don't check, it flips to -2,147,483,648. The same class includes underflow, or wraparound in the other direction: subtracting 1 from an unsigned integer set to 0 doesn't go negative, it jumps to the type's maximum — 4,294,967,295 for a 32-bit unsigned integer.
The reason this keeps happening is that most systems languages don't check for it by default. C and C++ perform silent wraparound on unsigned arithmetic and treat signed overflow as undefined behavior, meaning the compiler is free to optimize based on the assumption it never happens — which can remove the very bounds check a developer wrote to catch it. Rust panics on overflow in debug builds but wraps silently in release builds unless a developer explicitly calls checked_add or similar. Solidity, before version 0.8.0, wrapped uint256 arithmetic silently, which is exactly what made it a magnet for financial exploits. The result is a vulnerability class that looks like ordinary math and rarely announces itself until an attacker deliberately engineers the inputs to break it.
How did a single arithmetic bug let someone mint 184 billion bitcoin in 2010?
It happened because Bitcoin's early code checked that a transaction's outputs didn't exceed its inputs, but never checked whether the outputs themselves overflowed the signed 64-bit integer used to store their combined value. In block 74,638, a transaction contained two outputs whose values, when summed, exceeded the maximum a 64-bit signed integer could hold and wrapped around into a negative number. Because the negative "total" was still numerically less than the input value, the sanity check passed, and the network minted roughly 184.467 billion coins to two addresses. Satoshi Nakamoto and other early developers released a patched client, version 0.3.10, within about five hours, and the network coordinated a hard fork to reject the block and any chain built on it — one of only a handful of times Bitcoin has ever reversed a confirmed block. The incident, now tracked as CVE-2010-5139, is why Bitcoin Core still enforces an explicit MAX_MONEY cap on every transaction rather than trusting arithmetic comparisons alone.
Why did Boeing warn airlines to power-cycle 787 Dreamliners every 248 days?
Boeing issued the warning because a software counter inside the 787's electrical generator control units would overflow after 248 days of continuous operation, causing all four units to fail at the same time. In 2015, the FAA issued Airworthiness Directive 2015-12-08 after Boeing discovered that if the generator control units associated with the aircraft's engine-mounted generators were left powered without interruption for 248 days, an internal counter would overflow and drive all four units into a simultaneous failsafe shutdown — cutting electrical power regardless of flight phase. Until a software fix was deployed fleet-wide, the FAA's mandated workaround was procedural: operators had to power-cycle the aircraft's electrical system before the counter reached its limit. It's a reminder that integer overflow isn't just a web-app or crypto-wallet problem — it lives in embedded firmware controlling safety-critical hardware, where a single unchecked counter can ground a fleet.
How did one unchecked multiplication erase hundreds of millions from a cryptocurrency in 2018?
It happened because the Beauty Chain (BEC) token's smart contract multiplied a transfer amount by a recipient count without checking whether the result overflowed Solidity's 256-bit integer type. On April 22, 2018, an attacker exploited what became known as the "BatchOverflow" bug, tracked as CVE-2018-10299, in the contract's batchTransfer function. By choosing a recipient count and per-recipient value whose product exceeded the maximum uint256 value (2^256 − 1, roughly 1.15 × 10^77), the multiplication wrapped around to a tiny number that slipped past the contract's balance check — while the attacker's own account was simultaneously credited with an amount equivalent to quintillions of tokens. The attacker moved a portion of those tokens to exchanges and sold them, crashing BEC's price toward zero and wiping out an estimated $900 million in market value within hours. The same overflow pattern turned up in multiple other ERC-20 contracts that week. The fallout is a large part of why Solidity made overflow and underflow checks the default behavior starting with version 0.8.0 in December 2020, after years of developers relying on an external SafeMath library to patch over the gap.
How did a Linux kernel function untouched for years suddenly become a root-privilege-escalation bug in 2021?
It became exploitable because a size calculation inside the kernel's seq_file filesystem interface used a signed integer that could be forced to overflow when fed a large enough input. Researchers at Qualys disclosed the flaw, nicknamed "Sequoia" and tracked as CVE-2021-33909, on July 20, 2021. By creating, mounting, and then deleting a deeply nested directory structure whose full path length exceeded roughly one billion characters, an unprivileged local user could trigger a size_t-to-int truncation that wrapped a legitimate size calculation into a negative number, corrupting kernel memory in a way that led to full root access. The vulnerable code path had existed in the kernel since 2014, affecting virtually every major Linux distribution — Ubuntu, Debian, Fedora, and RHEL among them — for seven years before anyone noticed the arithmetic could be weaponized. Vendors shipped patches within days of disclosure, but the gap between introduction and discovery illustrates the core danger of this bug class: overflow conditions can sit dormant in mature, heavily used code for years because they only trigger under input conditions nobody thought to test.
How Safeguard Helps
Every example above shares a pattern: a routine arithmetic operation, an unchecked boundary, and a downstream check that trusted the result. Safeguard is built to catch that pattern before it ships. Our static analysis scans first-party code for unchecked arithmetic on attacker-influenced inputs — size calculations, buffer indices, token amounts, counters — and flags CWE-190-class findings with the specific line and data flow that makes the overflow reachable, rather than a generic "arithmetic operation" warning that gets ignored.
On the dependency side, Safeguard's software composition analysis continuously matches every library, container base image, and smart contract dependency in your build against known integer overflow CVEs — including the Sequoia-style kernel bugs and BatchOverflow-style contract flaws described here — and surfaces exactly which of your deployed artifacts pull in the vulnerable version, so you're not left grepping changelogs after a disclosure. Because Safeguard generates and maintains a full software bill of materials for every build, when a new overflow CVE drops, you get an immediate answer to "are we affected, and where," rather than a multi-day audit.
Finally, Safeguard's CI/CD policy gates let teams block merges and releases on unresolved CWE-190 findings above a defined severity, closing the gap between "the scanner found it" and "the code shipped anyway." Integer overflows are rarely exotic; they're missed boundary checks in ordinary code. Catching them consistently, at the point of commit and at the point of dependency resolution, is what turns a bug class with a two-decade track record of expensive surprises into a routine finding your pipeline handles before it ever reaches production.