tracker issue : CF-3544895

select a category, or use search below
(searches all categories and all time range)

Post ColdFusion Security Hotfix APSB13-10 - error on JSON returned with debug on

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Ross Phillips / Ross Phillips (ross_phillips)

Created: 04/18/2013

Components: AJAX

Versions: 9.0.1

Failure Type: Crash

Found In Build/Fixed In Build: 9.0.1 /

Priority/Frequency: Critical / All users will encounter

Locale/System: English / Windows 7

Vote Count: 12

Problem Description:
After completing the install process of the hotfix (APSB13-10) I get the following error when debugging ("Enable Request Debugging Output") is on and the response comes from a remote function whose returnformat is JSON.

Steps to Reproduce:
This is the test component:
          <cffunction name="myfunc" access="remote" returntype="struct" output="true" returnformat="JSON">
                              var st = {};
                              st["name"] = "ross";
                              return st;

Called in the following fashion:

Actual Result:

<head><title>JRun Servlet Error</title></head><h1>500 </h1><body>
javax.servlet.ServletException: coldfusion.server.DebuggingService.getShowAjaxDebug()Z
at coldfusion.xml.rpc.CFCServlet.invoke(
at coldfusion.xml.rpc.CFCServlet.doGet(
at javax.servlet.http.HttpServlet.service(
at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBas
at javax.servlet.http.HttpServlet.service(
at coldfusion.bootstrap.BootstrapServlet.service( 9)
at jrun.servlet.FilterChain.doFilter(
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringS
at coldfusion.bootstrap.BootstrapFilter.doFilter( )
at jrun.servlet.FilterChain.doFilter(
at jrun.servlet.FilterChain.service(
at jrun.servlet.ServletInvoker.invoke(
at jrun.servlet.JRunInvokerChain.invokeNext(
at jrun.servlet.JRunRequestDispatcher.invoke( 286)
at jrun.servlet.ServletEngineService.dispatch( 543)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.ja va:203)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.j ava:428)

Expected Result:

Any Workarounds:
None other than not installing the hotfix or not using debugging output when developing.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3544895

External Customer Info:
External Company:  
External Customer Name: ross_phillips
External Customer Email:  
External Test Config: My Hardware and Environment details:

Windows 7 Enterprise (64bit)

IIS 7.5



We are also getting this error, this issue need to fix as soon as possible
Vote by External U.
15644 | April 18, 2013 03:39:08 PM GMT
We have also started experiencing this issue since applying the hotfix, although (at least in our case) it only seems to happen if the cfc exists in an application containing an application.cfc file. AFAIK, the folowing workarounds exist: 1. Disable "Enable Request Debugging Output" in the CF administrator 2. Create a .cfm proxy to use in your AJAX or Flash remoting requests which will invoke the CFC methods 3. Append _cf_nodebug=true to the requests as either a URL or POST parameter In addition to the above error, it appears that the display of debugging info for remote CFC requests also changed with this hotfix (even if no application.cfc exists). Previously debug information was not appended to the debug output of these remote CFC requests (even if <cfsetting showdebugoutput="yes" />) but after applying the hotfix debugging info is now being appended to the output of these remote CFC requests. You can work around this by adding the following code to your application.cfm or application.cfc's onRequestEnd() function: <!--- Disable debugging into for remote CFC (i.e. AJAX) requests ---> <cfif StructKeyExists(GetHTTPRequestData().headers, "X-Requested-With")> <cfsetting showdebugoutput="no" /> </cfif>
Comment by External U.
15636 | April 19, 2013 03:43:23 PM GMT
This bug has "broken" at least two of our apps since applying the hotfix. We've had to implement various workarounds as a result.
Vote by External U.
15645 | April 19, 2013 03:46:07 PM GMT
We cannot apply the hotfix to our servers until this issue is corrected. Please correct the issue as soon as possible.
Comment by External U.
15637 | April 24, 2013 02:33:51 PM GMT
I cannot apply the hotfix to our production environment until this is corrected due to the impact on all of our applications. Please correct this as soon as possible.
Vote by External U.
15646 | April 24, 2013 02:50:02 PM GMT
My Applications rely heavily on AJAX & remote function calls. I cannot apply the security hotfix until this issue is resolved. I'm also getting a similar error on remote function calls that do not return JSON.
Vote by External U.
15647 | April 26, 2013 03:42:49 PM GMT
I made a small test. It works with Application.cfm but the error occurs with an Application.cfc and it's independent from the returntype.
Comment by External U.
15638 | April 30, 2013 07:08:12 AM GMT
Other kind of remote access, cfajaxproxy, works
Comment by External U.
15639 | April 30, 2013 07:26:24 AM GMT
We have deployed this to production, where we don't need debug to be turned on; we've had to roll back our development environment, however, as we'll need to make loads of changes to work around this issue. Please alert me when a hotfix has been released.
Comment by External U.
15640 | May 01, 2013 10:54:04 AM GMT
I can't find a good workaround for this, so we just won't use Request Debugging until this is fixed. It breaks a LOT of things, not cool Adobe...
Vote by External U.
15648 | May 01, 2013 01:15:46 PM GMT
Having the same problem and have rolled back to APSB13-3. Surprised Adobe has not responded with a fix to this issue after 12 days considering its related to a security patch.
Vote by External U.
15649 | May 01, 2013 01:33:27 PM GMT
We use AJAX calls to remote methods all the time, and JSON is our preferred return type. We lock down debug by IP and leave it on so we can quickly debug our issues when they arise. This issue means our applications will be thoroughly broken for everyone in our organization if we apply this hotfix to our production servers. We can't allow that. This is a major bug. We should haven't to choose between spending countless hours rewriting functionality or having fully patched and secure servers.
Vote by External U.
15650 | May 06, 2013 12:32:17 PM GMT
I have verified this bug and it is fixed now. We will be releasing it shortly.
Comment by Nimit S.
15641 | May 07, 2013 03:28:50 AM GMT
This issue took down my production API.
Vote by External U.
15651 | May 13, 2013 10:19:03 AM GMT
This causes problems with staging servers and temporary troubleshooting. I would make it a priority.
Vote by External U.
15652 | May 13, 2013 10:29:02 AM GMT
Any word yet Adobe? This issue needs to be resolved so we can properly patch our servers. What good is a security update if it breaks things instead of fixing them?
Vote by External U.
15653 | May 13, 2013 10:32:02 AM GMT
Impacts production servers so our choice is to not apply security patch or to apply security patch and have servers down because of bug in patch. Not a great choice. This should be a high priority to fix, please!
Vote by External U.
15654 | May 13, 2013 11:35:47 AM GMT
Any view on a fix for this being released?
Comment by External U.
15642 | May 15, 2013 03:44:13 AM GMT
A new project is blocked to be deployed because of this issue. Of course we can't remove the latest security fix as workaround!
Vote by External U.
15655 | May 16, 2013 01:17:22 AM GMT
This issue is fixed in APSB13-13. Link: Regards, Nimit
Comment by Nimit S.
15643 | May 16, 2013 02:39:40 AM GMT