Apache Commons BCEL CVE-2026-105111

Exploitation requires that the deployment actually uses BCEL's Class2HTML utility (classes in org.apache.bcel.util such as Class2HTML, AttributeHTML, CodeHTML, ConstantHTML) to generate HTML reports from class files that are possibly attacker-controlled, and that a victim subsequently opens the generated report in a browser (UI:P). The payload is carried in class-file-derived strings (anchors, type/class names, field/method names, attribute values) that the emitters wrote into HTML without escaping. Limiting factors: this is not reachable in normal library use of BCEL (bytecode parsing/manipulation) - only the report-generation feature is affected; the attacker must get their crafted class file into the report pipeline, and a human must view the resulting HTML, so there is no fully automated/unattended exploitation path. No special server configuration is needed beyond use of the Class2HTML feature itself.

This is a low-priority, high-conditionality issue despite the CVSS:4.0 vector showing AV:N/AC:L/PR:N. The vendor-assigned CVSS 4.0 base score is only 2.3, and the signals are internally consistent: the vulnerable system suffers no impact (VC:N/VI:N/VA:N), with only low confidentiality/integrity impact against a subsequent system (SC:L/SI:L) - i.e., the browser rendering the generated HTML report, which is the classic signature of XSS rather than direct server compromise. Two metrics strongly dampen real-world risk: AT:P (a specific attack requirement must be met - namely that Class2HTML is run against attacker-controlled class files) and UI:P (a victim must open the generated report). Exploitation status is 'no public exploit identified at time of analysis': the only references are the fix commit and the Apache announcement thread, not exploit code. No EPSS score and no CISA KEV listing were provided; absence of these is expected for a low-severity library-tooling XSS and should not be read as either elevated or suppressed risk. The one caveat worth flagging: PR:N/UI:P describe the abstract attacker, but exploitation realistically depends on an uncommon operational workflow (feeding untrusted bytecode into Class2HTML and publishing/viewing the resulting report), so defenders should treat the deployment precondition, not the CVSS vector, as the true gating factor.

An attacker crafts a Java class file whose names or attribute strings embed an HTML/JavaScript payload and gets it into a workflow (e.g., an analysis pipeline or shared JAR) where an operator runs BCEL's Class2HTML to produce browsable reports. Class2HTML's emitters write these attacker-controlled strings into the HTML without escaping, so when the operator opens the report the payload executes as stored XSS in their browser. No public exploit code is identified; exploitation requires both low attack complexity and that a victim view the generated report (UI:P).