[Looking for Charlie's main web site? or all posts?]

Announcing ColdFusion updates of Oct 13 2026 - p2 security update, with a LOT of changes

Adobe has released another set of updates, on Oct 13 2026, for CF2025 (update 14) and CF2023 (update 26). As with other recent updates, these address vulnerabilities "that could result in arbitrary code execution, security feature bypass, arbitrary file system write, privilege escalation, arbitrary file system read, application denial-of-service, and memory exposure.."

But unlike recent updates, the update technotes for this one show a LOT of changes that you should be aware of before "just getting the update in place".

In fact, this update has so much to it that I am going to split this into two posts, this one that simply announces the update and points you to Adobe's several resources with more on the updates. Then I hope tomorrow to offer more of a "reaction" post. Apologies to those who prefer that in one post from me, but some of these updates are just too much for me to in one day a) consider carefully what they say, b) test them on multiple machines and OS's, c) watch what the community may be reporting about the update, d) helping clients who might have wanted to do the update the first day, and so on.

Finding more on the updates

The key first 2 are community resources by Adobe, where other folks may (over time) share feedback or observations about the update(s), which point to the last 2 (the update technotes) and more:

Each of the resources link to still more info about the CF updates in general and about this most recent one in particular, including downloads for the update jar file and packages zip file (for those who may need those for command-line or offline updates) as well the APSB offering security vuln details.

About the APSB, and some changes regarding it

As for the ASPB, APSB 26-144, note that it lists a whopping 32 CVEs, with 4 being rated a score of 9.9 or higher. Even so, it's classed merely as a "p2" security update.

As in past updates, that APSB also indicates that "Adobe is not aware of any exploits in the wild for any of the issues addressed in this update." To be clear, that doesn't mean you're NOT vulnerable to what it addresses.

Something else to note about the APSB is that it's formatted a little differently. Those CVE details are hidden now under a "+" sign, allowing you to expand or collapse its discussion. Note there is indeed a "expand all" and "collapse all" feature also.

One last thing of note about the APSBs comes from an email Adobe sent today to those who had registered to receive notifications about the updates. It noted first how the bulletins have a new home, https://www.adobe.com/trust/security/bulletins-and-advisories.html.

It also indicated that "Adobe is transitioning from Adobe-defined severity ratings (Critical, Important, Moderate) to industry-standard CVSS v3.1 severity ratings (Critical, High, Medium, Low), aligned with each vulnerability's CVSS score and vector string.Adobe Priority ratings (1, 2, and 3), which communicate our assessment of exploitability and patching urgency, will remain unchanged."

Much more to note, in the update technotes

Again, I plan to offer more tomorrow. Let me offer just a couple of quick points:

  • Like many CF updates, this one does update the Tomcat embedded within CF server installs: the update for CF2025 now implements 10.1.60 and for CF2023 it implements 9.0.122. (That said, Tomcat implements changes very quickly, so within days CF will almost assuredly again be found to be "behind".)
  • And like most other recent updates, this one addresses important changes arising from the new security protections (where Adobe has traded compatibility for security), as well as available mitigation options (mostly JVM args) where you can reverse that, to trade security for compatibility.
  • In particular, see the sections on the major new "Outbound network security policy", the dozen "Security changes that require action", and about a dozen more subsections addressing different changes. Again, this one is a bit of a whopper--though most of these "dozen more subsections" are on rather obscure features that may not have been used by most devs.
  • Finally, there are several "known issues" and "bugs fixed", including a couple introduced in last month's CF2023 update 25, which kept CF from starting under two circumstances.
  • As for still other issues, see the "updated info" at the bottom of this post

As with each update we must balance the urgency of the update (for the security protections) against the potential changes in compatibility, along with the available mitigations (which would re-open a door that Adobe is closing in this update). Whereas normally there's not ever enough detail in the information provided to assess that, this update's technotes do contain quite a but more info (though still not as much as seems warranted on some points.)

Experience so far...

There are a couple of things to report on this first day of the update.

First, as for discussions in the community of issues with the updates, there was not much in the two primary Adoe resources linked to above.

