Following the disclosure of severe remote code execution risks in Fastjson 1.x, Fastjson2 has also encountered a new remote code execution security risk.
In July 2026, security researchers discovered and reported a remote code execution vulnerability in Fastjson2. According to the public advisory, the vulnerability may affect Fastjson 2.0.62 and below. Under exploitation conditions, attackers only need to control the JSON request data entering the application, without authentication, and without requiring traditional dangerous classes commonly used in deserialization attacks, they may execute arbitrary code on the server.
This news deserves high attention from enterprises. Just before this, Fastjson 1.2.68 to 1.2.83 had already been disclosed to have another remote code execution risk. Many enterprises had just begun planning to migrate from Fastjson 1.x to Fastjson2, but now they need to re-examine the actual version and security configuration of Fastjson2.
From Fastjson 1.x to Fastjson2, Why Do Risks Keep Appearing?
In the previous article about the Fastjson 1.x vulnerability,Fastjson 1.x Remote Code Execution Vulnerability: What Applications Should Enterprises Audit Immediately?
We mentioned:
Even if AutoType is disabled, as long as SafeMode is not enabled, the application may still be at risk.
This vulnerability in Fastjson 1.x mainly involves type checking, resource access, and class loading mechanisms. Attackers may trigger external resource loading through malicious @type content, and further achieve remote code execution in specific deployment environments.
Although this disclosed Fastjson2 vulnerability is also related to type identification and class loading, the mechanism that produces the vulnerability is different.
According to public technical information, even when SupportAutoType is not enabled by default, Fastjson2 may still process the @type attribute at the beginning of generic object elements.
When the program verifies the type name, it calculates an incremental FNV 1a hash of the input content and matches the result against the default allowed hash values. However, in certain code paths, after the system hits a hash value, it does not further verify whether the input text actually equals the expected whitelist class name.
Attackers may construct special strings with the same hash match results, causing content containing URL characteristics to enter the application context class loader, ultimately triggering arbitrary code execution.
Simply put, the system checks the "digital fingerprint" of the type name, but does not fully verify the type name itself again after a match. Attackers may exploit hash collisions to make malicious strings be mistaken for trusted types.
Which Systems Need Priority Auditing?
According to current public information, enterprises should prioritize auditing Java applications using Fastjson 2.0.62 and below.
Focus on the following scenarios:
Applications provide external JSON interfaces where attackers can control complete or partial JSON request bodies.
Applications parse external JSON into Object, Map, or other generic types.
Business data may allow or contain the @type attribute.
Application runtime accounts have high file, network, or system operation privileges.
Applications operate in the Internet, partner networks, or other not fully trusted access environments.
Since this vulnerability is described as potentially triggerable under default configuration, enterprises should not rely solely on "not actively enabling AutoType" as a basis for ruling out risks.
At the same time, the audit scope should not only cover dependencies directly declared by the business team. Some applications may introduce Fastjson2 through public components, internal SDKs, third-party frameworks, or indirect dependencies. R&D and operations teams need to cross-confirm based on Maven, Gradle dependency lists, software composition analysis results, and actual server deployment files.
CloudSino Continues to Follow Up and Quickly Updates Interim Remediation
In previously published articles, CloudSino has explained the Fastjson 1.x related remote code execution risks, impact scope, and audit priorities, and reminded enterprises to focus on verifying Fastjson versions, SafeMode configuration, application deployment methods, and external JSON input situations.
As Fastjson2 related security risks are further disclosed, CloudSino immediately organized the technical team to carry out a new round of impact analysis, and quickly updated interim remediation plans, assisting related projects in completing configuration adjustments, effectiveness verification, and rectification tracking.
For CloudSino systems currently still using Fastjson 1.x, the interim remediation focus is to enable SafeMode and further restrict AutoType related capabilities.
For Web nodes, you need to modify the bin/startup.sh file and add the following JVM parameters before the Tomcat startup script is executed:
export JAVA_OPTS="$JAVA_OPTS -Dfastjson.parser.safeMode=true"If the system uses other middleware such as TongTech or Baolande, you need to add the following parameters to the JVM startup configuration in the corresponding middleware management page:
-Dfastjson.parser.safeMode=true
After configuration is complete, you need to restart the relevant Web services for it to take effect.
For collection nodes, you need to modify the server/bin/startServer.sh file and add the following before the AppStartup startup command:
JAVA_OPTS="$JAVA_OPTS -Dfastjson.parser.safeMode=true"
After completing the modifications, you also need to restart the collection process.
After the restart is complete, you can use the following commands to check the startup parameters of the Tomcat process and the collection process separately:
ps -ef | grep java | grep fastjson
If the following content already appears in the process parameters, it means the SafeMode configuration has been successfully loaded:
-Dfastjson.parser.safeMode=trueThe CloudSino interim handling plan specifically emphasizes that Web nodes and collection nodes need to be modified, restarted, and verified separately, to avoid only handling one type of node, causing some Java processes to remain at risk.
For environments using Fastjson2, the corresponding SafeMode parameter for Fastjson2 should be used:
-Dfastjson2.parser.safeMode=trueThe parameter names for Fastjson 1.x and Fastjson2 are different. During implementation, you need to configure accurately according to the actual component version and cannot be mixed directly.
It should be noted that SafeMode is an interim mitigation measure at the current stage. It can reduce related type parsing and class loading risks, but enterprises should continue to confirm the actual version in use, business interfaces, and deployment environment, and pay attention to the official formal fix versions subsequently released by Fastjson.
CloudSino will continue to track Fastjson related security trends, and update remediation plans in a timely manner based on the vulnerability impact scope and official fix progress, assisting customers in completing version verification, node rectification, startup parameter validation, and subsequent review, to minimize the vulnerability risk exposure time.
About Guangzhou CloudSino Information Technology Co., Ltd.
Guangzhou CloudSino Information Technology Co., Ltd. focuses on intelligent operations and maintenance management of data centers and enterprise IT infrastructure. Its product capabilities cover hardware monitoring, out-of-band management, IT infrastructure management, full lifecycle asset management, energy and space management, automated deployment, topology visualization, and business service visualization. The company serves customers in banking, securities, insurance, telecom operators, energy, manufacturing, government, healthcare, education, and many other industries.
CloudSino
Guangzhou CloudSino Information Technology Co., Ltd. is a global leading provider of data center monitoring solutions, offering stable and reliable hardware-integrated operations management solutions for digital development across industries. With its outstanding technical strength, it has served over 900+ industry users and has always led the Chinese hardware monitoring market. In the future, CloudSino will, with greater determination, increase independent R&D investment, continuously enhance R&D capabilities, and build China's first-class IT resource monitoring and operations management products with craftsmanship, contributing CloudSino's unique technical strength to scientific and technological self-reliance, and promoting the digital development process of various industries in China.
Based on the out-of-band management platform for data center hardware devices, energy consumption data is controlled from the "device" perspective; through the analysis and application of accurately collected data, local hot spots are discovered, equipment operating temperatures are actively adjusted, dynamic environment systems are connected for precise temperature control, effectively improving the operating efficiency of air conditioning in machine rooms, reducing PUE values, thereby achieving resource conservation and low-carbon operation goals, and truly realizing a safe, smart, and green new generation data center machine room.