Lucee-62 RequestTimeout based when invalid cookies sent

anderslars27 · November 11, 2025, 6:16pm

In Lucee 6.2

Lucee Version 6.2.3.35
Servlet Container Apache Tomcat/11.0.13
Java 21.0.9 (Eclipse Adoptium) 64bit
Windows, with IIS

When we get cookies named ‘Path’ or ‘version’ etc that are a reserved keyword in the cookie protocol, we see 2 things as per below.

Not clear if these are malicious or not, but we are not setting those cookies in code. I can filter out the noise of these exceptions, but main concern is that they are sitting there and could contribute to thread exhaustion if the request come fast enough. Any obvious way to mitigate? I could use URL rewrite to drop the request if certain cookie names exists if i absolutely have to, but seems aggressive.z

Thanks

exception - Cookie name “Path” is a reserved token

com.intergral.fusionreactor.j2ee.jakarta.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:163)
com.intergral.fusionreactor.j2ee.jakarta.filter.FusionReactorRequestHandler.doNext(FusionReactorRequestHandler.java:705)
com.intergral.fusionreactor.j2ee.jakarta.filter.FusionReactorRequestHandler.doHttpServletRequest(FusionReactorRequestHandler.java:263)
com.intergral.fusionreactor.j2ee.jakarta.filter.FusionReactorRequestHandler.doFusionRequest(FusionReactorRequestHandler.java:126)
com.intergral.fusionreactor.j2ee.jakarta.filter.FusionReactorRequestHandler.handle(FusionReactorRequestHandler.java:743)
com.intergral.fusionreactor.j2ee.jakarta.filter.FusionReactorCoreFilter.doFilter(FusionReactorCoreFilter.java:35)
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
com.intergral.fusionreactor.j2ee.jakarta.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:69)
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
com.intergral.fusionreactor.agent.filter.FusionReactorStaticFilter.doFilterJakarta(FusionReactorStaticFilter.java:282)
com.intergral.fusionreactor.agent.pointcuts.jakarta.JakartaNewFilterChainPointCut$1.invoke(JakartaNewFilterChainPointCut.java:48)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:165)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:77)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:113)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:83)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:654)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:72)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:341)
org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:424)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:903)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1778)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:946)
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:480)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:57)
java.lang.Thread.run(Unknown Source)

and then 2 minutes later (the request timeout setting)

"ERROR","ControllerThread:10586","11/11/2025","11:12:48","controller","stop request (27) because run into a timeout. ATM we have 1 active request(s) and 0 active cfthreads (no path available).;java.lang.Throwable;java.lang.Throwable
	at java.base/jdk.internal.misc.Unsafe.park(Native Method)
	at java.base/java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.unmanagedBlock(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.managedBlock(Unknown Source)
	at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
	at java.base/java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
	at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:108)
	at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
	at org.apache.tomcat.util.threads.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:886)
	at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:933)
	at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:480)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:57)
	at java.base/java.lang.Thread.run(Unknown Source)

"

cfmitrah · November 12, 2025, 12:03pm

This happens because Tomcat rejects reserved cookie names like Path or Version.
Lucee doesn’t have a built-in setting to handle it.
You can safely ignore the log or filter those cookies at the web server level.
If needed, set rejectIllegalHeader="false" in Tomcat’s connector to avoid the error

anderslars27 · November 12, 2025, 1:51pm

Thanks for the response and makes sense. The only concern (in ignoring it) is the fact that there is a [later] request timeout for every one of these non-compliant cookie name requests. So it looks like Lucee’s controller is forcibly killing a request that’s been waiting on a thread past the request timeout max.
I am going to reject these requests at the IIS URL rewrite level for now to be safe so I don’t get too many threads tied up if these bots start hammering me.