ColdFusion 10.0  -  Bug 3572565

Created on Tuesday, June 4, 2013

Login for more options


CF10 writes CFID and CFToken cookies incorrectly, causing session problems (fatal for CF9) for all other instances in domain


Problem Description: CF10 is writing CFID and CFToken cookies as DOMAIN cookies, and (apparently) ignoring the 'SetClientCookies' attribute on CFApplication. Net result is CFID/CFToken pair global to the entire domain, leading to session loss if any other CF instance (anywhere in the entire domain) is accessed. In combination with another bug found in both CF9 and CF10 (also submitted by me, number not available because it was reported as a 'security' bug), if the CF10 instance creates the first cookie for a given user, that user will not be able to establish a session with any other CF9 instance in the domain.

Steps to Reproduce:
set up the configuration described below
browse to the CF10 instance at
> view cookies in firebug
>>>> - observe that the CFID/CFToken cookies have the domain '' - '' is expected
>>>> - also observe that the cookies are NOT session cookies, as they should be (according to the CFCookie attributes)

For worst-case scenario...
now browse to the CF9 instance at
>> observe that new CFID/CFToken values were created (this is expected - first hit to 'green'
>> view cookies - observe that there are now duplicate cookies for CFID/CFToken - one set for, one for
reload this page...
>>> observe duplicate keys in CFDump output (this is the other issue I reported)
>> observe also that the CFID/CFToken values are NOT the same as the previous request - these will update *for every subsequent request*

Actual Result:
domain-wide chaos >> NOTE - the '' domain is affected by this problem - as noted in other issue - if a user's first visit (since clearing cookies) is to a CF10 instance in (so a CFID/CFToken pair exists in their cookie jar) and then attempts to access - infinite redirect [bugbase appears to not be upgraded to CF10 yet]

Expected Result: unique CFID/CFToken pairs maintained for each server name

Any Workarounds: adding '-Dcoldfusion.session.protectfixation=false' in jvm.config is a partial solution, but must be done for all CF instances in domain, resulting in substantial (and unacceptable) security risk

Test Configuration

To see the bug itself, all you need is one CF10 instance and a site with session management enabled and a fully-qualified server name (

For ease of viewing cookies, use either FireFox with FireBug installed... or Chrome

for the worst-case scenario, you will need at least one CF10 instance and at least one CF9 instance. For discussion, let's say these instances are on port 8009 (the CF9 instance) and 8010 (the CF10 instance)

Add the following entries to the 'hosts' file on the machine where your browser is running [update the IP address as appropriate so these aliases all point to the server where the CF instances are running]:

Place the following two files in an otherwise-empty directory ('test', for purposes of discussion) at the web root for each CF instance:


<cfset sessionTimeout = CreateTimeSpan(0,0,60,0)>


<cfcookie name="CFID" value="#Session.CFID#">
<cfcookie name="CFToken" value="#Session.CFToken#">

<CFOutput>hello, world<br /></CFOutput>
<cfcookie name="hello" value="hello cookie set at #Now()#">
foo = StructNew(); = "goodbye";
foo.value = "goodbye cookie set at #Now()#";
<cfcookie AttributeCollection=#foo#>

<cfdump var=#cookie# label="Cookie">


App Language(s) English
OS Language(s) English
Platform(s) Platforms All
Browser(s) Browsers All

Notes (8)

  • TParker

    12:49:47 PM GMT+00:00 Nov 18, 2013

    (sorry to take forever to follow on with further findings...)
    The work-around to the bad defaults... is to create a 'cookieParams' structure as follows... and pass it to CFApplication (assuming a CF10 instance - CF9 may complain)

    cookieParams = StructNew();
    cookieParams.httpOnly = "true";
    cookieParams.timeout = "-1"; // SHOULD be the default, but is not

    <cfapplication name="#name#" sessionCookie=#cookieParams# {additional attrs - sessionTimeout, etc}>

    the cookieParams attribute replaces the 'setClientCookies="no"' used with CF9 and earlier

  • TParker

    9:52:22 AM GMT+00:00 Jun 5, 2013

    any CF10 installation... is likely to have created permanent domain-level CFID/CFToken cookies in the cookie jars of all site visitors. Some thought will be needed as to how to clean this up (or maybe CF should simply ignore any domain-level CFID/CFToken cookies, but doing that could break some legitimate cases where sharing of session cookies is actually wanted ( and both exist on, so using the subdomain '' for the CFID/CFToken *is* legitimate in this case - so it's not correct to blindly discard domain-level cookies for CFID/CFToken

    Maybe this is too radical because many apps explicitly write their own CFID/CFToken cookies to force them to be non-persistent, but maybe now is the time to discard the dual cookie approach (any clue as to why we need TWO session tokens??) and consolidate this to a single 'CFSession' cookie??

  • TParker

    9:42:14 AM GMT+00:00 Jun 5, 2013

    oops... I just realized that the title for this issue is wrong - should read 'CF10 writes CFID/CFToken cookies **INcorrectly**

    but... further research shows that in fact the problem runs a little deeper - the 'SetClientCookies' attribute (CFApplication) is being ignored - this makes the CF10 server toxic to all other CF instances in the domain because the unwanted cookies are inappropriately created at the domain level

  • TParker

    1:59:07 PM GMT+00:00 Jun 4, 2013

    I suppose another work-around is to use J2EE sessions... not sure if I can sell it to everyone, however...

  • TParker

    12:57:20 PM GMT+00:00 Jun 4, 2013

    Thank you, Pete - your solution could work in some cases, but it unfortunately falls short in a couple of ways:
    1) it appears that putting an empty 'domain' value in the cookie params structure.. doesn't work - it seems that you have to give it CGI.Server_Name, which then produces a cookie with a domain like '' instead of the desired 'no domain given' session cookie

    2) the 'SessionCookie' attribute to CFApplication causes an attribute validation error with CF9 - so any application which needs to live with both versions of CF... will have to get creative. I suppose building an AttributeCollection struct (for CFApplication) might work, but... yuck. I suppose I shouldn't worry about readability when usability is at stake, but...

    that said... I'll play with this a bit more - this could (at least) be a way to avoid the worst of the poison cookie effects - but the best answer is for Adobe to fix the bug and do the right thing with the session cookies [which.. by the way... is to make these non-persistent session cookies and clean up the documentation and examples and such to stop giving the impression that domain-wide session cookies are a good idea or even acceptable practice. Developers should have to jump through hoops to make these cookies anything other than server-specific/session-only/http only cookies - people without explicit and well-thought-out reasons for these cookies to be anything else... should not be using domain-wide permanent cookies - the consequences are security weaknesses and hostile interactions with other CF applications in your domain.

  • Peter Freitag

    11:06:41 AM GMT+00:00 Jun 4, 2013

    This is not a fix, but I think you may be able to workaround this issue by using the sessioncookies attribute of CF10 in the cfapplication tag, or the this.sessioncookies variable in Application.cfc, see for more info.

  • TParker

    10:15:04 AM GMT+00:00 Jun 4, 2013

    see also:

  • TParker

    10:03:08 AM GMT+00:00 Jun 4, 2013

    This is mission-critical for several of our customers. Pending a fix for this problem, we are advising our CF10 customers to either delay deployment or to use CF9.0.2 instead

Duplicate ID 3593673
Reported By TParker


State Closed
Status Withdrawn
Reason Duplicate


Priority 3-High
Frequency All users will encounter
Failure Type Incorrectly Functioning
Product Area Core Runtime


Found In Build Final
Fixed In Build

Attachments (0)

No Files Attached

Votes (4)

  • askasok

    11:12:03 PM GMT+00:00 Jan 31, 2014

    Our users sessions are dropping

  • Slick RiQ

    9:13:00 AM GMT+00:00 Jan 31, 2014

    We're experiencing the same issue.

  • LeoGurl029

    9:10:04 AM GMT+00:00 Jan 31, 2014

    Losing precious time bec of this bug

  • Tariq Ahmed [ACP]

    8:00:01 AM GMT+00:00 Jan 31, 2014

    We're having similar issue where users suddenly lose their session.

Your session has expired! Click to login
Current form data will be preserved