Apache Wicket EUVD-2026-114899

Exploitation requires a non-default deployment where wicket-core is loaded by a class loader that cannot see the application's component classes: wicket-core in a servlet container's shared library directory, in an EAR library directory with the application in the WAR, as an application-server global module, or as an OSGi bundle whose wicket-core bundle cannot resolve application-bundle classes. The standard WAR packaging with wicket-core in WEB-INF/lib is NOT affected because the class-file check then succeeds and the template is refused. The attacker must know and name a component's fully qualified class name, though Wicket embeds these in the package-resource URLs it renders. Impact is strictly limited: read-only disclosure of developer-authored markup templates only - no user data, credentials, or session material is reachable, and there is no write or availability impact. Affected versions: 8.0.0-8.19.0, 9.0.0-9.24.0, 10.0.0-10.11.0; fixed in 8.20.0, 9.25.0, 10.12.0.

Signals are consistent and point to a genuine but low-urgency information-disclosure issue rather than a high-priority flaw. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N) scores 6.3 (Medium): network-reachable and unauthenticated (PR:N), but carrying AT:P - an attack requirement - because exploitation depends on a non-default class-loader layout, and VC:L with VI:N/VA:N because only read-only disclosure of developer-authored markup occurs. The vuln.today decision label is 'this_month', not act_now or emergency. No EPSS score, no CISA KEV listing, and no public exploit were provided; per the input the only reference is the Apache advisory, so exploitation status is 'no public exploit identified at time of analysis'. The AT:P requirement is the key discriminator: as the description states explicitly, ordinary WAR packaging (wicket-core in WEB-INF/lib) is NOT affected, and only atypical deployments (shared container library, EAR lib with app in WAR, app-server global module, or OSGi where wicket-core's bundle cannot resolve application classes) are exposed. Combined with the limited impact (no user data, credentials, or session material reachable), this is a real but narrowly-scoped issue appropriate for scheduled patching, not emergency response.

In a deployment where wicket-core runs in a class loader that cannot see the application's component classes (e.g. placed in a servlet container's shared library directory), a remote unauthenticated attacker requests the package-resource URL of a named component class - fully qualified class names that Wicket itself writes into every package-resource URL it renders. Because PackageResourceGuard finds no co-located class file, it serves the component's markup template with HTTP 200, disclosing developer-authored template content such as structure, comments, conditionally-rendered markup, inline script, and referenced endpoints. No public exploit was identified at time of analysis, and network reach is offset by the AT:P requirement that the target run a non-default class-loader layout.