Dear TomEE Community and PMC Members, I would like to raise some serious concerns regarding the recent large number of CVEs published for Apache TomEE, particularly those identified through Claude-based security scanning.
First, I want to emphasize that I fully support improving the security of Apache TomEE. Identifying and fixing genuine security vulnerabilities is essential, and I appreciate the efforts of everyone contributing to that work. However, I believe we need a broader community discussion about how these security scans were initiated, how their findings were evaluated, and how the resulting CVEs affect users of older, unsupported TomEE versions. *1. Who decided to introduce Claude-based security scanning?* According to the ASF announcement published on September 3, 2026, the Foundation conducted large-scale security scanning using Anthropic's Claude Mythos through Project Glasswing. Reference: https://news.apache.org/foundation/entry/security-scanning-at-foundation-scale I understand that this was an ASF-level initiative. However, I have not been able to locate a public TomEE community discussion concerning participation in this scanning program. My questions are: - Was the TomEE PMC consulted before TomEE was included in these scans? - Who decided that this approach should be applied to the TomEE codebase? - Was the decision discussed on the TomEE development mailing list? - Was there a formal PMC decision, consensus discussion, or VOTE? - If such a discussion took place, could someone provide a reference to the corresponding mailing-list thread? - Did the TomEE PMC review and approve the threat model and scanning scope? I recognize that individual security reports may require confidential handling and that not every operational decision requires a public vote. Nevertheless, adopting an initiative that results in dozens of public vulnerability announcements affecting a large existing user base deserves appropriate project-level oversight and transparency. *2. Why are we publishing so many CVEs affecting EOL versions?* On November 10, 2026, approximately 38 CVEs were announced for Apache TomEE, including findings affecting historical OpenEJB and TomEE releases. A significant number of these findings affect older versions, including TomEE 7.x, 8.x, and 9.x, as well as legacy modules that have been removed from the current releases. This raises an important concern. There are many enterprise applications still running these older TomEE versions in production. In many cases, organizations cannot immediately upgrade because their applications depend on Java EE APIs, older Java runtimes, or complex application architectures. These organizations are already operating on versions that are no longer actively maintained by the Apache TomEE community. When we suddenly publish numerous additional CVEs against those releases, we create significant operational and compliance challenges for their users. Security scanners begin reporting additional findings. Enterprise security teams demand remediation, and customers are required to explain why these vulnerabilities remain unresolved. Yet, for many of these users, no official security patch is available for their existing version. In addition, migrating from TomEE 8.x or 9.x to TomEE 10.x is not necessarily a straightforward version upgrade, particularly because of the transition from javax.* to jakarta.*. I believe our proactive security-scanning efforts should primarily focus on the actively supported TomEE branches. This is not an argument for concealing genuine vulnerabilities in older software. Valid vulnerabilities should still be disclosed accurately, including their historical affected versions. However, I strongly believe that findings affecting only EOL releases or abandoned components should be handled and presented separately, with clear support status, applicability information, and realistic remediation guidance. Otherwise, we risk creating significant problems for users without providing a practical solution. *3. Have all AI-generated findings been independently validated?* Another concern is how these vulnerabilities were evaluated before CVE publication. AI-based security analysis can be extremely useful, but the existence of an AI-generated finding does not automatically establish that a vulnerability is exploitable in a real-world deployment. For each reported vulnerability, I believe we should be able to establish: - Whether it was independently reproduced and validated by a human reviewer. - Whether the affected functionality is enabled by default or requires a specific configuration. - Whether the vulnerable component is included in standard TomEE distributions. - Whether the issue can actually be exploited through a supported and realistic deployment configuration. - Whether all listed historical versions were tested or their affected status was inferred from source-code analysis. - Whether the finding was evaluated against TomEE's documented security model and trust boundaries. We should also distinguish between an actual security vulnerability, insecure configuration, a theoretical attack scenario, and behavior that is intentionally supported by the architecture. I am particularly concerned about assigning broad affected-version ranges without clearly distinguishing verified impacts from inferred ones. *4. CVEs for components that have already been removed* Several of the recently announced CVEs affect legacy modules such as the embedded OpenEJB HTTP server, Hessian remoting, and the SSH administration shell. The current TomEE security page explicitly states that these modules have been removed and that no fixed versions of those components exist. I understand that removing vulnerable functionality can be a legitimate security measure. However, for organizations that depend on these modules, removal is not equivalent to a security patch. How are such users expected to remediate these findings without potentially redesigning their applications? Should we distinguish more clearly between vulnerabilities that have been patched and vulnerabilities whose affected functionality has simply been removed? I believe this distinction is extremely important for enterprise users and security auditors. *5. Who approved the publication of these CVEs?* I found the public release votes for TomEE 10.3.0 and TomEE 11.0.0-M2. However, these votes concern the release artifacts. I would like to better understand the decision-making process surrounding the security advisories themselves. Were the findings reviewed collectively by the TomEE PMC or designated security team before publication? Was the scope of the affected versions reviewed? Was there a coordinated disclosure and remediation plan, particularly for users of unsupported branches? I am not suggesting that each CVE requires a public vote, nor that confidential vulnerability details should have been discussed publicly before disclosure. I am asking whether an appropriate project-level review took place and whether the community can receive a non-sensitive summary of that process. *6. We need a clearer security policy for EOL releases* I would like to propose that the TomEE community establish a clearer policy for future AI-assisted security scanning and CVE publication. In particular: - Prioritize active and supported release branches when planning proactive scans. - Clearly separate supported and EOL versions in security advisories. - Distinguish verified affected versions from potentially affected versions. - Document actual exploitability conditions and relevant deployment assumptions. - Clearly distinguish a security fix from the removal of vulnerable functionality. - Provide realistic workarounds or migration guidance when no fix is available. - Review large batches of AI-generated findings through an agreed PMC security-triage process. - Communicate major changes in scanning and disclosure practices to the community, while protecting confidential security information. For legacy vulnerabilities, users should be told explicitly when no community-maintained fix is planned, rather than receiving upgrade recommendations that may not be technically feasible in their environment. *7. The impact on the TomEE ecosystem* Apache TomEE has been used by organizations for many years, and the stability of its enterprise application environment is one of its important strengths. A sudden increase in published CVEs can create substantial uncertainty among organizations that have relied on TomEE in production. Security transparency is essential, but so are accurate risk classification, responsible communication, and realistic remediation options. Publishing dozens of CVEs should not become the measure of success of an AI security-scanning initiative. The real objective should be to reduce exploitable risk and improve the security of software that people actually deploy. I am not against Claude, AI-assisted security analysis, or responsible CVE disclosure. My concern is whether we have established the right governance, priorities, validation standards, and disclosure practices for using these tools within the TomEE project. I would appreciate clarification from the TomEE PMC on the original decision to participate in this initiative, the relevant discussion or approval records, and the policy we intend to follow for future security scanning and EOL-related CVE announcements. I believe this deserves an open discussion on the development mailing list. Thank you for your attention. Best regards, Ronzy
