Copy link to clipboard
Copied
We are pleased to inform you that we've released security updates for ColdFusion 2025, 2023, and 2021 releases. For more information, see the respective tech notes:
Adobe ColdFusion (2021 release) Update 23 marks the end of core support for ColdFusion 2021 update releases.
Adobe ColdFusion (2021 release) Update 23 is the final update, as this version reached its end of core support on November 10, 2025. After this update, no further core updates will be provided for this version.
What's new and changed
The updates includes important security fixes that mitigate vulnerabilities related to arbitrary file system write, arbitrary file system read, arbitrary code execution, and security feature bypass. The updates also include:
View the tech notes and security bulletin, APSB25-105, for more information.
Download the updates
Docker and CFFiddle
Please download and apply the updates and provide your feedback.
Copy link to clipboard
Copied
Thanks Saurav. And readers may be interested to hear that I did a post with more about the update (as I try to do for each update, pointing to this one and other resources as well as offering lots more info to help folks applying the update).
Additionally, if anyone seeing this applied the update and then found that the CF Admin stopped working, I’ll note that it’s a problem that some folks (myself included) experienced with CF2023 when doing the update yesterday. Technically, it's a problem that can happen with the other versions and other CF updates, where the issue is that administrator package and indeed all updated packages are unexpectedly uninstalled during the first startup but then not updated/reinstalled.
Some good news first is that there’s a solution for the problem if it happened/happens to you. Then second the problem didn’t happen in an update I did to CF2023 later/that night. So I attribute the problem to being some sort of caching issue (somewhere between my CF instance and the Adobe server sending the bundledependency.json file, which I found was lacking the updated package info).
Again, this problem has happened to others with previous CF updates, and it could happen in the future, perhaps especially to those who try to implement the update on the first day of its release. (It doesn’t ALWAYS happen–and indeed it did not happen when I updated cf2025 before that, and cf2021.)
Anyway, if you’re interested in hearing more about the issue (including how to diagnose and resolve it), see my post on that, which followed the one above. And try to keep it in mind if you apply a future update on the first day or two, and find that updated packages are unexpectedly uninstalled after doing the update. (This is not to discourage you doing the update the first day--just info to be aware of, and an explanation of what may happen and how to recover.)
Copy link to clipboard
Copied
What is the syntax for referring to files for `car.associatedfiles` in pathfilter.json? Could you share an example of a completed pathfilter.json with multiple whilelisted .car files?
Copy link to clipboard
Copied
Hi,
To allow a specific path for CAR deployment, use the deploypath setting.
To allow associated files to be included in CAR files, use associatedfiles.
Below is the pathfilter.json contents where test.car and test2.car are allowed to be deployed:
{
"comments": "paths should be semi-colon seperated. To Allow a file: {path-of-file}; To Allow a directory & files in it: {path-to-directory}/*; To Allow a directory & sub-directories: {path-to-directory}/**; To Block a file: !{path-of-file}; To Block a directory & sub-directories: !{path-to-directory}/**; Precedence decreases from left to right. Suppose directory A has directory B & C inside it.To Allow B & Block C: !A/C/*;A/**;",
"bytecodeexecutionpaths": "",
"schedulerexecutionpaths": "",
"car": {
"deploypath": "/opt/coldfusion/cfusion/packages/test.car;/opt/coldfusion/cfusion/packages/test2.car;",
"associatedfiles": ""
}
}
If you want to allow an entire folder along with all its subfolders, you can use:
/opt/coldfusion/cfusion/package/**
Thanks,
Rochelle
Copy link to clipboard
Copied
We are seeing the following error in 2021 HF 23:
Due to security reasons, coldfusion.scheduling.ScheduleTagData is blocked for deserialization. Add the class/package in the file cfusion/lib/serialfilter.txt to override the behavior and allow deserialization.
Accoring to the docs - https://helpx.adobe.com/coldfusion/kb/coldfusion-serialfilter-file.html
coldfusion.scheduling.ScheduleTagData; is a default allowed package.
"By default, the packages that ColdFusion allows for Wddx deserialization are:"
java.util.Locale; java.util.Collections$EmptySet; java.util.HashMap; coldfusion.server.ConfigMap; coldfusion.util.FastHashtable; coldfusion.saml.SpConfiguration; coldfusion.saml.IdpConfiguration; coldfusion.runtime.CaseSensitiveStruct; coldfusion.scheduling.mod.ScheduleTagData; coldfusion.runtime.ArgumentCollection; coldfusion.util.CaseInsensitiveMap; coldfusion.runtime.AttributeCollection; coldfusion.sql.QueryTable; coldfusion.archivedeploy.Archive; coldfusion.scheduling.ScheduleTagData; coldfusion.osgi.to.ScheduleTagTO;
Why are we getting this error?
As a result, clustered tasks are not working.
If we add the class to the serialfilter.txt (not cfserialfilter.txt - its already in this file) the issue is resolved. I assume this issue is a bug?
Copy link to clipboard
Copied
Since applying the updates (both 23 on CF2021 standard and 5 on CF2025 standard) I'm unable to connect to oracle data sources using a jdbc connection (I get an error java.sql.SQLException: Index -1 out of bounds for length 0). Is there a way I can fix this? I've rolled back the security update on both servers and the issue went away, but that's not a fix. Thanks
Copy link to clipboard
Copied
@pauls67473543
you can add some more informations; logs
Copy link to clipboard
Copied
@w49369461
This is no bug.
There are two distinct deserialization mechanisms in ColdFusion, each governed by a different security filter and serving different use cases.
WDDX deserialization is controlled by cfserialfilter.txt.
The default packages you referenced in your comment apply to this deserialization path.
The class coldfusion.scheduling.ScheduleTagData is required by internal ColdFusion scheduling logic and therefore has been explicitly whitelisted for WDDX deserialization.
If a class is blocked during this process, the details are logged in wddx.log, which should be the primary reference for troubleshooting WDDX-related deserialization issues.
The security changes for this deserialization flow were introduced some time ago and are not recent.
Java deserialization is controlled by serialfilter.txt.
The default allowlisted packages for this mechanism are not publicly documented, as this deserialization path is primarily exercised by third-party libraries and integrations.
In your case, the class coldfusion.scheduling.ScheduleTagData is being blocked during Java deserialization. To resolve this, the class must be explicitly allowlisted in serialfilter.txt.
The most recent updates to Java deserialization filtering were introduced in ColdFusion 2025 Update 5.
Any class blocked during Java deserialization will be recorded in exception.log, which should be used for diagnosis and verification.
Copy link to clipboard
Copied
You do not document this anywhere though. Not even in the tech notes.
This was not an issue in previous versions.
Why does a built in part of Coldfusion fail? Surely you should be making sure this part works. This should be part of your default allowlist?
I get other parts external to your core, but why would you cause just this part to not work? This must be a bug?
Get ready! An upgraded Adobe Community experience is coming in January.
Learn more