Disable the Apache Tomcat Examples Web Application to Mitigate CVE-2026-66299 on Windows

What the Tomcat examples removal Worklet does

This Automox Worklet™ disables the Apache Tomcat examples web application on Windows endpoints that run a Tomcat release affected by CVE-2026-66299. The CVE is an uncontrolled resource consumption flaw in the WebSocket chat example, which ships inside the examples application.

Affected releases are 9.0.89 through 9.0.120, 10.1.24 through 10.1.57, and 11.0.0-M20 through 11.0.24. On those releases, the Worklet moves the examples folder out of webapps and leaves server.xml and every other application under webapps alone.

Why remove the Tomcat examples application from production servers

The examples application demonstrates servlets, JSP pages, and WebSocket features for developers. It has no role on a production server. Tomcat deploys every directory in webapps, so a leftover examples folder runs at the /examples context path next to your business applications. On an affected release, that folder also carries the vulnerable chat example, whose flaw can exhaust the instance's resources.

The Apache Tomcat security considerations documentation says to always remove the examples web application from security-sensitive installations. Apache's advisory for CVE-2026-66299 recommends removing the examples application or upgrading. The advisory also says installations without the examples application aren't affected.

Tomcat 9.0.121, 10.1.59, 11.0.25, and later releases resolve CVE-2026-66299. A Tomcat upgrade usually needs a change window, regression testing, and sign-off from the teams that own each web application. The Worklet is a temporary workaround while that upgrade waits for approval.

How the Tomcat examples mitigation works

1. Evaluation phase: Finds Tomcat through the machine-level CATALINA_HOME and CATALINA_BASE environment variables and a set of common install paths. Those paths include every folder under Apache Software Foundation in Program Files and Program Files (x86), plus %SystemDrive%\Tomcat (usually C:\Tomcat) and its immediate subfolders.

   The Worklet also reads the 64-bit and 32-bit views of HKLM\SYSTEM\CurrentControlSet\Services. For each service whose name contains "tomcat", it takes the install directory from an ImagePath of the form <install>\bin\<name>.exe. Only folders that contain a webapps directory count as Tomcat instances.

   For each instance, the Worklet reads the version from org/apache/catalina/util/ServerInfo.properties inside lib\catalina.jar. It opens the jar with shared read access, so the check works on a running Tomcat. If the jar gives no answer, it falls back to the RELEASE-NOTES file. You'll see each instance and its detected version in the Activity Log.

   The endpoint reports non-compliant with exit code 1 only when an instance on an affected version still has a webapps\examples directory. That result triggers remediation. Evaluation exits 0 for unaffected versions, instances without the examples directory, and endpoints with no Tomcat.

   When the Worklet can't read the version of an instance with webapps\examples, it logs that instance as undetermined for you to review manually. Its examples folder stays in place. If no other instance is non-compliant, evaluation exits 0 and writes a COMPLIANT (UNDETERMINED) line to the Activity Log.

2. Remediation phase: Moves each affected webapps\examples directory to a sibling folder named examples.disabled_cve-2026-66299 in the Tomcat base directory. A rename inside webapps would only redeploy the application under a new URL, so the new folder sits outside the appBase on the same volume. If a disabled folder from an earlier run already exists, the Worklet adds a timestamp to the new folder's name.

   The Worklet reruns discovery and the version check before it moves anything. Each move goes into the Activity Log and into examples-paths.manifest under %ProgramData%\amagent\WorkletCache\ec1b6282-554f-5556-9a9c-afbc28d1e9f1. The Worklet then confirms that webapps\examples is gone. If a file lock blocks a move, it logs the error and exits 1.

   If an internal team still relies on the examples pages, you can put them back. Set rollback to $true in the remediation code. Scheduled runs skip compliant endpoints, so run the policy manually on the Tomcat endpoint. Rollback moves each folder listed in the manifest back into webapps.

   If a new webapps\examples folder already exists, rollback leaves the disabled folder in place. If autoDeploy is off, restart Tomcat to load the restored application. The restored folder makes the endpoint non-compliant again. Remove the endpoint from the policy before you reset rollback to $false. Otherwise the next scheduled run moves the folder out again.

Tomcat examples mitigation requirements

• Windows 10 or Windows 11 x64, or Windows Server 2016 and later, with PowerShell 5.1 or newer

• Administrative rights to move folders inside the Tomcat installation and write the manifest. The Automox agent runs Worklets as SYSTEM by default, which covers both.

• Apache Tomcat installed in one of the locations the Evaluation phase searches

• A readable lib\catalina.jar or RELEASE-NOTES file in CATALINA_HOME, which the Worklet reads for the Tomcat version

• No process holding files in the examples directory open. If a move fails, stop the Tomcat service in a maintenance window and run the Worklet again.

• Optional dryrun and rollback variables at the top of the remediation code, both $false by default. When you set dryrun to $true, the Worklet logs each planned move to the Activity Log and moves nothing.

Expected Tomcat state after the mitigation

After remediation, each affected instance's examples folder sits in examples.disabled_cve-2026-66299 beside webapps. With autoDeploy enabled on the <Host> element in server.xml, Tomcat undeploys the application and stops serving /examples. The Worklet doesn't restart Tomcat. With autoDeploy off, restart the Tomcat service to unload /examples.