The root of the issue is that XSLTC (turns XSLT into a Java Class to be executed for better performance) does not account for that fact that the constant_pool_count in a Java class is only 16bits. An attacker can create an XSLT document containing too many constants, all of which will be written to the class file, but the count will be truncated to 16bits, leading to some of those constants being interpreted as part of the classfile containing things like field and method descriptions for the class.

The whole post gets deep into the background how XSLT is exposed through SAML assertions and verifying signatures (so part of the unauthenticated attack-surface) and into the details of actually crafting a valid classfile abusing this integer truncation.