XRP “decade-old vulnerability” floods feeds: patch is in place, but what really matters are these three timing gaps
“Creating XRP out of thin air” sounds like an incident happening right now. Let’s get the timeline straight: the vulnerability was publicly disclosed on October 9; the payment engine fix had already shipped with xrpld 3.4.1. On October 10, GitHub made the source code for that version and its upgrade instructions public. Disclosure, software fixes, and activation of mainnet rules each answer a different question.
First, the payment engine vulnerability affected versions 3.4.0 and earlier. Researchers reported it through the bug bounty program on September 22. After reproducing it, the team raised its severity and released a fix on September 25. The official investigation suggests the issue may trace back to code from 2015. The report says there is no evidence that the public network was exploited. That is an investigative finding; it cannot be stretched into proof that all historical activity was free of irregularities, much less stated as proof that an inflation attack had occurred.
Second, the same report also covered an issue with internal transaction validation in Batch. When discovered, this rule had not yet been enabled on mainnet. The software shipped with the fix first, while fixBatchV1_2 was not enabled on mainnet until October 9. The payment engine fix, by contrast, took effect as soon as nodes were upgraded. Conflating the two fix timelines as “all vulnerabilities were not closed until October 9” would misstate the risk window.
Third, the considerations for regular holders and node operators should not be conflated. GitHub currently requires servers to be upgraded to 3.4.1, noting that older versions have been blocked by a new amendment and can no longer sync normally. This upgrade requirement applies to server software; it does not mean holders need to transfer their assets to an unfamiliar website to “fix their wallet.” If a link asks for your recovery phrase or authorization under the pretext of a security alert, verify it through official channels first.
My takeaway from this incident is that security defenses should not simply repeat the same assumption: if there is a problem with payment calculations, the validation layer could also miss it if it relies on the same arithmetic assumptions. The patch and the follow-up review process are therefore both worth tracking. This inference is based on the disclosure mechanism; it is not a conclusion about vulnerabilities in other protocols.
I’ll continue watching for updates to the official investigation, progress upgrading older nodes, and subsequent security reviews. These could change the assessment of technical risk; whether the price continues to rise, however, still requires evidence from trading volume and buying support. A security vulnerability being fixed does not, on its own, constitute a buy signal.
Sources: XRPL’s official vulnerability disclosure dated October 9; XRPLF/rippled 3.4.1 release notes. Verified October 10 at 22:36 Beijing time.
“Creating XRP out of thin air” sounds like an incident happening right now. Let’s get the timeline straight: the vulnerability was publicly disclosed on October 9; the payment engine fix had already shipped with xrpld 3.4.1. On October 10, GitHub made the source code for that version and its upgrade instructions public. Disclosure, software fixes, and activation of mainnet rules each answer a different question.
First, the payment engine vulnerability affected versions 3.4.0 and earlier. Researchers reported it through the bug bounty program on September 22. After reproducing it, the team raised its severity and released a fix on September 25. The official investigation suggests the issue may trace back to code from 2015. The report says there is no evidence that the public network was exploited. That is an investigative finding; it cannot be stretched into proof that all historical activity was free of irregularities, much less stated as proof that an inflation attack had occurred.
Second, the same report also covered an issue with internal transaction validation in Batch. When discovered, this rule had not yet been enabled on mainnet. The software shipped with the fix first, while fixBatchV1_2 was not enabled on mainnet until October 9. The payment engine fix, by contrast, took effect as soon as nodes were upgraded. Conflating the two fix timelines as “all vulnerabilities were not closed until October 9” would misstate the risk window.
Third, the considerations for regular holders and node operators should not be conflated. GitHub currently requires servers to be upgraded to 3.4.1, noting that older versions have been blocked by a new amendment and can no longer sync normally. This upgrade requirement applies to server software; it does not mean holders need to transfer their assets to an unfamiliar website to “fix their wallet.” If a link asks for your recovery phrase or authorization under the pretext of a security alert, verify it through official channels first.
My takeaway from this incident is that security defenses should not simply repeat the same assumption: if there is a problem with payment calculations, the validation layer could also miss it if it relies on the same arithmetic assumptions. The patch and the follow-up review process are therefore both worth tracking. This inference is based on the disclosure mechanism; it is not a conclusion about vulnerabilities in other protocols.
I’ll continue watching for updates to the official investigation, progress upgrading older nodes, and subsequent security reviews. These could change the assessment of technical risk; whether the price continues to rise, however, still requires evidence from trading volume and buying support. A security vulnerability being fixed does not, on its own, constitute a buy signal.
Sources: XRPL’s official vulnerability disclosure dated October 9; XRPLF/rippled 3.4.1 release notes. Verified October 10 at 22:36 Beijing time.