Length extension attack changes the hash result therefore with high probability the difficulty parameters is no longer valid. From this $$ h = \operatorname{SHA-256}(a\mathbin\|b\mathbin\|pad1)$$ in to this*. $$ h'= \operatorname{SHA-256}(a\mathbin\|b\mathbin\| \text{pad1}\mathbin\|\text{appended_data} \mathbin\| \text{pad2})$$ We don't expect them to be equal, the equality is negligible event.
Of course, the attacker may search for such an extension (appended_data) that has a similar difficulty parameter. However, they don't have much time since one of the clients has already found the nonce that is valid for the difficulty parameter and it is already propagating on the network.
The verifiers will get the $a$ and $b$ and the hash result $h'$ ( the limited size is the key here). When they calculate the hash value they will calculate $h = \operatorname{SHA-256}(a\mathbin\|b)$ and they will see that $h \neq h'$ and the equality is a negligible event.
Even they have the same same hash value or valid difficulty parameter, a properly implemented client will see the attack.
Therefore with proper implementations, a length extension attack is not a problem. However, don't rely on the implementations since they can be incorrect, use double SHA-256 as Bitcoin did. Alternatively, use length extension resistant hash functions like SHA-512/256, BLAKE2/3, SHA3-256.
Keep in mind that POW is designed to require lots of work, so choosing double SHA-256 was not a bad idea when Bitcoin design started.
*The paddings
$pad1$ is the padding of SHA-256 where fist 1
is appended than as small as possible 0
s such that when the length encoding is added the message is multiple of 512.
The length extension attacker must use this padding and then add the extended message then that will need additional padding as the $pad2$, too.