Let's split your question into two parts: first the length extension attack problem with Whirlpool, and next your HMAC tool idea.

# *Is whirlpool vulnerable to length extension attack?*

Yes, Whirlpool by itself (as a plain hash, not HMAC) is indeed vulnerable to length extension attacks.

The SkullSecurity.org website offers an explanation in their article [“Everything you need to know about hash length extension attacks”](https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks). Here's an excerpt:

> # The attack

>An application is susceptible to a hash length extension attack if it prepends a secret value to a string, hashes it with a vulnerable algorithm, and entrusts the attacker with both the string and the hash, but not the secret. Then, the server relies on the secret to decide whether or not the data returned later is the same as the original data.

> It turns out, even though the attacker doesn't know the value of the prepended secret, he can still generate a valid hash for {secret || data || attacker_controlled_data}! This is done by simply picking up where the hashing algorithm left off; it turns out, 100% of the state needed to continue a hash is in the output of most hashing algorithms! We simply load that state into the appropriate hash structure and continue hashing.

> TL;DR: given a hash that is composed of a string with an unknown prefix, an attacker can append to the string and produce a new hash that still has the unknown prefix.

> # Example
Let's look at a step-by-step example. For this example:

>     let secret = "secret"
    let data = "data"
    let H = md5()
    let signature = hash(secret || data) = 6036708eba0d11f6ef52ad44e8b74d5b
    let append = "append"

> The server sends data and signature to the attacker. The attacker guesses that H is MD5 simply by its length (it's the most common 128-bit hashing algorithm), based on the source, or the application's specs, or any way they are able to.

> Knowing only data, `H`, and `signature`, the attacker's goal is to append append to data and generate a valid signature for the new data. And that's easy to do! 

In that article, they also link to a tool which allows to practically do a length-extention attack on every algorithm you could wish for – including WHIRLPOOL.

The tool – coded in plain C – is available for free and [hosted at Github under the name `hash_extender`](https://github.com/iagox86/hash_extender). Quoting its description, `hash_extender`…

> … implements a length extension attack against every algorithm I could think of:

> - MD4
- MD5
- RIPEMD-160
- SHA-0
- SHA-1
- SHA-256
- SHA-512
- WHIRLPOOL

> I'm more than happy to extend this to cover other hashing algorithms as well, provided they are "vulnerable" to this attack -- MD2, SHA-224, and SHA-384 are not. Please contact me if you have other candidates and I'll add them ASAP!

# *I am trying to build some HMAC for a program and consider using whirlpool to do so.*

This again lifts the length extension attack problem described above, since the HMAC construction prevents length extension attacks. Therefore, the answer which practically considers your question title as well as your description is extended to:

Yes, Whirlpool by itself (as a plain hash, not HMAC) is indeed vulnerable to length extension attacks – but since you plan to use it in a HMAC construction (which prevents length extension attacks) you can safely ignore that attack vector. Yet, it should be noted that I'm assuming you implement the HMAC construction correctly.

# TL;DR

- Yes, Whirlpool as a plain hash is vulnerable to length extension attacks.
- HMAC constructions prevent length extension attacks, which voids that problem.