Is whirlpool vulnerable to length extension attack? Is whirlpool vulnerable to length extension attacks? 
I did not find anything on the topic and hardly anything interesting about whirlpool at all. I am trying to build some HMAC for a program and consider using whirlpool to do so.
Let's split your question into two parts: first the length extension attack problem with Whirlpool, and next your HMAC tool idea.

1. Is whirlpool vulnerable to length extension attack?

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

Besides Crypto.SE Q&amp;As like “Understanding the length extension attack”, the SkullSecurity.org website offers an explanation in their article “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. 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!


2. 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 a HMAC construction (which securely hashes data with a secret key) prevents length extension attacks. For details on how a HMAC construction achieves that, you can check the Crypto.SE Q&amp;A “How does the secret key in an HMAC prevent modification of the HMAC?” which explains that HMACs were designed to void length extension attack issues.

When trying to attack a HMAC,


  …the attacker only controls variable-length input to the inner hash, not the outer hash…


So, 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.