{"uuid": "c7164a0c-1d13-4a83-9fd6-0a823fffadcb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-34486", "type": "seen", "source": "https://gist.github.com/albertotrindade131-png/9c164247cb64ddc15993e8b7a3f49581", "content": "I verified it. The chain is Apache Tomcat EncryptInterceptor: CVE-2026-29146 was the padding-oracle issue, fixed in Tomcat 9.0.116 / 10.1.53 / 11.0.20, but that fix introduced CVE-2026-34486, where the EncryptInterceptor could be bypassed; the follow-up fix is in 9.0.117 / 10.1.54 / 11.0.21. The key diff is that super.messageReceived(msg) was moved outside the decrypt-success path in the first patch, then moved back in the regression fix. \n\nApache Tomcat patch regression: CVE-2026-29146 -> CVE-2026-34486\n\nI was looking at these two Apache Tomcat CVEs because they are a clean example of a security fix creating a new bug.\n\nThe CVEs are:\n\n- CVE-2026-29146\n- CVE-2026-34486\n\nThis is about Tomcat's \"EncryptInterceptor\", which is used in Tomcat clustering / Tribes communication.\n\nQuick summary\n\nCVE-2026-29146 was a padding oracle issue in \"EncryptInterceptor\".\n\nThe fix changed the encryption handling and also changed part of the message receive flow.\n\nThe problem is that this fix accidentally allowed \"EncryptInterceptor\" to be bypassed.\n\nThat follow-up bug became CVE-2026-34486.\n\nSo the chain is basically:\n\nCVE-2026-29146\n  -> patch changes EncryptInterceptor\n  -> patch accidentally forwards messages even after decrypt failure\n  -> CVE-2026-34486\n\nAffected / fixed versions\n\nFor CVE-2026-29146:\n\nTomcat line| Affected| Fixed in\n11.x| 11.0.0-M1 to 11.0.18| 11.0.20\n10.x| 10.0.0-M1 to 10.1.52| 10.1.53\n9.x| 9.0.13 to 9.0.115| 9.0.116\n8.5.x| 8.5.38 to 8.5.100| no normal current-line fix\n7.x| 7.0.100 to 7.0.109| no normal current-line fix\n\nFor CVE-2026-34486:\n\nTomcat line| Affected| Fixed in\n11.x| 11.0.20| 11.0.21\n10.x| 10.1.53| 10.1.54\n9.x| 9.0.116| 9.0.117\n\nPatch commits I checked\n\nFor Tomcat 9:\n\n- CVE-2026-29146 fix: \"0112ed22abfccc3d54e44d91eb08804d0886acd1\"\n- CVE-2026-34486 fix: \"776e12b3e2b0b4507b8a3b62c187ceb0b74bf418\"\n\nFor Tomcat 10:\n\n- CVE-2026-29146 fix: \"607ebc0fa522bd9e8c05517baa2d179bbd1e659c\"\n- CVE-2026-34486 fix: \"55f3eb9148233054fccfdf761141c6894a050be1\"\n\nFor Tomcat 11:\n\n- CVE-2026-29146 fix: \"6d955cceca841f2eabf2d6c46b59a8c7e1cd6eaa\"\n- CVE-2026-34486 fix: \"1fab40ccc752e22639eccfe290d5624afad7eccd\"\n\nWhat changed in the bad patch\n\nThe interesting part is in:\n\njava/org/apache/catalina/tribes/group/interceptors/EncryptInterceptor.java\n\nBefore the regression, the message was only passed forward after decrypt worked.\n\nThe CVE-2026-29146 patch moved this call:\n\nsuper.messageReceived(msg);\n\nso it happened after the \"catch\".\n\nThat means if decrypt failed, the code logged the error, but then still continued and passed the message forward.\n\nThat is the regression.\n\nSimplified version:\n\ntry {\n    decrypt(message);\n} catch (GeneralSecurityException e) {\n    log.error(\"decrypt failed\", e);\n}\n\nsuper.messageReceived(msg);\n\nThis is bad because the interceptor is supposed to stop bad encrypted messages, not just log the problem and continue.\n\nWhat the second patch fixed\n\nThe CVE-2026-34486 patch moved \"super.messageReceived(msg)\" back into the successful decrypt path.\n\nSimplified version:\n\ntry {\n    decrypt(message);\n    super.messageReceived(msg);\n} catch (GeneralSecurityException e) {\n    log.error(\"decrypt failed\", e);\n}\n\nNow if decrypt fails, the message is not forwarded.\n\nThis is a tiny diff, but the security meaning is big.\n\nWhy I think this is a good regression example\n\nThis was not a huge rewrite.\n\nThe regression was basically a control-flow mistake.\n\nThe code still caught the decrypt error, so at first glance it may look safe.\n\nBut catching the error is not enough.\n\nThe important question is:\n\nAfter decrypt fails, does the message stop?\n\nIn the broken patch, the answer was no.\n\nThat is why the second CVE exists.\n\nMain lesson\n\nFor security code, error handling is part of the security boundary.\n\nIf the security check fails, the code should usually stop right there.\n\nLogging the error is not the same as blocking the message.\n\nIn this case, the first patch fixed the crypto issue, but accidentally changed the message flow.\n\nThe second patch fixed the flow.\n\nMy takeaway\n\nThis is the kind of bug that is easy to miss in review because the code looks cleaner after moving the call outside the \"try\".\n\nBut for security checks, cleaner code can still be wrong.\n\nThe safer review question would have been:\n\nCan any message reach super.messageReceived(msg) if decrypt fails?\n\nIf yes, that is a bug.\n\nReferences\n\n- Apache Tomcat security page for Tomcat 9\n- Apache Tomcat security page for Tomcat 10\n- Apache Tomcat security page for Tomcat 11\n- NVD entry for CVE-2026-29146\n- NVD entry for CVE-2026-34486\n- Apache Tomcat commit \"0112ed22\"\n- Apache Tomcat commit \"776e12b3\"\n- Apache Tomcat commit \"607ebc0f\"\n- Apache Tomcat commit \"55f3eb91\"\n- Apache Tomcat commit \"6d955cce\"\n- Apache Tomcat commit \"1fab40cc\"", "creation_timestamp": "2026-06-22T08:31:57.000000Z"}