CVE-2018-1323

Think of the connector as a receptionist that routes incoming IIS requests to the right “employee” (Tomcat URL/handler). Because of a mistake in how it interprets some weirdly formatted address paths, a clever caller may be able to reach an employee that was supposed to be hidden behind the normal receptionist rules. The risk is about exposing application features that weren’t intended to be reachable through the IIS reverse-proxy front door.

This matters if you run Apache Tomcat behind Microsoft IIS using the Apache Tomcat JK ISAPI Connector. It’s relevant only when IIS requests pass through this connector’s IIS/ISAPI path-matching logic. Based on the description, it’s mainly a risk if an attacker can send specially crafted requests to your IIS front end that are then forwarded to the affected Tomcat connector (not just internal Tomcat access).

This is an AMBER issue because the connector can be tricked into exposing unintended Tomcat functionality via crafted requests. There’s no known public exploit code or CISA KEV entry, but the risk is still high enough to warrant action for any environment using the affected connector versions behind IIS.

1. Confirm exposure

• Identify whether the Apache Tomcat JK ISAPI Connector is installed and actively used with your Apache Tomcat deployment.
• Record the connector version. This issue applies to Apache Tomcat JK ISAPI Connector 1.2.0 through 1.2.42.

2. Verify how requests are routed

• Confirm that IIS is forwarding requests through the JK connector (ISAPI) to Tomcat.
• Identify which Tomcat URL paths are meant to be reachable from the IIS front end (the “intended public endpoints”).

3. Upgrade path (preferred)

• The findings state that no fix/patch information is available, so you may not have a clearly documented fixed connector version.
• Work with your Tomcat Connectors package source, vendor, or internal build/IT team to find an upstream release that specifically resolves CVE-2018-1323, and schedule an upgrade when available.
• If you cannot locate a fixed release, treat the mitigation steps below as a stopgap until an upgrade is possible.

4. Configuration mitigation (stopgap)

• Apply strict allow-listing at the IIS layer: deny requests to any URL patterns that should not be accessible publicly.
• Make sure your IIS routing rules do not forward arbitrary or unexpected paths to the connector.
• If you have multiple worker mappings, ensure only the intended worker(s) can be reached from IIS.

5. Detect and monitor

• Enable and review IIS and connector/Tomcat request logs for suspicious path patterns (especially malformed or unusually encoded paths).
• Watch for repeated request attempts that don’t map to normal application navigation.

6. Decide on timing

• Given the AMBER verdict, plan remediation promptly. The priority should be highest if IIS is exposed to the internet or if you have external users reaching the IIS front end.

Affected component: IIS/ISAPI specific code in Apache Tomcat JK ISAPI Connector 1.2.0 to 1.2.42.

Weakness: Incorrect handling of path normalization and matching (CWE-22 and CWE-200).

Mechanism: The connector normalizes the requested path before matching it to the URI-worker map; the normalization/matching has edge cases that can allow a specially constructed request to reach Tomcat application functionality not intended to be exposed when Tomcat is accessed via the reverse proxy.

Exploitation status: No public exploit code is on record (EXPLOIT finding). KEV/CISA confirmation is not listed (KEV finding).

Fix status: No fix/patch information is available in the provided findings (PATCH finding), so a definitive fixed version cannot be stated here.

Threat signals: Press attention is rising, but that is not the same as confirmed exploitation; the findings provide no direct “exploited in the wild” confirmation. EPSS is a prediction with a falling trend; per instructions, this percentage is not used in public-facing blocks.