Some attacks need a clever chain of primitives. This one needs a large integer in a header.
The mechanism
The PBES2-HS256+A128KW family derives a key from a password using PBKDF2. Iterating slowly is the point: it makes brute force expensive.
The number of iterations travels in the token itself, in the p2c header. The recipient reads it and runs that many rounds.
You can see it coming. An unauthenticated attacker crafts a single JWE with p2c set to a hundred million, sends it, and the server dutifully starts computing. One request, one pinned CPU. Repeat.
Why it went unnoticed
Because the implementation was correct. It did exactly what the specification describes. The flaw is not in the arithmetic, it is in trusting a cost parameter supplied by the party you are defending against.
The work happens before any authentication, which is what makes it reachable by anyone who can reach the endpoint.
The fix
p2c is now bounded, with a configurable ceiling. Above it, the token is refused without computing anything. Fixed in 3.4.10, 4.0.7 and 4.1.7.
The pattern to look for
Any parameter that says how much work to do, and that arrives from outside, needs a ceiling. Iteration counts, memory costs, decompression ratios, image dimensions, recursion depths. The bound belongs in your configuration, never in the message.
And if you can avoid password-based key encryption in a protocol exposed to the internet, do. The reason it is slow is the reason it is dangerous here.