What is the impact of an exposed secret key for a JWT token implementation?
Whoever possesses the private key can create valid tokens where your system simply can not distinguish between a legitimate token and a token created by the attacker.
I am guessing you are not just using the expiry field but also the subject field sub, which is in short terms the logged in user.
With the private key, I can create a token with any subject I want, thus sign in as any user of your system.
As you stated, I can also add any other claim and you system has no choice but trust it, as I was able to create a valid signature.
It can not be stressed enough, but JWT heavily relies on the private key to stay absolutely private. Losing the private key is the worst case scenario.
Having a leaked private key would be equivalent to issuing JWTs using only the header and payload sections, and trusting any such JWT a user sends you.
If the private key isn't private, there's no protection offered by the signature section anymore, so you might as well leave it off. Now you'll save bandwidth with smaller JWTs and you'll save CPU time from not having to generate or verify signatures! Nice. ;)
Without a signature section (either literally or effectively) a user can easily update the header and payload however they like, and you have to believe that what they're sending you is what you gave them in the first place.
Even if there's currently nothing particularly sensitive a malicious user could gain access to with your service, you might expand your capabilities in the future, and if you're still using that same leaked key, it's going to become a bigger problem.
I agree with the accepted answer above, except for it being the "worst case scenario". I don't think you need to be quite that scared. At worst, if your private key is leaked, you could just generate and use a new one. Your users with tokens that were valid up until this point will now have invalid tokens... so they'll have to re-authenticate, etc. It really depends on the context of what you use the tokens for in the first place.
Perhaps a scenario that is worse is if your private key were leaked and you didn't know about it. And if your data is that sensitive, and especially if you can assume short-term expirations... it might not be a bad idea to generate and then update your private key on a regular basis when it's OK to kick users off the system. That way a leaked private key is less likely to be damaging.
(Sorry... I know I shouldn't respond to another answer in my answer, but I can't actually add a comment to that answer, which is what I would prefer to do!)