Second, there was a CFML Slack channel thread reporting that for CF2023, its default "packages url" (https://www.adobe.com/go/cf2023_packages, which redirects to and downloads the bundlesdependency.json file at https://cfmodules.adobe.com/cf2023/bundlesdependency.json) was NOT returning any references to today's update 26 (2023.0.26). And as such, while performing a CF update would update the "core", it would not update the packages. Even worse, some found many of their packages unexpectedly uninstalled. That problem with the json file seemed to have been resolved by late night of the first day (as an update, people are still reporting it off and on into the second day).

Third, I'll share also that I found on the first startup of CF after each update that I had the following error in my coldfusion-out.log (though it did not prevent CF from starting):

Cannot invoke "coldfusion.util.PasswordUtils.getSeedValue()" because the return value of "coldfusion.util.PasswordUtils.getInstance()" is null

I found that on restarting CF, the error did not appear again (and this was whether I had or had not cleared the felix-cache folder.)

As I learn of any other significant ramifications of this update, I may offer comments below, or an update to this post, or again I plan to do another post tomorrow with more on the many things discussed in the update.

Finally, I can say that I have applied the update on both versions, on multiple machines and different OS's, without any trouble during the update (once I confirmed that the Admin UI showed there were package updates available: I waited for that with this update of CF2023 due to the above observation).

I've also confirmed that the downloadable zip of packages offers the updated packages indicated in each update technote (there have been recent occasions where the zip did NOT include the updated packages).

Getting help, from me or others

As always, if you have need of assistance in applying or dealing with the ramifications of the update, note first that you can use those community resources above to seek help publicly.

Or I am available for remote screenshare consulting. I can usually solve most update-related problems very quickly, since I help so many people with them in each update (whether publicly or directly). See carehart.org/consulting for more on my rates, approach, satisfaction guarantee, online calendar, and more.

Updated info, since the original post

Here are some updated info since the original post, things which I learned of in client engagements, comments below, the community, etc.
  • Oct 16, 2026: There have been a couple of issues related to regular expressions (regex/regexp) that have been tracked as tracker tickets but not yet tracked as "known issues" in the update technotes. See CF-4234762 and CF-4234761. For more, see another update below of Oct 19. (If those report "no issue found", that's a bug in Tracker. It's NOT that the tickets have been deleted but instead that tracker is temporarily not working and fails to identify that correctly.)
  • Oct 16, 2026: Elaborating further on a point I made in the original post, there was a problem in the first couple of days after the release, where sometimes the CF2023 bundlesdependency.json file downloaded from Adobe's site (https://www.adobe.com/go/cf2023_packages) was sometimes including references to package updates for update 26, and then suddenly it did NOT include the references. As such, someone running the update while it FAILED to have the updated package references would have trouble, which might even lead to the packages being uninstalled and not updated/not reinstalled. That problem seems to no longer be happening as of today, Oct 16.
  • Oct 19, 2026: Adobe has offered a fix for some (not all) of the regex problems mentioned above. See an updated hotfix jar made available by Edwin at Adobe, in the tracker ticket at CF-4234762. See also comments from others there.
  • Oct 19, 2026: The container images are available for this update, as of today, at the Adobe CF repos at dockerhub and AWS ECR
  • Oct 21, 2026: Beware of the impact on CF scheduled tasks of thus update's new "Outbound network security policy". You may find that some (or all) tasks just stop working, without any indication of anything amiss in their listing in the CF Admin UI. But you may see errors in the CF logs, like the scheduler.log, which may report for example, "This scheduled task URL is not permitted by the outbound network security policy." The problem seems limited to only tasks calling urls on the local machine (which may surprise those who presumed "outbound" would mean "to off the server").

    I'd been letting this percolate in the comments but forgot that I'd not mentioned it here in the post. Fortunately, in the meantime Gregory Alexander created a helpful post on the matter, and has also commented below, on top of other helpful observations from others and myself.

    Bottom line: if you're hit with this and struggle to resolve it, note that you have choices (beyond uninstalling the update): there is the new allowlist or related blockLinkLocal and blockPrivateNetworks booleans which you can set in the update's new security-settings.json file discussed above, or you can use the new ssrf jvm argument, all mentioned briefly in the post and elaborated upon in the update technotes.

    (Note finally that while the scheduled task error message goes on to suggest application.cfc settings as another means to control things, that's incorrect. Scheduled task processing does NOT pay attention to application.cfc, not even that of an "application scheduled task". See more in my comments below of 10/16/26 2:09 PM.)


For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
Any word if this new patch fixes the fusion reactor bug from the last patch update 25?
# Posted By Michael | 10/14/26 11:58 AM
Yes, it does resolve this (and FWIW it affected not just those using FusionReactor but any tool leveraging the java instrument library--due to a cf bug on Windows only that I identified to be a path truncation issue, discussed at https://www.carehart.org/blog/2026/9/29/solving_new_cf2023_update_25_startup_problem/.

This bug being fixed is one of the many things I was alluding to when in my past I said I had much more to say, and might offer a new post. But more news keeps coming in, and it's a lot to synthesize and (find the time to) regurgitate.

At least comment covers (to a degree) this one matter. I'm sure soon there may be comments from others on still more.
We found this update stopped all scheduled tasks from running and filled the scheduler.log with:

This scheduled task URL is not permitted by the outbound network security policy. To allow this connection, add it to outboundNetwork.allowList in security-settings.json or to this.security.outboundNetwork.allowList in Application.cfc.

We had to open the security-settings.json file and enter an array of the various addresses we use into the "outboundNetwork" key.

Would think a page might be created in the CFAdmin for such entries?
# Posted By Paul | 10/14/26 3:54 PM
Paul, it may have been "all tasks" for you, but folks shouldn't conclude that this update will break "all scheduled tasks". I have some that have not stopped.

If folks look closely at that section on "Outbound network security policy", it discusses how this all works, and by default affects only local calls (not remote ones, which may seem backward to some).

You would also see you COULD have just changed either the blockLinkLocal or blockPrivateNetworks value to true, instead (or even added the jvm arg for ssrf to revert the entire network access protection behavior.) See the update tech notes for more.

Of course some would not want to do that, as they'd see Adobe is trying to close down the free reign CF has long had to call just about anything (unless you locked it down with a firewall or other security software).

The point here is that you have choices. I agree it's a frustrating change of behavior. I warned of it in the post, and the technotes have more to consider than about any in the past.

If you feel I somehow "have this wrong", I'm open to feedback of course.
I successfully applied 2023.0.26 to two of three non prod servers today. The third one was complaining about packages, and I noted it was installed packages with version 2023.0.25.

When i checked the packages URL: https://cfmodules.adobe.com/cf2023/bundlesdependency.json

It does appear that 2023.0.26 packages are missing. This must have occurred in just the last hour or two because the first two servers successfully downloaded 2023.0.26 packages:

Here's a count of packages and versions as of 2249Z on 10/14/2026

Count Name
----- ----
54 2023.0.0.330468
54 2023.0.05.330608
15 2023.0.07.330663
6 2023.0.08.330668
30 2023.0.11.330706
1 2023.0.12.330713
4 2023.0.13.330759
9 2023.0.14.330784
16 2023.0.15.330825
1 2023.0.16.330828
12 2023.0.17.330864
5 2023.0.18.330879
3 2023.0.19.330899
5 2023.0.20.330909
6 2023.0.21.330920
3 2023.0.22.330928
6 2023.0.23.330940
5 2023.0.24.330957
32 2023.0.25.330977

I've opened a ticket with cfsup@adobe.com
# Posted By Joseph Cunningham | 10/14/26 5:51 PM
Yep, I'd mentioned the issue in the post last night, and it's been happening off and on (for some, not others) since early yesterday, the day of the release. No harm in another person bringing it directly to Adobe's attention.

In the meantime, you can do the manual offline install approach discussed in the technote. That relies on a json file found in the zip you'd download. I haven't heard anyone say THAT json file failed to be updated for u26 packages.

And no, I can't fathom how one file would always be correct while another would inconsistently be incorrect.
The manual offline install approach is a good fall back, but requires modifying CF configuration, which i would prefer not to do. I would prefer the upgrade process to work the same every time, without having to adjust configurations in CF admin.

I built a web app on CloudFlare to monitor bundlesdependency.json on adobe's website and track when bundles are added/removed or versions change. Looks like sometime between 0800Z and 0830Z the 2023.0.26 versions showed back up.
# Posted By Joseph C | 10/15/26 9:57 AM
I'm with you Joseph, but I can only commiserate. I have no "in" with Adobe to force or even further encourage resolution. I've taken up the dialogue in many places. Nary a response, as yet. Again, I can't explain it. (As a lifelong Commanders fan--WFT, 'skins, this feels like the catastrophe of last week, widely derided by NFL observers. And yes, I realize that's a comment that won't age well here.)

To be clear, I offered the workaround for those unaware, feeling stuck. Otherwise, we wait.

Excellent to hear about your tool. Is it available in any way publicly? I'm sure some would appreciate it. Also, have you found the "updated info" coming and going, like I have, over the past couple of days?

Someone will ask, "could you just provide a link to one that's guaranteed to be updated?" And surely someone could offer that, but then it would need to be KEPT updated, if Adobe might at some point update then file BETWEEN cf updates, let alone updating it WITH any cf update.

And the latter would be demanded by many to be done IMMEDIATELY after any such subsequent cf update. It's the very fact that Adobe's url for the remote json file has sometimes NOT reflected the latest update which is at the root of the issue. Anyone else "taking the ball" can't fumble it, and woe be to them if some caching between them and users delays that immediate delivery.

We'll see how things play out. Again, even an obvious win can be botched by a failed play call. And sometimes that can seem clearly to be finally a fireable offense...but fans can only look on and comment. It's ownership who decides such fates.
Like previous commenter Paul, I had scheduled tasks stop working because of this.

The Application.cfc setting doesn't work.

The json file, if I even expected it to work as documented, probably wouldn't be good enough. I'm guessing it's only read once per server startup, which means a potential restart any time a scheduled task is added (to a different host) in the future.

The only way forward for me is to disable this whole dumb feature.

I don't need to be protected from my own scheduled task configuration anyway.
# Posted By Alan | 10/16/26 8:47 AM
Alan, first no, the app-level solution would not be a workaround as the execution of scheduled tasks (even "application" ones) doesn't consult the Application.cfc/cfm first. (And yes, I see that the error reported for such a failed sched task suggests both the server-level and app-level config tweak. It's simply wrong about the app-level one, from my testing at least.) Such whitelisting WOULD need to be done in the server-level file.

And you raise a good point: CF definitely does NOT read that server-level file until CF is restarted. I have tested/confirmed it.

All that said, note that folks have a couple of possible options beyond "having to whitelist every URL that a scheduled task may call". And I realize you said instead, "a potential restart any time a scheduled task is added (to a different host)".

First let's clarify that if the URLs (for the tasks) use 127.0.0.1 or localhost, one could choose instead to enable the server file's setting, "blockPrivateNetworks": false. We might think it was blockLinkLocal that should be set to false, but I tested it and it's not so.

Second, when specifying a URL in the allowlist, note that the technote indicates "An entry with no path, or with a trailing /*, matches any path for that destination." So if all the URLs you call in sched tasks were always in some folder, you could just provide the URL up to that folder name.

Perhaps you were referring to either of those in adding "(to a different host)", and fair enough.

Also, folks need to pay attention when tweaking that server file (the new security-settings.json, such as in cfusion/lib): note that if you make a mistake in that, all you do in there could be ignored (and the defaults CF imposes will take effect).

Any error in that file will be reported at startup in the server.log. It could be a syntax error, like using // for comments (not allowed in that json file), where at startup there will be an error starting "Failed to load security-settings.json — all settings will use coded defaults" and some more detail.

That said, if you make a mistake in the allowlist (or denylist), like leaving off the http:// or https://, it will show an error (in that log) not at startup but when that list is consulted (like running a sched task), when that log will show an error like:
"OutboundUrlAllowList: skipping malformed outbound-URL allowlist entry [localhost]: missing scheme"

I know this is a lot for a comment. As I'd said when I created the post I had lots I was gathering and meaning to blog about. I am offering this bit now given Alan's comment.

I know the changes are frustrating (to some, while others have made the move easily). It's all done by them for the sake of security. We may not like it, but it's "for our own good" as the saying goes.

And of course, there are the server settings (and app settings) and even the jvm arg that can tweak how things work. It's just going to be a long learning curve...because sadly many will not be implementing the updates for some time, and later some will move from CF2021 or earlier to 2023 or later and only then encounter these major new changes.
Hey, Alan, if you may have gotten emailed my last comment, I hope you'll see this one before responding. I tweaked the 3rd paragraph to better clarify what I was responding to about what you'd said.
I also wanted to add one more comment in reply to Alan's previous one here (but I wanted to get that last one out ASAP, before he may reply to some wording I'd made that deserved my correction.)

