For any soft fork, it's possible for a block to contain a transaction violating the new consensus rules. Old nodes would accept this block and new nodes would refuse it.

However as long as more than half of the network hashrate updated to the new rules the fork would only be temporary. This is because those would never mine on top of an invalid node. If the majority of the hashrate does so they would eventually create a chain with more work than the one with the invalid block, which old nodes would therefore drop.

For any soft fork, it's possible for a block to contain a transaction violating the new consensus rules. Old nodes would accept this block and new nodes would refuse it.

However as long as more than half of the network hashrate updated to the new rules the fork would only be temporary. This is because updated miners would not mine on top of an invalid block. If the majority of the hashrate does so they would eventually create a chain with more work than the one with the invalid block, which old nodes would therefore drop.

The lower the percentage of updated hashrate on the network, the higher the probability of a long chain containing an invalid block being created. This is why historically care has been taken to wait for miners to upgrade their nodes before full nodes started enforcing the new rules. You want to minimize the probability of an unsuspecting user receiving a payment on their non-updated node with a decent number of confirmations which eventually gets wiped as the invalid chain gets reorg'd out!

To go further:

• "On the security of soft forks" a post from Pieter Wuille which examines the failure modes of a soft fork activation.
• A tiny Python script by Jonas Nick which computes the probability of an old node seeing a chain longer than N blocks given the % of the network hashrate which updated to the new rules.