Keyless integrity checking with SHA-256 Currently a program is loading some files from an untrustworthy source (e.g. a CDN) which could have been tampered with. It has a known SHA-256 hash of the file stored locally, then it downloads the file from the CDN and compares the hash before loading the file into memory.

Because most of the SHA2 family suffers from length extension attacks (except for the truncated versions) this SHA-256 hash seems inadequate for integrity checking files coming from an untrustworthy source. A clever attacker could embed some extra data in the file being downloaded, the program would receive the file, calculate it to be the same SHA-256 hash, unwittingly execute that code and compromise the program.

The program's source code is publicly available, therefore embedding a secret key for HMAC is not an option and would be too slow anyway. SHA3 library code is not currently available either. However the SHA-384 hash is not vulnerable to the length extension attack. Would the next best option be to use SHA-384 for this integrity checking? It would also match up with NSA's recent recommendation to use at least SHA-384.
A length extension attack doesn't let you find a collision. It lets you predict the hash for an input with an unknown component in the prefix. If you have $h = H(x)$ for unknown (or partially unknown) $x$, you can generate $h_y = H(x \vert\vert y)$ for arbitrary $y$ (this is not strictly correct; I've ignored padding, but for the purposes of this discussion it's a minor detail). However, you still can't find $z$ such that $h = H(x \vert\vert z) = H(x)$ faster than brute force.