He concludes saying, "I don't need to be protected from my own scheduled task configuration anyway." I'd like to address that.

CF has long been subject to vulns where somehow a bad guy could CREATE a scheduled task (unexpectedly), and than have the running of that task do something unexpected (like create a file via the "publish output" feature of the task), but really ANY unexpected task doing ANYTHING would be a concern. As such, over the years there have been different things added to CF to make their execution more secure. This is just another.

I get it that we may think "our servers are protected" or "no one can get in from the outside" and so on. But we can't know what we don't know, about how some new vuln might again allow creating of sched task unexpectedly--that could then do something untoward.

Let me be clear: I don't work for Adobe, and they don't consult me on any of this (I also get no early access to the updates or the docs for them).

As always, I'm just trying to help.
Gregory Alexander has done a post with more on the negative impact on some scheduled tasks, and he acknowledges some of the discussion here. See his post:
https://www.gregoryalexander.com/blog/2026/10/18/coldfusions-october-update-quietly-stopped-my-scheduled-tasks
Hi Charlie,

I got bit by the scheduled tasks (all ours operate against local code).
After getting confused by the message in the scheduler log, getting frustrated at my changes in the application.cfc not taking effect...
(we have app.cfc in our tasks folder)

The light bulb went off - you're correct that for scheduled tasks you must allow [protocol]127.0.0.1[port]/[tasks-path] not because there's no Application file - there is, but you likely don't Want to edit it, even if you could! It's for the Administrator app.

