Copy link to clipboard
Copied
Sorry to be posting questions so frequetly...
With CF2023 update 17 comes a few new questions. The related note says, "From this update, ColdFusion blocks all class deserialization by default... Classes not on this allowlist are blocked, and an error is logged advising you to add the relevant class or package to serialfilter.txt if you wish to allow it." Oddly, the destination linked-to in the description of "Serialfilter" from that page says "From Update 5 onwards...
ColdFusion blocks all class deserialization by default." If the change was implemented in Update 5, then how does update 17 differ?
My bigger question is this... Not being a Java coder, and assuming Adobe doesn't expect CF coders to know what Java deserialization is, I need to ask, are there Java classes that do not "deserialize"? I have a .jar file in cfusion\wwwroot\WEB-INF\lib. With update 17 installed, the class performs fine with no updates to serialfilter.txt. Can I assume that it doesn't error because it doesn't "deserialize"?
Is there a way to proactively search our codebase for classes that deserialize? I would think this would be preferrable to a "run your code and fix whatever breaks" methodology.
Hi @Dordrecht ,
The "Update 5" in the Serialfilter documentation you link to refers to ColdFusion 2025 Update 5. That's the CF2025 update that corresponds with ColdFuson 2023 Update 17, which were both released with Adobe Product Secuirty Bulletin APSB25-105.
Yup - there are lots of Java classes that don't "deserialize". If you're adding your own Java libraries to ColdFusion, you could start by reviewing your Java code for calls to readObject() and writeObject(). And while it would be reacti
...Copy link to clipboard
Copied
Hi @Dordrecht ,
The "Update 5" in the Serialfilter documentation you link to refers to ColdFusion 2025 Update 5. That's the CF2025 update that corresponds with ColdFuson 2023 Update 17, which were both released with Adobe Product Secuirty Bulletin APSB25-105.
Yup - there are lots of Java classes that don't "deserialize". If you're adding your own Java libraries to ColdFusion, you could start by reviewing your Java code for calls to readObject() and writeObject(). And while it would be reactive, your best bet might be to just watch the server.log, exception.log and wddx.log log files (outlined in the Serialfilter doc) for blocked occurances of deserialization.
Copy link to clipboard
Copied
Thank you, @Brian__ !
Copy link to clipboard
Copied
@Brian__ has answered the original questions. I have some addtional answers.
The Java classes that commonly involve deserialization are any classes that:
Common examples are:
These are already covered by Adobe ColdFusion's internal allow-list, so they'll rarely, if ever, cause issues by themselves. In fact, when you install or update ColdFusion, all the Java classes that it uses are included in its internal allow-list. So there's really no need to proactively search your codebase for classes that deserialize. Unless, as @Brian__ mentioned, there are error messages about serialization in the logs.
Get ready! An upgraded Adobe Community experience is coming in January.
Learn more