CF 2023 HF 17 issue

The error seems to be caused by:

• initialization failure in the Oracle driver, due to Java 17 incompatibility or classpath conflicts.

Are you using just one OJDBC driver? If so what is its version, and is the version compatible with the Java version in ColdFusion 2023 Update 17?

Are there multiple driver Jars on the classpath (for example, resulting from Update 17 adding additional Jar)? 

Jack/Wolfshade, while someone may well offer a "simple solution", I have a few thoughts, including additional diagnostics to consider, and a POSSIBLE solution for you--but it takes care to implement it correctly.

And yes, it IS important that you get the update in place, as there are known attacks that seem to be exploiting servers that have not been updated. More on that in a moment.

So first, you have not indicated what update you came from (and now have reverted to). Can you let us know? That can be as important as knowing that you were attempting update 17 of 2023.

Second, are you 100% sure there were no errors in the applying of the updates? None indicated in the update log (in the hf-updates folder for your applied update 17), and none during the startup of CF after that (which is when package updates happen)?  I realize you may not have your logs to check (more in a moment), but if you do the update and still get the error, be sure to check those then before doing anything else. That may be all that was amiss, and it may be unique to your situation rather than something generic.

But it may well be that your problem is of a newer variety, that COULD be specific to this latest update, and an important change it made (for our protection). For that, I have several more things for you (and other readers here) to consider.

1. You shared what you got as alerts. It would be helpful to see what was tracked in CF's logs. I know you said you restored from a backup: do you still have ANY copy of what WAS in the CF folder (or logs, specifically) from before the restore? If so, look in the server.log and (if there is one) the wddx.log.
   
   
2. Do you see any log messages in those which match the time of the alert (for what you presume is a legit request by your users)? If so, they may have more detail about one or more of the the java classes being "blocked" for "deserialization".
   
   
3. Note that the latest CF updates (from December 2025, which is your CF2023 update 17 as well as CF2025 update 5 and CF2021 update 23) did change CF to by default block ALL "deserialization" by java classes, unless the java classes doing it were whitelisted (listed in either a serialfilter.txt or cfserialfilter.txt file, depending on which type of deserialization was being done--and thus in which log the error was tracked). 
   
   
4. An interesting question may be why your code would be leading to an attempt at such "deserialization". Many are confused about this, and there's relatively little being shared. I'll offer more later in my reply. But it seems a simple cfquery (since you refer to the line pointed to being a cfqueryparam). That alone should NOT be leading to such an error--which is why I started with my earlier question of whether you maybe had an error simply in the applying of the update.
   
   
5. Anyway, note that the CF docs has a page discussing those two "filter" files, as well such errors and this change of behavior. (The doc page refers only to "update 5"--which again is what the number was for CF2025--but the matter and that doc page applies as well to CF2023 and 2021.) It's at https://helpx.adobe.com/coldfusion/kb/coldfusion-serialfilter-file.html. 
   
   
6. Beware also that it's unclear if you really need to use the "patch" listed there (for CF2023 and 2021) to cause logging to the wddx.log. That doc page was from at least 2024, when there's mention of a revision to it that year--and a couple of times since. This is why I asked you to just look and see if you DO have such a wddx.log. You may not, but that may simply be because the problem you had was of the type logged instead in the server.log. (I realize this can confuse casual readers of this reply. Read the doc page and it may make more sense.)
   
   
7. It's certainly interesting that you tried first to uninstall update 17 and things still failed--which forced you to restore from a backup.  That could well just be a failure during the update AND the uninstall of the update. But back to this deserialization matter, it would be interesting (besides knowing what update you have reverted to) to know what you may see if you compared your current serialfilter.txt and cfserialfilter.txt files to those which were in place before you did the restore, to see if those changed and how. This again is why I asked if you had access to that. If the problem is you have NO such copy of the files before the restore (and can't arrange it), then please consider noting what you have now in those files, and when you try the update (whether it works or not), then consider comparing the old values to the new ones before you may "restore again". That may be important to understand, if it takes time for you to get back to us and us to get back to you.
   
   
8. As for a possible workaround, a first idea would be to look at those logs to see WHAT class (if any) is logged as being "blocked" for "deserialization". If it's at the time of a legitimate request, consider adding the class to be whitelisted.
   
   
9. Note also that since your code is doing a query, it's perhaps worth noting that you may well find the wddx.log referring to com.sun.rowset.JdbcRowSetImpl. The doc page happens to refer specifically to that, when it says: "Due to security reasons, com.sun.rowset.JdbcRowSetImpl is blocked for deserialization. Add the class or package in the file:

   cfusion/lib/cfserialfilter.txt". But I'm proposing you only add that if you find the error at the time of what you regard to be legit requests that are failing, given that CF vuln attack I referred to above--and about which I'll have more to say in a moment.

    