I'd been thinking backward, that I could update the application.security.outboundNetwork structure on the target files rather than the source/origin of the loopback requests.

So since I have allowed scheduled tasks folder at the server level, I must also put a corresponding denyList entry on all other applications via App.cfc.

Cheers!
# Posted By Tom | 10/18/26 9:53 PM
It seems you're still concluding you need to change application.cfc for scheduled tasks. My testing indicates that you don't.
And to be clear, the new network security protection is indeed ONLY for outbound requests. It has nothing to do with processing of the application.cfc for a cf template that is CALLED as a scheduled task.
It appears that there are some jar files that have magically appeared without commentary on the RegEx bug submissions in Adobe's Bug Tracker:

hf20230005756.jar
hf20250005756.jar

Guess I'll go ahead and guinea pig myself. :)
# Posted By Kevin | 10/19/26 8:02 AM
Confirmed that dropping the version-appropriate jar file into my ColdFusion<version>/<instance_name>/runtime/lib/updates folder and restarting the instance has resolved my particular RegEx backreference issue (and likely others).

It did leave a copy of the new U2 album on my server without consent, however.

(kidding)
# Posted By Kevin | 10/19/26 8:16 AM
I spoke too soon.

The RegEx "fix" resolved one issue with backreferences but still fails upon additional testing.

