There are 2 vulnerabilities faced by nodes that do not upgrade to the new segwit validation rules. The first is an increased risk of 0-conf double spends. The second is the risk of temporarily following an invalid fork.
Segwit introduces new rules that treat certain output scripts as special. For segwit nodes, such outputs may only be redeemed if certain conditions are met, such as a proper signature being provided. However, for old nodes, these outputs look like "anyone-can-spend" outputs. Under the old rules, these outputs may easily be redeemed by anyone on the network without a signature. It is possible to craft a transaction that is valid under the old rules, but invalid under the new rules. This presents some problems if such transactions are relayed to non-upgraded nodes or included in a block that is relayed to non-upgraded nodes.
0-conf double spend
One problem is the increased risk on 0-conf double spends. An attacker (Alice in this example) is sending money to a target (we will call him Bob). Bob is running his wallet or other code on top of a non-upgraded node. Alice can send Bob a transaction (TX 1) in which she redeems a normal output from one of her addresses and also redeems a segwit style output without a signature. Bob's node thinks that this second output is an "anyone-can-spend" output and that Alice is legitimately redeeming it. Bob's node thinks that TX 1 is valid. However, upgraded nodes reject TX 1 as invalid because it violates the new segwit validation rules.
Alice can then create a new transaction (TX 2) that redeems the same output from her address, but it does not include an additional input, and it sends the money back to her wallet instead of to Bob. Bob's node will initially ignore this transaction, because TX 1 has already redeemed Alice's output. However, TX 2 will get included in a block instead of TX 1. If Bob's code does not have sufficiently advanced double-spend detection, he can have problems. This double spend scenario is possible even without any rule changes, but the rule changes make it much easier to perform.
TX 1 - spends an output from Alice's address - sends to Bob - valid under old rules - invalid under segwit rules |======================================| | INPUTS | OUTPUTS | | | | |======================================= | Alice's address | Bob's address | |--------------------------------------| | anyone-can-spend | | |======================================| TX 2 - double spends the same utxo from Alice's address - sends to Alice instead - valid under old and new rules - Ignored by Bob's non-upgraded node as a double spend - included in block by upgraded miners |==========================================| | INPUTS | OUTPUTS | | | | |==========================================| | Alice's address | Alice's other address | |------------------------------------------| | | | |==========================================|
Following an invalid fork
Because non-upgraded nodes will not be performing full tx validation according to the new rules, they are at risk of temporarily following an invalid chain should any miners continue to mine blocks under the old rules. Segwit has already been locked in according to the BIP9 mechanism, but there may be miners that are running old or buggy software that does not enforce the new rules correctly. Such miners could build a block including a transaction such as TX 1 from the double spend example, which would make that block invalid according to the new rules. Other miners that are not doing proper validation could build on top of that invalid block. A similar event has happened before when BIP 66 was enabled. Some miners were practicing "SPV mining" and were building on top of blocks without validating them first. As a result, they built on top of an invalid block. As long as these miners do not represent a majority of hash power, the fork will eventually be resolved. Non-upgraded nodes would then reorg to follow the correct chain, but this period could be rather disruptive.
In order to avoid these vulnerabilities, operators should either upgrade to software that enforces the new rules, or guard their non-upgraded nodes behind boundary nodes that do enforce the new rules. Guarding old nodes behind boundary nodes will prevent invalid blocks or transactions from ever reaching the old nodes.