Need confirmation about CVE-2025-48988 impacting Tomcat 9.0.10x related to CVE-2025-48976.
Hi, It is about the CVE-2025-48988 mentioned in the email subject. I have a question that- if we update the "Apache Commons FileUpload" jar to the version which fixes the CVE-2025-48976; in that case, do we still need to update the Apache Tomcat to 9.0.106, 10.1.42 & 11.0.8 which has CVE-2025-48988 fixed ? Or is it not needed to update the Tomcat to these versions ? Thanks & Regards,
Need confirmation about CVE-2025-48988 impacting Tomcat 9.0.10x related to CVE-2025-48976.
Hi, It is about the CVE-2025-48988 mentioned in the email subject. I have a question that- if we update the "Apache Commons FileUpload" jar to the version which fixes the CVE-2025-48976; in that case, do we still need to update the Apache Tomcat to 9.0.106, 10.1.42 & 11.0.8 which has CVE-2025-48988 fixed ? Or is it not needed to update the Tomcat to these versions ? Thanks & Regards,
Re: CSRF not working with 10.1.42 but it works with 10.1.39
On 23/06/2025 01:17, Hrvoje Lončar wrote:
If someone else has a problem with latest "security fix",
here is a working solution to run your Spring Boot app directly from
Eclipse STS
without installing a Tomcat and deploying to it.
Now you can submit forms the same way as you did before.
You can filter out my fix from production environment with `@Profile`
annotation.
@Configuration @EnableWebSecurity(debug= *false*)
@EnableMethodSecurity(prePostEnabled
= *true*, securedEnabled = *true*, jsr250Enabled = *true*) *public
**class *HttpSecurityConfig
{ // ... @Bean @Profile(Str.*DEV*)
WebServerFactoryCustomizer
configTomcatConnector() { * return *factory -> factory.addConnectorCustomizers(
connector -> { connector.setMaxParameterCount( 1000 );
connector.setMaxPartCount(
1000 ); } ); } // ...
If you opt to do that then make sure to do one of the following:
- ensure uploads are only accessible to trusted users
- have 8GB heap spare (16GB if running on Java 8)
or your application will be exposed to a trivial DoS that can disable
the server via an OOME.
I would *strongly* recommend increasing maxPartCount only to the minimum
necessary for your application to work.
Note: It looks like the default for maxPartCount will increase from 10
to 50 in the next release round.
Mark
}
On Sun, Jun 22, 2025 at 3:19 AM Hrvoje Lončar wrote:
The actual problem now is my embedded Tomcat when I start my Spring Boot
app from Eclipse STS:
I get the same error, but I don't know where to configure Tomcat and where
to add this new paramerer.
Anyone?
On Fri, Jun 20, 2025 at 1:28 PM Maxim Solodovnik
wrote:
from mobile (sorry for typos ;)
On Fri, Jun 20, 2025, 18:16 Hrvoje Lončar wrote:
Well, I should say it was a weird way to fix it.
For example, if you don't have a DoS attack
AFAIK defaults should be set to the values preventing DoS
Waiting for the DoS is not a good idea :)
and you upgrade your Tomcat,
that would be a big surprise as it was to me.
Lucky me I have nice users that contacted me and told me some features
of
my web app stopped working.
Moving to next minor release shoulnd't be a surprise even if it is bug
fix
such you mentioned.
Default value should be higher and it should be clearly noted that you
have
to lower it down to go to safe side regarding DoS attacks.
But then again, if you have an actual attack, you're forced to fix
something anyway, so setting the parameter to lower value (as default
should be set to higher values) would be the better fix than upgrading
the
whole Tomcat, especially if you can expect major changes that could
surprise you as they did me few days ago.
Installing a new version is maybe not the best way to go while fixing
vulnerabilites under attack if easier option is available (lowering
value
to be lower than default).
Default value of 10 would be appropriate for major release when you
expect
major changes and you're prepared to additional work regarding upgrade.
But switching from one minor release to another shouldn't break existing
setup, it should only fix bugs.
BR,
Hrvoje Lončar
On Fri, Jun 20, 2025 at 1:02 PM Mark Thomas wrote:
On 20/06/2025 11:54, Hrvoje Lončar wrote:
Thank you very much
Mark ThomasThat was the case :(
Absolutely weird to make such a major change in a minor release from
NN.MM.39 to NN.MM.42
It was a response to a DoS security vulnerability.
Feel free to add your views on what the defaults should be to the BZ
discussion.
Mark
On Fri, Jun 20, 2025 at 10:01 AM Mark Thomas
wrote:
On 20/06/2025 02:07, Hrvoje Lončar wrote:
Hi!
Hope it's the right place to ask for help or/and advice.
Few days ago I switched to latest Tomcat 10.1.42.
After deyploy POST is not working due to missing CSRF token.
When I inspect HTTP request, CSRF token is in a payload as "_csrf"
and
the
value is correct.
But at the backend side I get
* AccessDeniedException = Invalid CSRF Token 'null' was found on
the
request parameter '_csrf' or header 'X-XSRF-TOKEN'.*
Everything works fine with 10.1.39.
To be sure tried on 2 different Ubuntu servers - test and
production
instance.
Anyone else having the same problem?
Maybe related to:
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Try setting maxPartCount on the connector but be aware of DoS
risks as
the value gets higher.
Mark
Some technical info:
- Ubuntu 24.04.2 LTS
- nginx/1.27.5 to handle SSL certificate
- Apache Tomcat 10.1.39 and 10.1.42
- Java 21
- Spring Boot 3.5.0
Thanks!
BR,
Hrvoje
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
*TheVegCat.com
Re: Need confirmation about CVE-2025-48988 impacting Tomcat 9.0.10x related to CVE-2025-48976.
Hi, On Mon, Jun 23, 2025 at 12:12 PM Charpe, Anil wrote: > > Hi, > It is about the CVE-2025-48988 mentioned in the email subject. > I have a question that- if we update the "Apache Commons FileUpload" jar to > the version which fixes the CVE-2025-48976; in that case, do we still need to > update the Apache Tomcat to 9.0.106, 10.1.42 & 11.0.8 which has > CVE-2025-48988 fixed ? > Or is it not needed to update the Tomcat to these versions ? You need to upgrade Tomcat since it uses its own internal copy of fileupload to process the Servlet API multipart functionality. Be aware of https://bz.apache.org/bugzilla/show_bug.cgi?id=69710 and adjust the maxPartCount parameter on the Connector according to your needs. If you are parsing multipart using fileupload directly, then you could only upgrade fileupload itself. Rémy > Thanks & Regards, - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SUSPICIOUS Re: Updating configTest to include shutdown port validation
Thank you Chris for the inputs. export JAVA_OPTS=-Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true before running the configtest This seems to help fail the validation if connector initialization fails. Thanks, Amit From: Christopher Schultz Sent: Sunday, June 22, 2025 3:30 PM To: users@tomcat.apache.org Subject: SUSPICIOUS Re: Updating configTest to include shutdown port validation Cohesity Security Advisory: Automated detections have identified this email as SUSPICIOUS for the following reasons: Message matched suspicious signature 'SentimentCM_Subject.HiddenPath.URL.Phishing' Use extra caution with this email. If you believe this detection was in error or have questions, please contact secur...@cohesity.com. Amit, On 6/20/25 11:32 AM, Amit Pande wrote: > Thank you Mark for the feedback. > > Reason to ask for shutdown port availability was that, configtest already > check that for connector ports. E.g. > > SEVERE: Failed to initialize component > [Connector["nbhttps-jsse-nio-127.0.0.1-12345"]] > org.apache.catalina.LifecycleException: Protocol handler initialization failed > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:1075) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122) > at > org.apache.catalina.core.StandardService.initInternal(StandardService.java:522) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122) > at > org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:957) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122) > at org.apache.catalina.startup.Catalina.load(Catalina.java:712) > at org.apache.catalina.startup.Catalina.load(Catalina.java:735) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown > Source) > at java.base/java.lang.reflect.Method.invoke(Unknown Source) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:485) > Caused by: java.net.BindException: Address already in use > at java.base/sun.nio.ch.Net.bind0(Native Method) > at java.base/sun.nio.ch.Net.bind(Unknown Source) > at java.base/sun.nio.ch.ServerSocketChannelImpl.netBind(Unknown > Source) > at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source) > at > org.apache.tomcat.util.net.NioEndpoint.initServerSocket(NioEndpoint.java:266) > at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:221) > at > org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1399) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1412) > at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:633) > at > org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:82) > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:1073) > ... 11 more > > And a follow up question, even with the SEVERE error like above (or while > creating the SSL context due to incorrect store password for instance), the > return code is 0. Did I miss anything here? > > Jun 20, 2025 10:23:15 AM org.apache.catalina.startup.Catalina load > INFO: Server initialization in [2457] milliseconds > [me@mymachine bin]# echo $? > 0 A single connector failing won't cause the server to fail to start. So it doesn't cause the configtest to fail, either. -chris > > From: Mark Thomas > Sent: Friday, June 20, 2025 2:58 AM > To: users@tomcat.apache.org > Subject: Re: Updating configTest to include shutdown port validation > > Cohesity Security Advisory: Automated detections have identified this email > as SUSPICIOUS for the following reasons: > > Message matched bulk signature 'BULK.LUC.High' > Message matched suspicious signature > 'SentimentCM_Subject.HiddenPath.URL.Phishing' > Use extra caution with this email. If you believe this detection was in > error or have questions, please contact secur...@cohesity.com. > > On 20/06/2025 01:18, Amit Pande wrote: >> Hello, >> >> I was testing out the "configtest" option of the catalina.sh/.bat and >> observed that does not do validation for the shutdown port. > > There are lots of things it doesn't explicitly test. Why is the shutdown > port of particular interest? > >> hxxps://nam11,safelinks,protection,outlook,com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fblob%2F8bbdabe02c384cf15aa43dafb66a5b42440edac3%2Fjava%2Forg%2Fapache%2Fcatalina%2Fstartup%2FBootstrap.java&data=05%7C02%7Camit.pande%40cohesity.com%7C891eb88268c24f0f45e208ddafd045ed%7Cb3c5c12c459546ac9b80e6d7b886903f%7C0%7C0%7C638860031236032446%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
