Hi Ronzy, ASF projects get security reports every day, many of them AI-generated. ASF Security triages them against the project’s security model and forwards the valid ones to the PMC’s private list, where the PMC deals with them. CVEs are not discussed in public.
If a PMC doesn’t do this itself, someone else will. These tools are available to everyone, and every project is a scan target. Look at the volume of ASF advisories on oss-security (https://oss-security.openwall.org/wiki/mailing-lists/oss-security), and you’ll see it’s happening to every project, not just TomEE. Glasswing was announced before that blog post, while the scans were already running. PMCs were asked privately (via ASF Security and ASF Tooling) to participate, and we did. ASF Security pre-triaged each report before it reached us. The methodology won’t be shared. That’s an ASF-wide decision. A CVE doesn’t disappear because it isn’t listed. EOL versions are affected, as are a lot of the transitive dependencies they ship. EOL is EOL. Only 10.x and 11.x are maintained, and we just made that clearer on the security page. If you need support or help for older versions, there are commercial vendors for that. TomEE is a volunteer-driven project. No one is paid by the project to work on it. If someone's employer pays for their time, that's an investment in a component the employer uses. However, TomEE has had a participation problem for a long time. Most of the work is done by a few people, often the same people who also maintain our upstream dependencies. No volunteer wants to spend their evenings after the day job reproducing, triaging and fixing security reports. It's not fun work, but we do it anyway. AI has sped up open source work, but maintainer burnout and maintainers leaving are a real threat. Since all of this is volunteer work, as David Blevins once put it: “If you frequently take pennies and do not give, there will be no pennies.” If you care about the project as a user, it might be time to contribute. The security model, the website, EE11, tests and fixes are all open for PRs. I won't go into the individual points further because my volunteer time is limited. Gruß Richard > Am 12.11.2026 um 22:56 schrieb Ronzy Thomas <[email protected]>: > > 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
