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