I do not recommend relying on the fix at this point. Details/example can be found in the 2 tracker bugs listed by Charlie.
# Posted By Kevin | 10/19/26 10:18 AM
Reflecting on the scheduled task difficulties, especially the fact that the scheduled task launcher has no relationship with application settings, leads me to more questions.

Why am I using CF scheduled tasks at all? If they're just sending http requests from their own isolated environment, why can't I do that from outside CF? Does the CF task scheduler do something that cron and wget can't do?

If I can stop using CF scheduler, and disable the creation of tasks in it, then I don't have to worry about its security policies ever again.

Well, now I'm off to check a few hundred REFind and REReplace calls to see how many of them broke in the same update that killed my scheduled tasks.
# Posted By Alan | 10/20/26 8:37 AM
This is an anecdotal comment to address my thoughts on what feels like an all-too-common "cross your fingers" apprehension that has been building when applying CF updates over the last 2-3 years.

I've been with the same company working on the same CF-based application since the turn of the century. We're a small shop and we wear many hats. At the time when I came on board, my job was 90% dev and 10% everything else (server/network/security/etc...). Those were the Wild West days of the internet.

Now? I'm lucky if dev is even 10% of my role. Security has become such a critical component that it directly or indirectly consumes the vast majority of my time just to stay on top of it. The overhead at our company, as a result, has skyrocketed.

At a recent NIST seminar, the overwhelming vibe that I got from the speakers was FUD. Fear for Quantum. Fear for AI. These experts offered some solace in small doses but it was largely shadowed by the absolute lack of confidence as to how the next decade would play out.

Now, putting myself in the shoes of Adobe, I can imagine that they, themselves, have been forced to transition from purveyors of software to reluctant security stewards. I can imagine that, like myself, they've gone from a large focus on moving their product forward to having to spend copious amounts of resources on ensuring that it provides us end-users with as much protection against these growing threats as possible.

