_A new Tomcat security issue has been reported that affects Tomcat versions 7.0.0 through 7.0.22, versions 6.0.0 through 6.0.33 and versions 5.5.0 through 5.5.34. 
According to the Tomcat mailing lists:
_"CVE-2012-0022 Apache Tomcat Denial of Service

Severity: Important

Description:
Analysis of the recent hash collision vulnerability identified unrelated inefficiencies with Apache Tomcat's handling of large numbers of parameters and parameter values. These inefficiencies could allow an attacker, via a specially crafted request, to cause large amounts of CPU to be used which in turn could create a denial of service.
The issue was addressed by modifying the Tomcat parameter handling code to efficiently process large numbers of parameters and parameter values.

Mitigation:
Users of affected versions should apply one of the following mitigations:
- Tomcat 7.0.x users should upgrade to 7.0.23 or later
- Tomcat 6.0.x users should upgrade to 6.0.35 or later
- Tomcat 5.5.x users should upgrade to 5.5.35 or later

Credit:
The inefficiencies in handling large numbers of parameters were identified by the Apache Tomcat security team.
 
A new Tomcat security issue has been reported that affects Tomcat versions 7.0.0 through 7.0.21 and versions 6.0.30 through 6.0.33. 
According to the Tomcat mailing lists:
_"CVE-2011-3375 Apache Tomcat Information disclosure

Severity: Important

Description:
For performance reasons, information parsed from a request is often cached in two places: the internal request object and the internal processor object. These objects are not recycled at exactly the same time. When certain errors occur that needed to be added to the access log, the access logging process triggers the re-population of the request object after it has been recycled. However, the request object was not recycled before being used for the next request. That lead to information leakage (e.g. remote IP address, HTTP headers) from the previous request to the next request.
The issue was resolved be ensuring that the request and response objects were recycled after being re-populated to generate the necessary access log entries.

Mitigation:
Users of affected versions should apply one of the following mitigations:
- Tomcat 7.0.x users should upgrade to 7.0.22 or later
- Tomcat 6.0.x users should upgrade to 6.0.35 or later

Credit:
The issue was initially reported via Apache Tomcat's public issue tracker with the potential security implications identified by the Apache Tomcat security team."
 
Picture
A new security issue has been reported in Apache Tomcat versions 7 through 7.0.20, 6 through 6.0.33 and 5.5.0 through 5.5.33.
According to the Tomcat mailing lists:

"Apache Tomcat supports the AJP protocol which is used with reverse proxies to pass requests and associated data about the request from the reverse proxy to Tomcat. The AJP protocol is designed so that when a request includes a request body, an unsolicited AJP message is sent to Tomcat that includes the first part (or possibly all) of the request body. In certain circumstances, Tomcat did not process this message as a request body but as a new request. This permitted an attacker to have full control over the AJP message which allowed an attacker to (amongst other things): - insert the name of an authenticated user

- insert any client IP address (potentially bypassing any client IP address filtering)
- trigger the mixing of responses between users

The following AJP connector implementations are not affected:

org.apache.jk.server.JkCoyoteHandler (5.5.x - default, 6.0.x - default)

The following AJP connector implementations are affected:
org.apache.coyote.ajp.AjpProtocol (6.0.x, 7.0.x - default)
org.apache.coyote.ajp.AjpNioProtocol (7.0.x)
org.apache.coyote.ajp.AjpAprProtocol (5.5.x, 6.0.x, 7.0.x)

Further, this issue only applies if all of the following are are true for at least one resource:
- POST requests are accepted
- The request body is not processed

Example: See https://issues.apache.org/bugzilla/show_bug.cgi?id=51698

Mitigation:

Users of affected versions should apply one of the following mitigations:
- Upgrade to a version of Apache Tomcat that includes a fix for this issue when available
- Apply the appropriate patch
 - 7.0.x http://svn.apache.org/viewvc?rev=1162958&view=rev
 - 6.0.x http://svn.apache.org/viewvc?rev=1162959&view=rev
 - 5.5.x http://svn.apache.org/viewvc?rev=1162960&view=rev
- Configure the reverse proxy and Tomcat's AJP connector(s) to use the requiredSecret attribute
- Use the org.apache.jk.server.JkCoyoteHandler AJP connector (not available for Tomcat 7.0.x)"