The vulnerability lies in Fastjson's autoType feature, which allows specifying a Java class name in the JSON input using the @type key. The core of the issue is in the com.alibaba.fastjson.parser.ParserConfig.checkAutoType function. In vulnerable versions, this function did not properly validate the class name before attempting to load it. An attacker could provide the name of a malicious class (e.g., one that triggers a JNDI lookup) and Fastjson would load and instantiate it, leading to Remote Code Execution.
The patch in version 1.2.48 addresses this by introducing multiple layers of defense within checkAutoType. First, it inspects the class's bytecode using an ASM ClassReader to check for a @JSONType annotation before loading the class. This prevents the class's static initializers from running if it's not explicitly marked as safe for deserialization. Second, it tightens the conditions under which autoType is permitted, for example, by not trusting overly generic expected types like java.lang.Object or java.io.Serializable.
The analysis of the commits between versions 1.2.47 and 1.2.48 confirms these changes. The modifications in ParserConfig.java are central to the fix. The related changes in TypeUtils.loadClass (which performs the class loading) and MiscCodec.deserialze (a potential entry point for class loading) are supporting fixes to limit caching and reduce the attack surface. Therefore, any runtime profile during exploitation would prominently feature checkAutoType and its helper TypeUtils.loadClass.