I do not envy them. And, as much as I complain about being Patient Zero on bugs at least once every 3-5 updates, I can imagine that they would prefer to go back to those innocent early days as well. Their increases in licensing fees are almost certainly simply going towards covering the increase in their red tape.

Moving on from CF would not make these threats go away and I appreciate that Adobe is still working diligently on our behalf, in spite of where their preferred time would be spent.

Again -- my thoughts from my experience. YMMV.
# Posted By Kevin | 10/20/26 9:04 AM
We didn't get this issue going to 25, but it is there in patch 26.

This scheduled task URL is not permitted by the outbound network security policy. To allow this connection, add it to outboundNetwork.allowList in security-settings.json or to this.security.outboundNetwork.allowList in Application.cfc.

We had to add 127.0.0.1 to get the patch checker to work again and the url for the server to get it to call a task.

We added the URLs to security-settings.json and it resolved it.
Ripley, that was one option, but not your only one. To quote a comment I made above the day of the post (when someone else struggled with the allowlist for local urls being requested):

"If folks look closely at that section on "Outbound network security policy", it discusses how this all works, and by default affects only local calls (not remote ones, which may seem backward to some).

You would also see you COULD have just changed either the blockLinkLocal or blockPrivateNetworks value to true, instead (or even added the jvm arg for ssrf to revert the entire network access protection behavior.) See the update tech notes for more."

I'm highlighting here that blocklinklocal, which many are missing or misconstruing. Hope that helps.

And yes, I do realize there are a lot of comments to wade through here, for those inclined to consider them. I'm still hoping to do a follow up post. Lots to consider, to avoid another wall of text.
Thanks for the mention, Charlie, and for all the detail in this thread. It's what got me unstuck. One more variation for anyone still searching: my tasks used a public URL, not localhost, and were still blocked. The server's hosts file points the site's own domain at 127.0.0.1, so the outbound policy treated it as a private address. What worked was allowing both forms, with no trailing slash: `https://mydomain.com/path` and `https://127.0.0.1/path`, then restarting ColdFusion. And the tasks kept saying "Active" with a next run time the whole time they were being refused, so scheduler.log was the only place it showed.
# Posted By Gregory | 10/21/26 8:17 PM
Thanks, Gregory. As I've noted to others, while the allowlist is one way to go, another is to consider setting either the new setting for blockLinkLocal or blockPrivateNetworks to true. I'm not saying that's always the right way, but when folks struggle with the allowlists it's an option short of using the SSRF jvm arg to disable the entire new security policy feature (or uninstall the update).

And yep, it's super frustrating that this issue doesn't reflect in clear warnings or even indications of the tasks being disabled in the UI. Thankfully it does writes lines to the logs (more than just the scheduler.log, though--that's duplicated into the coldfusion-out.log, and some other related issues show up in still other logs), but most people honestly don't watch them carefully.
Kevin, thanks for your last few comments. Apologies for the delay in responding. I was traveling these past couple of days and so only able to take care of SOME responsibilities/respond to SOME comments.

You make a great point about how Adobe has their work cut out dealing with increasing rates of reported vulns, which only makes their and our jobs harder.

Sadly, it's the way of the world now: AI makes it easier to find and report vulns (and Adobe and other companies offer bug bounties, which incentivizes reporting by good guys).

But then AI also makes it easier for bad guys (or responsible good guys) to reverse-engineer updates ASAP, which can allow bad guys to perpetrate vulns even sooner against servers of those who are delayed in applying updates.

And this goes beyond CF, of course. Some may have heard about the big PHP vuln of recent days. But then even OS's (not just Windows) and Java and other software are reporting record number of vulns being fixed in their recent updates.

Tough times ahead for us all, I fear.
Alan, to your note of yesterday morning, you had wondered whether one could just skip using CF scheduled tasks entirely. That's indeed true.

Do they add things "that cron and wget can't do"? Yes, and no. For some, those (or the Windows Task Scheduler) could suffice. It's just different, in ways some will find appealing and others not so much.

For more on what CF Scheduled Tasks can do for you (beyond reading the Admin UI--and its "advanced settings" for them--and the CF docs), I'll note that I had done a talk on them a couple of years ago, "CF Scheduled Tasks: there's more than you may know". The description and PDF AND recording are available on my presentations page, specifically at:
https://carehart.org/presentations/#schedtasks
Copyright ©2026 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the HTML in this page?)

Managed Hosting Services provided by
xByte cloud Hosting