10. As for "where to find these filter txt files", note that the doc page refers to them being in cfusion/lib. That's a bit lazy. if you happen to be running "multiple instances" of CF, you would have a sibling folder to that "cfusion" one which would have its own lib folder, and its own cfserialfilter.txt file.  Again, if the error is logged in the server.log, then this would seem to be not about "wddx deserialization" but instead just "java deserialization". In that case, it's not the cfserialfilter.txt but instead the serialfilter.txt file that you would want to consider modifying. Just be sure to edit the RIGHT file (depending on the error) in the RIGHT folder. (And you must restart CF for the change to take effect)
    
    
11. FWIW, that doc page shows what the default values are for the cfserialfilter.txt file but currently it does NOT show what's in the serialfilter.txt. I can report what I find for my current CF2023 update 17 (and it's the same CF2025, not only since update 5 but I can see the file was created and unchanged since when CF2025 was released in Feb). The file's contents are (as a single line):
    !org.mozilla.**;!com.sun.syndication.**;!org.apache.commons.beanutils.**;!org.jgroups.**;!com.sun.rowset.**;!com.mysql.cj.jdbc.interceptors.**;!org.apache.commons.collections.**;
    
    
12. I bring that up because if in fact the error logged for a legit request may refer to that com.sun.rowset.JdbcRowSetImpl, note that the default serialfilter.txt file values there DO in fact show it being blocked for deserialization, by the value of !com.sun.rowset.**. The ! there means "deny" (which was done used before this latest update, which now instead blocks deserialization by ALL classes unless whitelisted). But to be clear this means that ANY class within that com.sun.rowset package is specifically denied, which would include this com.sun.rowset.JdbcRowSetImpl.  And I'm wanting to clarify that if you were to just add that classname to the end of that list, that would NOT make things work, because later in that doc page it explains how the order of things is important--with the first things overriding any subsequent ones. As such, one doing this would want to add that com.sun.rowset.JdbcRowSetImpl; to the FRONT of that list (note the semi-colon, used to separate values). 
    
    
13. Don't JUST add that argument, though, if that class is NOT identified as the class in error in the log AT THE TIME of a legitimate request that failed. Again the key is to find WHAT class IS identified in the log AT THE TIME of a legit request. If you instead just add "whatever classes are logged for being blocked", you may be finding log lines about classes that were blocked FOR GOOD REASON, if the requests were made by bag guys. Again, more in a moment.
    
    
14. If you don't have the logs to confirm things from before, do the update, THEN make even ONE request to cause the error, then see which log it's tracked in (if any). Then make the change based on that finding, then restart CF and try again. If it still fails, check both logs to see if perhaps another class is now being blocked. (No, one should NOT need to go through all this hassle. Things SHOULD just work. But let's hear what you find.)
    
    
15. Finally, the reason to be all the more careful is that attack I referred to at the top. It was documented JUST YESTERDAY here: https://www.esecurityplanet.com/threats/2-5m-malicious-requests-hit-adobe-coldfusion-and-others-in-holiday-attack/. And note that it, too, does SPECIFICALLY refer to how the "The ColdFusion attacks leveraged WDDX deserialization flaws to trigger JNDI and LDAP injection, targeting the com.sun.rowset.JdbcRowSetImpl". That is why, for now, those who HAVE updated CF should be protected, because ALL classes doing deserialization (or either type, java or wddx) are now blocked by default as of this last update. And even those on previous updates were protected at least from java deserialization by this class (by the blacklisting in in the serialfilter.txt), though for now it's unclear to me when that started.

All this stuff about deserialization (of either type) is indeed frustrating, for us as well as for Adobe trying to protect us. BTW, it's not new. There were previous deserialization vulns (fixed by previous CF updates), as reported by Brian Reilly in 2024. He also did a post in 2023 about such deserialization vulns found (and fixed) affecting Lucee.  The bad guys are always trying to get a step ahead of Adobe (and Lucee). And it's our task (as users of the engines) to stay updated to get the protections as they add them. But sadly those protections can hurt us, or discussion about them can "get in the weeds" and leave a lot of folks confused. Hey, I may even be confused about something. (It's even possible that your issue has NOTHING to do with deserialization, as I hedged at the open.) As always, I welcome feedback.

Sorry for the blog post-length reply. If this stuff was easy, it could be answered in a tweet-length reply. But clearly things can be more complicated, with multiple possibilities and different solutions. Hope this helps someone. Let us know how it goes for you.